Good for them for using ACME, but this appears to be some kind of add-on to Fastly, and not "here's my money, one signed cert, please" like I would expect from a general purpose CA
Yeah, I did actually consider replying "but, why?" but that seemed in poor form on someone's announcement. So I thought the middle ground was to bring to attention that there wasn't a call-to-action and it doesn't appear in the Products drop-down as something one could get for themselves without already having a Fastly account
I do actually have some sympathy for the monetary cost of the infrastructure surrounding the "pay to do math" model, but you're 100% correct that for a CDN company, that cost must surely be damn near invisible among the rest of their cost of doing business
I like this. We need to reduce our reliance on Let's Encrypt, so another CA which supports ACME is definitely welcome to me. The GoDaddy cross signature should make Certainly be accepted by just about any client.
Accepted into the root stores for Mozilla, Apple, and Google, but what about Microsoft? (Or maybe Microsoft's doesn't matter anymore with Chrome using their own store since 105, Edge being a Chrome variant, and Firefox always having used their own?)
Though the intermediate cert is cross-signed by GoDaddy, so this isn't a problem right now.
I think their statement is accurate. If they've been accepted into root programs (and it sounds like they have), then the GoDaddy cross-sign is only relevant for older browsers, and even then requires no additional or ongoing actions from GD to keep working.
Is it not dependent on GD keeping upstanding status? If, lets say, they were hacked, and had their status revoked, then the Certainly certs would stop working in some places. That sounds like dependency to me.
In the normal course of events, no. If a CA demonstrates itself to be particularly untrustworthy, the actions most root programs might take (adding restrictions, or removing it from the root store entirely) still rely on those changes getting distributed to users, and if users pick up that update to the root store, they probably picked up the update which added Certainly too.
There are conceivable scenarios where GD doing something (or not doing something) could result in Certainly search no longer validating on some subset of older browsers/clients, but they're quite obscure and unlikely. If you include those scenarios as Certainly having a dependency on GoDaddy, I feel like you would also have to say that Certainly depends on their domain name registrar to not give away their domain out from under them.
I think Microsoft’s Trusted Root Program [1] is still important even with Edge moving to be a Chrome derivative, and it being missing in the announcement is interesting given three other major programs have approved for inclusion.
Inclusion into the trust stores for Linux distributions like Red Hat and Ubuntu will be another interesting one to watch with Certainly.
Oh and the Oracle Java Root Certificate Program [2], since the JRE has its own root certificate store, and Java is still used very broadly.
Very few people actually manage root programs: Mozilla, Apple, Microsoft, Google, Oracle, and maybe one or two others in smaller niches. Everybody else either uses the platform's store or ships an approximation (the certificate list and some basic constraints, but missing the more complex policies implemented in mozilla::pkix) to Mozilla 's store.
That includes Debian, so probably also Ubuntu. Dunno about Red Hat but it's probably the same.
Microsoft runs a "legal" root program, rather than a "public" root program, meaning if you're included in the Microsoft root store, you sign a legal contract with Microsoft. This is not the case with Google, Mozilla, or Apple. So the process of being included just looks a little different.
Edge still uses the Microsoft root store; Microsoft’s program has been going through some updates recently and they paused processing of new applications while sorting processes. I would guess their application is in but is still under review.
That sounds about right to be honest. The part of the process which is essential to be useful is to obtain trust from the Browser vendors/ OS vendors in their role representing the Relying Parties (ie in this case, ordinary users like you or me).
And in practice although you need all of the big ones to be OK with it, the one that matters is Mozilla, via m.d.s.policy, a public group overseeing this well, policy for Mozilla both directly as the vendor of Firefox, and as de facto trust store for Free Unix systems.
Now, m.d.s.policy wants to see a whole bunch of paperwork, including audits, beginning from when you began setting stuff up, your own policy documents etc. and it sometimes wants these fixed so you need to go around the loop again. During this you need a complete, working, system, with the only differences from your final public system being maybe scale and the fact you aren't actually directly trusted. But in practice you will have trust via a cross signature (in this case GoDaddy) so you are trusted, just indirectly - if you screw up that's for real and that's going to be a big deal.
Example: m.d.s.policy wants to see what a working secured web site will be like, so you spin up a site which exists only to show that yup, we can issue a correct leaf cert for the site, with a valid expiry date, path leading back to GoDaddy, if testers tell their test system that it trusts $newCA, then it says it's valid from you not GoDaddy, check.
Another example: m.d.s.policy wants to see that expiry works properly, so you spin up a site with a two month old certificate but only a month of validity. Except wait, if you're like Let's Encrypt/ ISRG you intentionally don't have manual issuance so you literally need to use your normal automated issuance process and then wait until the certificate expires to show that this works. Let's Encrypt really did this. Twice I think.
[Off-topic] but they've got absolutely bizarre webserver/blog behavior. I noticed "page not found" flash briefly on my screen before the content loaded, and indeed you can confirm with curl or network inspector it's actually returning http 404 status code/"page not found" content and then some bunch-o-JS injects the blog post. The Aristocrats!
I saw this on our site that used next.js once. Looks like they use Gatsby which I guess is similar.
Cache headers weren't being set properly, new pages would or wouldn't load depending how you reached the page (direct link vs. javascript loading the content via an internal cache or via a fragment fetch)
Hey! I'm on Fastly's DevX team. Sorry for the 404, we had to make some corrections so we took it down to republish it. But we're super thrilled to see the enthusiasm here and I'm passing along the feedback you shared too! Thanks everyone
39 comments
[ 3.3 ms ] story [ 95.7 ms ] threadI do actually have some sympathy for the monetary cost of the infrastructure surrounding the "pay to do math" model, but you're 100% correct that for a CDN company, that cost must surely be damn near invisible among the rest of their cost of doing business
Also, I really like the name :)
Let’s Encrypt isn’t exactly a SPOF (single point of failure) but also it isn’t like there are 13 equivalents.
https://acmeclients.com/certificate-authorities/
Though the intermediate cert is cross-signed by GoDaddy, so this isn't a problem right now.
> are fully supported by Fastly without any dependence on another organization.
There are conceivable scenarios where GD doing something (or not doing something) could result in Certainly search no longer validating on some subset of older browsers/clients, but they're quite obscure and unlikely. If you include those scenarios as Certainly having a dependency on GoDaddy, I feel like you would also have to say that Certainly depends on their domain name registrar to not give away their domain out from under them.
Inclusion into the trust stores for Linux distributions like Red Hat and Ubuntu will be another interesting one to watch with Certainly.
Oh and the Oracle Java Root Certificate Program [2], since the JRE has its own root certificate store, and Java is still used very broadly.
[1] https://learn.microsoft.com/en-us/security/trusted-root/prog...
[2] https://www.oracle.com/java/technologies/javase/carootcertsp...
That includes Debian, so probably also Ubuntu. Dunno about Red Hat but it's probably the same.
Three years seems like a long time to be working on a CA!
[1] https://uspto.report/TM/88345271
And in practice although you need all of the big ones to be OK with it, the one that matters is Mozilla, via m.d.s.policy, a public group overseeing this well, policy for Mozilla both directly as the vendor of Firefox, and as de facto trust store for Free Unix systems.
Now, m.d.s.policy wants to see a whole bunch of paperwork, including audits, beginning from when you began setting stuff up, your own policy documents etc. and it sometimes wants these fixed so you need to go around the loop again. During this you need a complete, working, system, with the only differences from your final public system being maybe scale and the fact you aren't actually directly trusted. But in practice you will have trust via a cross signature (in this case GoDaddy) so you are trusted, just indirectly - if you screw up that's for real and that's going to be a big deal.
Example: m.d.s.policy wants to see what a working secured web site will be like, so you spin up a site which exists only to show that yup, we can issue a correct leaf cert for the site, with a valid expiry date, path leading back to GoDaddy, if testers tell their test system that it trusts $newCA, then it says it's valid from you not GoDaddy, check.
Another example: m.d.s.policy wants to see that expiry works properly, so you spin up a site with a two month old certificate but only a month of validity. Except wait, if you're like Let's Encrypt/ ISRG you intentionally don't have manual issuance so you literally need to use your normal automated issuance process and then wait until the certificate expires to show that this works. Let's Encrypt really did this. Twice I think.
Edit: Tried opening in a private browsing window (read: more privacy options but no ublock origin) and it still fails.
Cache headers weren't being set properly, new pages would or wouldn't load depending how you reached the page (direct link vs. javascript loading the content via an internal cache or via a fragment fetch)
https://archive.is/20230221154358/https://www.fastly.com/blo...
The original page is a 404 for me.
https://web.archive.org/web/20230221151451/https://www.fastl...
don't downvote me
maybe it was taken down, there is another post which made couple of minutes back
"Protecting your web apps has never been easier: Introducing the Fastly Managed Security Service" https://www.fastly.com/blog/protecting-your-web-apps-has-nev...