Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DigiCert Revocation Incident (CNAME Domain Validation)

digicert.com

Post reply on HN
Print view View original

41–50 of 56 posts

Re: DigiCert Revocation Incident (CNAME Domain Validation)

#41

Post by aaomidi »

pests wrote: post #28
userbinator wrote: post #6

Earlier quoted context omitted.

So if you have a user named "haha_funny" you already aren't allowed to give them the hostname "haha_funny.somesite.example" - and on some system it will just silently not work because it's invalid. Not long ago I actually did come across a site that had an underscore in its domain name, and it worked both for me and apparently Google, because it indexed and showed a (relevant) page from that site. I only remembered i…

In 2019 the CAs agreed not to issue certs to underscored subdomains making this less useful. As evidenced by all your links being http. (as an aside, it looks really weird seeing a bare http link in the wild - crazy that was the old norm!)

A wildcard would still work for these fwiw

Re: DigiCert Revocation Incident (CNAME Domain Validation)

#43

Post by hg35h4 »

devrand wrote: post #34
hg35h4 wrote: post #32

Earlier quoted context omitted.

"Alternatively, if companies cannot handle the rotation, then they likely should re-evaluate if WebPKI is even appropriate for their use-case." I hate hearing this awful take, as if every IT organization has the same neat and tidy systems deployed as they do. Never had to deal with 3rd party SaaS vendors certificate pinning requiring service tickets to change, don't have any hardware devices or appliance based softwa…

"Never had to deal with 3rd party SaaS vendors certificate pinning requiring service tickets to change" I think this tends to fall into "probably shouldn't have been using Web PKI". I can't immediately think of a reason why you'd need a publicly trusted certificate if you're pinning a specific public key.. at that point who cares who signed it? I do agree that there are real costs with rotating certificates that ulti…

"I can't immediately think of a reason why you'd need a publicly trusted certificate if you're pinning a specific public key"

Inter-finance systems mostly, some government. Sometimes they pin the CA issuer, sometimes IP based although with dynamic cloud IPs that is disappearing, sometimes inside a VPN, and other times just the cert issues themselves. Same service handing public users while making bidirectional API calls to other interfaces that are more locked down.

Not everyone is a monolithic copy and paste Wordpress hosting site, a new cloud native cash rich startup, or a massive Google/Amazon/Microsoft with huge teams to orchestrate everything using their own architecture and systems they developed themselves. Private PKI? Even more orchestration layers for enrollment especially in places with BYOD.

There is no point to low expiry certs anyways. If a server is hacked, the primary concern is what data were they able to exfiltrate and for how long - not that a keypair was maybe stolen to be used in a very complicated and unlikely attack to intercept some of the same data they already stole.

Your ATC comment seems to continue your theme that everyone should run a private PKI instead. Airports are full of interconnections between themselves, other airports, airlines, ground crews, satellite relays, and weather monitoring systems. So then all these parties need to do all the same actions as the public PKI - root key signing , cert issue logging, secure interface for issuing certs, develop a trust across all parties and make them install your root in all their systems ..... or, just use the public PKI services which already does that. You are just reinventing the wheel and probably will get it wrong. Maybe for some strictly backend systems, or things like server out of band management it works well, but not anything involving multiple companies.

The CAs work with large and complex business understand these complexes and voted for 2 year duration. The owners of the browsers just wanted to further their own cloud bottom lines.

Re: DigiCert Revocation Incident (CNAME Domain Validation)

#44

Post by alphager »

hg35h4 wrote: post #43
devrand wrote: post #34

Earlier quoted context omitted.

"Never had to deal with 3rd party SaaS vendors certificate pinning requiring service tickets to change" I think this tends to fall into "probably shouldn't have been using Web PKI". I can't immediately think of a reason why you'd need a publicly trusted certificate if you're pinning a specific public key.. at that point who cares who signed it? I do agree that there are real costs with rotating certificates that ulti…

"I can't immediately think of a reason why you'd need a publicly trusted certificate if you're pinning a specific public key" Inter-finance systems mostly, some government. Sometimes they pin the CA issuer, sometimes IP based although with dynamic cloud IPs that is disappearing, sometimes inside a VPN, and other times just the cert issues themselves. Same service handing public users while making bidirectional API ca…

"Your ATC comment seems to continue your theme that everyone should run a private PKI instead."

Not the OP you replied to, but I want to add some nuance: there's a vast solution space between using the WebPKI and rolling your own. The enterprise focused CAs have non-WebPKI CAs and CA-as-a-service offerings, both with way longer certificate lifetimes and way longer revocation periods.

If you don't need WebPKI-compatible certs (because you're not offering services to the general public) and your org cannot abide by the WebPKI rules requiring 24 hours max before revocation, you are doing something very wrong when you use the WebPKI.

Re: DigiCert Revocation Incident (CNAME Domain Validation)

#45

Post by nickf »

CaliforniaKarl wrote: post #37
crote wrote: post #35

Earlier quoted context omitted.

Stuff like this is why some parties have been calling for increasingly-shorter cert validity. When a cert is valid for several years it allows companies to develop an increasingly complex workflow around deploying them, sometimes taking weeks and involving dozens of parties to roll them out. This is in turn used as an excuse by CAs to completely ignore the industry standards. Those SaaS vendors probably shouldn't be…

> Stuff like this is why some parties have been calling for increasingly-shorter cert validity. When a cert is valid for several years it allows companies to develop an increasingly complex workflow around deploying them, sometimes taking weeks and involving dozens of parties to roll them out. This is in turn used as an excuse by CAs to completely ignore the industry standards. "several years"? The certs we are getti…

