nickf

Then the CA goes away, like Entrust. Huge problems. I speak (sadly) from experience.

Don't forget the lede buried here - you'll need to re-validate control over your DNS names more frequently too. Many enterprises are used to doing this once-per-year today, but by the time 47-day certs roll around, you'll be re-validating all of your domain control every 10 days (more likely every week).

This. Also, re-evaluate how many places you actually need public trust that the webPKI offers. So many times it isn't needed, and you make problems for yourself by assuming it does. I have horror stories I can't fully disclose, but if you have closed networks of millions of devices where you control both the server side and the client side, relying on the same certificate I might use on my blog is not a sane idea.

I've said it up-thread, but never ever never never pin to anything public. Don't do it. It's bad. You, and even the CA have no control over the certificates and cannot rely on them remaining in any way constant. Don't do it. If you must pin, pin to private CAs you control. Otherwise, don't do it. Seriously. Don't.

Certificate pinning to public roots or CAs is bad. Do not do it. You have no control over the CA or roots, and in many cases neither does the CA - they may have to change based on what trust-store operators say. Pinning to public CAs or roots or leaf certs, pseudo-pinning (not pinning to a key or cert specifically, but expecting some part of a certificate DN or extension to remain constant), and trust-store limiting are all bad, terrible, no-good practices that cause havoc whenever they are implemented.

'Most likely' - with the exception of Apple enforcing 825-day maximum for private/internal CAs, this change isn't going to affect those internal certificates.

Curious as to why it’s that many inserts? The whole CT ecosystem has about 30-40,000 new certs/precerts a minute IIRC). Love merkelmap though!

No, SSLCorp are hosting and managing a CA with Entrust branding. Same as Sectigo are doing. Entrust aren't doing issuance, verification - they're straight reselling from white-labeled issuing CAs.

Just to be clear, the whole incident covered over 80,000 certificates. The TRO was applicable to only those of one subscriber - just over 70 certificates, yet caused the revocations of all 80k+ to be delayed.

Perhaps, but only in the case that the delayed revocations were scoped to those certificates covered by the TRO, and not over 1000x more from subscribers who had nothing to do with the company who filed the TRO.

Nothing public to point to, sorry.

Sub-CAs: Not really. Operational risk to the parent CA is huge, you'd be hard pressed to get any current public CA to sign an issuing CA to be operated externally. Cross-signing still works (though it is the stuff of nightmares in many cases) but again you have to have money and a CA willing to do it!

The parent was correct - it's not about the company not using x509 certificates, but not using publicly trusted certificates. There are myriad private/internal PKI solutions available from OpenSSL & bash to millions of dollars of solutions from Big Vendor. If you can't replace the publicly-trusted certificate quickly, you probably don't need it to be publicly-trusted in the first place.

No, Sectigo is the PKI business that was carved out of Comodo, back in 2017. Comodo still exists, doing whatever they do. They have been totally separate entities since then.

Time and money. Plus right now even if you bought the infra, the staff, paid for and passed the audits, and then waiting while Apple, Mozilla, Google and Oracle (at least) included your roots...Microsoft aren't taking more right now. So you have to wait for some unknown time in the future when/if they start doing that again. You could purchase a root off an existing CA, subject to the trust stores approving it, and the boatload of cash you'd need to buy it (plus still having the staff and infra to operate it).

Probably 47 days mandatory maximum, hopefully by 2029.

EV codesigning has been gone for almost a year now. MS said it no longer makes a difference.

Server certs will be losing the clientAuth EKU this year, so those will be out. SMIME certs may start to drop it too. I don’t know many CAs that will do a clientAuth only cert from a public CA, largely because it’s unnecessary. If it’s for auth, use a private CA.

Opera do. Cisco have their own. Oracle do (for Java, primarily) but tend not to participate in CA/B Forum much. Brave did previously have something of a root program - not sure if they still do or if they track Moz and/or Chromium. Quihoo 360 (China) have a root program, too. There are certainly other 'smaller' ones.

Do not pin to publicly-trusted certificates. It is a bad, bad idea. The roots, CAs and even the keys you might pin to are not within your control and can change with little or no notice. Certificate lifetimes are being driven down, too. Don’t do this.

The domain verification process is indeed a weak point - but there's now the upcoming introduction of MPIC (Multi Perspective Issuance Corroboration) to help with that (essentially checking the domain challenges from multiple network perspectives to overcome the risk of BGP-hijacking and similar attacks).

Also, if there's a non-internet connected network or device that uses TLS, it shouldn't be using public/webPKI certificates. Use a private CA, get the root on the managed devices that connect to it, and the problem goes away. That's always been an option.

I'm not sure how you think certificates work? It's not for 'yourself' - the certificate is an assertion to billions of users worldwide, called relying parties. If you don't care about those, then you can use a private CA. If you do care (and want anyone's browser to work) then it's not a 'personal freedom'.

A phased approach to reducing the validity of TLS server certificates over the next two or three years, ending at a 45-day certificate lifetime by early 2027.

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.

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

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

PSL has a couple of sections - ICANN and PRIVATE. PRIVATE can be a little more flexible/ignorable. If they implement a hard rule, then occasionally they'd have to make exceptions when the real Dyn comes along and wants (legitimately) a wildcard for their name.

Like SMTP/IMAP etc? That would make sense, though I'm not sure how much revocation checking even happens there.

You could start with this: https://crt.sh/ocsp-responders

What non-HTTP services need publicly-trusted certificates and care about revocation?

Try datatables.net - they have a sample 'server' (in PHP, plus more you can find on Github) that allow for dynamic search/filtering.