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

31–40 of 56 posts

Re: DigiCert Revocation Incident (CNAME Domain Validation)

#31

Post by agwa »

agwa wrote: post #5

> The underscore prefix ensures that the random value cannot collide with an actual domain name that uses the same random value. While the odds of that happening are practically negligible, the validation is still deemed as non-compliant if it does not include the underscore prefix. That's not the rationale for mandating the underscore prefix. The actual reason is so services that allow users to create DNS records at…

> 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

Re: DigiCert Revocation Incident (CNAME Domain Validation)

#32

Post by hg35h4 »

devrand wrote: post #27
ratg13 wrote: post #14

24h notice to change certificates in who knows how many systems, at the worlds largest companies, while everyone is on vacation. This will be interesting.

Respect to them for actually abiding by the BRs. Most CAs just shrug [1] and [2] say [3] it's [4] too [5] complicated [6], or just lie and claim planes will start crashing [7]. It's really disheartening that publicly trusted CAs just ignore their contractual obligations however they see fit. Ideally these companies should have response plans in place to prioritize certificate rotation. They can use this as a fire dri…

"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 software images each with their own web interface to update certs...

Yes companies should have a plan to do their minimum yearly certificate rotates. Yes those companies should have a security plan to rotate affected certificate issues, but in those cases the business users are ok with an outage to remediate a real security issue.

But what happened here is that Digicert invalided the entire domain's worth of certs. All those service.companyname.com certs or duplicates under that domain validation were affected in bulk. In some companies there could be thousands of certs under that domain. Digicert screwed up their system implementation and made their customers suffer.

"It's really disheartening that publicly trusted CAs just ignore their contractual obligations however they see fit."

It's also disheartening to see browsers in the CA consortium ignore the CA resolutions as well. Like how everyone voted for 2 year certs and Apple did their own thing anyways. Any punishment for Apple come? So why pick on the others?

Re: DigiCert Revocation Incident (CNAME Domain Validation)

#33

Post by devrand »

devrand wrote: post #27
ratg13 wrote: post #14

24h notice to change certificates in who knows how many systems, at the worlds largest companies, while everyone is on vacation. This will be interesting.

Respect to them for actually abiding by the BRs. Most CAs just shrug [1] and [2] say [3] it's [4] too [5] complicated [6], or just lie and claim planes will start crashing [7]. It's really disheartening that publicly trusted CAs just ignore their contractual obligations however they see fit. Ideally these companies should have response plans in place to prioritize certificate rotation. They can use this as a fire dri…

Spoke too soon... seems like subscriber(s?) issued DigiCert a Temporary Restraining Order to not revoke: https://bugzilla.mozilla.org/show_bug.cgi?id=1910322#c8

Bold.

Re: DigiCert Revocation Incident (CNAME Domain Validation)

#34

Post by devrand »

hg35h4 wrote: post #32
devrand wrote: post #27

Earlier quoted context omitted.

Respect to them for actually abiding by the BRs. Most CAs just shrug [1] and [2] say [3] it's [4] too [5] complicated [6], or just lie and claim planes will start crashing [7]. It's really disheartening that publicly trusted CAs just ignore their contractual obligations however they see fit. Ideally these companies should have response plans in place to prioritize certificate rotation. They can use this as a fire dri…

"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 ultimately may make it impossible for an organization to complete that work in the revocation window. That is very much an area that needs further automation developed and more importantly, for it to actually be adopted. I believe that's what ACME Renewal Information is attempting to address.

"but in those cases the business users are ok with an outage to remediate a real security issue"