90 day certificates will be here soon, and moving to shorter lifetimes from there.

Re: DigiCert Revocation Incident (CNAME Domain Validation)

#46

Post by agwa »

CaliforniaKarl wrote: post #36
agwa wrote: post #31

Earlier quoted context omitted.

> I definitely commend DigiCert for pledging to revoke the certificates within 24 hours and not having a delayed revocation or trying to language lawyer their way to a 5 day revocation as other CAs have tried. It seems I spoke too soon: https://bugzilla.mozilla.org/show_bug.cgi?id=1910322#c8

Having a restraining order served on them is going to slow things down a bit.

That only affects 72 certificates. They've delayed revocation for all 83,000+.

Re: DigiCert Revocation Incident (CNAME Domain Validation)

#47

Post by nickf »

agwa wrote: post #25
Apfel wrote: post #20

Is this a potential cause of the current Azure outages hitting western europe? I know DigiCert are used by Azure extensively...

Unlikely. Microsoft operates their own CAs. Some of their CAs have been cross-signed by a DigiCert root, but Microsoft is responsible for the domain validation. I don't think they extensively use certificates issued directly by a DigiCert CA.

They have almost 300 in the affected list from DigiCert, so who knows?!

Re: DigiCert Revocation Incident (CNAME Domain Validation)

#48

Post by nickf »

hg35h4 wrote: post #43
devrand wrote: post #34

Earlier quoted context omitted.

"Never had to deal with 3rd party SaaS vendors certificate pinning requiring service tickets to change" I think this tends to fall into "probably shouldn't have been using Web PKI". I can't immediately think of a reason why you'd need a publicly trusted certificate if you're pinning a specific public key.. at that point who cares who signed it? I do agree that there are real costs with rotating certificates that ulti…

"I can't immediately think of a reason why you'd need a publicly trusted certificate if you're pinning a specific public key" Inter-finance systems mostly, some government. Sometimes they pin the CA issuer, sometimes IP based although with dynamic cloud IPs that is disappearing, sometimes inside a VPN, and other times just the cert issues themselves. Same service handing public users while making bidirectional API ca…

I think part of the issue could be with the naming - 'public PKI'. I'd argue that doesn't really exist anymore - the nomenclature in use for some time now is 'web PKI'.

It's now ostensibly an ecosystem for use by modern, updated clients - browsers and OSs - for TLS. clientAuth will be gone from the webPKI soon, too, I hope.

It's fast becoming a more fluid, shifting ecosystem. We'll be on 90-day leaf certs very soon, shorter after that. Roots and intermediates will have much reduced lifetimes. New guidelines and regulations change things rapidly. Mass revocation events like this one.

In the ATC example - all parts of that ecosystem should be managed to the point that distributing a private root is relatively easy. It shields them from events like this. As another commenter has pointed out - running a private CA (or what might be known as an 'ecosystem CA' like we see in IoT with Matter, airlines with CertiPath, wireless with WinnForum) can be done 'as-a-service' easily, be it from a cloud vendor or CA or similar provider.

If folks continue to use the web PKI for non-web purposes, then they have to be in a position to deal with challenges like short-lifetime certs, 24-hour revoke/reissuance windows, and frequently-updated trust stores.

Most of the agreements and T&Cs for public CAs already forbid use in 'critical' systems anyway, so you're effectively agreeing to these kind of 24-hour changes from the start.

Re: DigiCert Revocation Incident (CNAME Domain Validation)

#49

Post by devrand »

nickf wrote: post #45
CaliforniaKarl wrote: post #37

Earlier quoted context omitted.

> Stuff like this is why some parties have been calling for increasingly-shorter cert validity. When a cert is valid for several years it allows companies to develop an increasingly complex workflow around deploying them, sometimes taking weeks and involving dozens of parties to roll them out. This is in turn used as an excuse by CAs to completely ignore the industry standards. "several years"? The certs we are getti…

90 day certificates will be here soon, and moving to shorter lifetimes from there.

Heck, subscribers could go to 10 day certs today (soon 7) and be immune from revocation entirely.

Re: DigiCert Revocation Incident (CNAME Domain Validation)

#50

Post by alex34778 »

crote wrote: post #35
hg35h4 wrote: post #32

Earlier quoted context omitted.

"Alternatively, if companies cannot handle the rotation, then they likely should re-evaluate if WebPKI is even appropriate for their use-case." I hate hearing this awful take, as if every IT organization has the same neat and tidy systems deployed as they do. Never had to deal with 3rd party SaaS vendors certificate pinning requiring service tickets to change, don't have any hardware devices or appliance based softwa…

Stuff like this is why some parties have been calling for increasingly-shorter cert validity. When a cert is valid for several years it allows companies to develop an increasingly complex workflow around deploying them, sometimes taking weeks and involving dozens of parties to roll them out. This is in turn used as an excuse by CAs to completely ignore the industry standards. Those SaaS vendors probably shouldn't be…

I think the issue is less with SaaS vendors doing cert pinning and more that many SaaS vendors offering deploying on customer domains often rely on those same customers to make the DNS changes for validation, and whenever you introduce another party like that it's exponentially more difficult to actually get things done in a timely matter.

IMO they should just use HTTP challenges to avoid this whole thing, but it's a pretty common pattern I see with a lot of SaaS vendors, even major fintechs.

Post reply on HN