Ideally yes, but that might be the same point you find out the certificate was used in some critical system (let's say Air Traffic Control like a previous CA tried to claim). They still may very well not be okay with the revocation despite the security issue. _Those_ are the people that need to stop using these certificates and there's really no way to weed them out until a revocation actually needs to occur.

"Digicert screwed up their system implementation and made their customers suffer."

And those customers are right to be mad at DigiCert. They probably don't have a legal basis to challenge as the subscriber agreement explicitly permits immediate revocation without prior notice, but they can certainly take their business elsewhere.

"It's also disheartening to see browsers in the CA consortium ignore the CA resolutions as well. Like how everyone voted for 2 year certs and Apple did their own thing anyways. Any punishment for Apple come? So why pick on the others?"

Admittedly I'm not very familiar with the various root programs and the obligations they have with CAs, but it doesn't seem unreasonable that root programs would be free to impose stricter requirements then the BRs.

Though I do find it two-faced for Apple to vote for Ballot 193 only to then impose a stricter requirement. At the very least they should have abstained.

Re: DigiCert Revocation Incident (CNAME Domain Validation)

#35

Post by crote »

hg35h4 wrote: post #32
devrand wrote: post #27

Earlier quoted context omitted.

Respect to them for actually abiding by the BRs. Most CAs just shrug [1] and [2] say [3] it's [4] too [5] complicated [6], or just lie and claim planes will start crashing [7]. It's really disheartening that publicly trusted CAs just ignore their contractual obligations however they see fit. Ideally these companies should have response plans in place to prioritize certificate rotation. They can use this as a fire dri…

"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 doing cert pinning to begin with. If you don't trust your root store either implement support for CAA or DANE, no need to roll out your own workflow. Those hardware devices should either 1) not use publicly trusted certs, 2) renew their own certs, or 3) have an API to automatically update certs.

The only reason they're still getting away with it is because doing it manually once a year isn't horribly painful. If 90-day validity becomes the industry standard, pain-free certificate renewal turns into a must-have for all new contracts.

Re: DigiCert Revocation Incident (CNAME Domain Validation)

#36

Post by CaliforniaKarl »

agwa wrote: post #31
agwa wrote: post #5

> The underscore prefix ensures that the random value cannot collide with an actual domain name that uses the same random value. While the odds of that happening are practically negligible, the validation is still deemed as non-compliant if it does not include the underscore prefix. That's not the rationale for mandating the underscore prefix. The actual reason is so services that allow users to create DNS records at…

> 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.

Re: DigiCert Revocation Incident (CNAME Domain Validation)

#37

Post by CaliforniaKarl »

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…

> 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 getting have one-year lifetimes. It used to be two years, but was reduced to one year some time ago (I don't remember exactly when).

Also, I don't think the problem is cert lifetimes, I think the problem is having so many certs expiring all at the same time. A lot of IT folks are coming off the major pain of the CrowdStrike crash. This is similar: You suddenly have a very large number of certificates that are going to stop working in less than 24 hours, and you have to respond.

Sure, you could say "Well, companies should be resourced to be able to handle that at any point." Except that's not the reality right now.

Re: DigiCert Revocation Incident (CNAME Domain Validation)

#38

Post by olliej »

One of the impacted companies filed a restraining order, because they believe their incompetence is more important than basic functionality of the PKI. Can't wait to hear how they expect to respond if they ever have encounter a cert compromise or actual misissuance, maybe they'll demand 24 hour revocation in that case?

Honestly my opinion is that this should trigger the company being banned by all CAs.

The company in question is Alegeus Technologies LLC: https://www.courtlistener.com/docket/68995396/alegeus-techno...

From basic googling it looks like a healthcare provider, so exactly the kind of company you would want to have shitty IT and security infrastructure. A++ work. Absolutely stellar.

Re: DigiCert Revocation Incident (CNAME Domain Validation)

#39

Post by devrand »

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…

I think they're suggesting that 1 year certificates are still at the point where people can just manually rotate them as they expire. If you keep reducing the lifespan, to say 90 days, that starts to tip the scale. You'll be spending too much human time manually rotating certificates that it will make financial sense to just automate the process.

If the process is automated then revocation can be automatically handled as well (so long as ARI gains traction).

Re: DigiCert Revocation Incident (CNAME Domain Validation)

#40

Post by icedchai »

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…

I work with customers that typically take 3 or 4 days to either acquire or renew a cert. Even though they are on one of the major cloud provider with automated certs, they refuse to use those mechanisms due to policy. They would rather send everything, including private keys, through email. They also take several days, sometimes weeks, to update a DNS entry. Welcome to modern IT.
Post reply on HN