Expiration or revokation of DST Root CA X3

Help
1

We have an embedded system (client) that will communicate with a server using letsencrypt. The client validates the certificate by verifying the certificate chain using the public key of “DST Root CA X3.” This has been tested and works well right now. I have questions however about how to keep this system working in the future:

  1. My understanding is that DST Root CA X3" will expire Thu 30 Sep 2021 02:01:15. how can I confirm this?
  2. How many days/weeks/months in advance of this expiration will a replacement for DST Root CA X3 be issued?
  3. What is the protocol in the extremely unlikely chance that DST Root CA X3 is compromised? Is a new root certificate immediately issued and the compromised certificate immediately revoked? I see this as a potential problem for our system because it will have no way to get the new certificate if the old is no longer working and there is no lead time to make the switch.
  4. Is there any sort of notification I can sign up for so I can know when I need to update this root certificate and be given the maximum time possible to roll the update to our customers?

My thought is to always store the public keys of 2 root certificates in the embedded system so the system will stay fully functional through any transition from one root certificate to another. The system will always check for new root certificates on boot by communicating with a server via TLS using a letsencrypt certificate. Does this all seem like it would work? I’m rather new to this whole certificate validation thing so any thoughts and advice are welcome… :slight_smile:

2

"DST Root CA X3" belongs to IdenTrust rather than Let's Encrypt, and is used for cross-signing. Perhaps trusting the ISRG Root X1, expiring in 2035, would be more accurate? What is the lifetime of your embedded systems?

There is a useful diagram on this page: Chain of Trust - Let's Encrypt

I suppose your question regarding compromise would still remain.

As an ACME client author I am subscribed to the API Announcements forum (API Announcements - Let's Encrypt Community Support), I am hoping any breaking changes would immediately appear there.

3

That's 02:01:15 PM (UTC), but you're correct.

My guess is that Let's Encrypt will transition straight from DST Root CA X3 to the existing ISRG Root X1 root in 2021. If that's the case, the replacement already has been issued.

For IdenTrust's own purposes, they have other roots expiring in 2034. I imagine they have their own plans to transition their customers, and the money to buy cross-certificates or other roots if necessary.

If Let's Encrypt has other plans, maybe one of the staff will chime in in this thread. :slight_smile:

That would be bad. :grimacing:

Doubtful. If IdenTrust were so badly compromised that an emergency distrust was necessary, they would probably be in no position to have new roots trusted. If some sort of unusual situation resulted in only partial distrust, they might try to switch to one of their other trusted roots ASAP.

To call it "disruptive" would be an understatement.

Roots can't be revoked in the traditional way. Intermediate certificates can be, but roots can only be distrusted via a software update or other mechanism.

Google and Mozilla have other revocation mechanisms -- CRLSets and OneCRL, respectively -- which have and would be used to distrust intermediates when necessary, but I'm unsure if they support revoking root certificates. I imagine Mozilla could push out a hotfix extension, and Google could push out a software update or something else.

Consider the examples of DigiNotar, StartCom and Wosign, and Symantec. One is a small CA that was catastrophically compromised and widely distrusted immediately, leading to significant disruption to many people in the Netherlands and fewer people elsewhere. The others are larger CAs -- too big to fail, if you want to make that accusation -- that had different issues, leading to lengthy investigations and distrust over lengthy transitions period.

Well, since you control root distrust for your platform, the good news is you could keep using a compromised root forever. The bad news is you could keep using a compromised root forever.

Intermediate revocation via CRL or OCSP would be an issue for you -- if you implement it -- but could also lead to the affected CA rapidly switching to a different intermediate with less extreme disruption. (Let's Encrypt maintains a backup intermediate at their secondary data center, for example.)

Consider the recent case of the Logitech Harmony Link. They're bricking thousands or millions of devices in March. Rumor has it Logitech may have backed themselves into a corner with the upcoming Symantec distrust.

It's certainly important and good that you're considering these issues! :smile: I don't know what best practices are. Maybe you should trust several major CAs -- or all of them -- and one or two backup CAs generated by your own organization and kept in safes in case of emergency. I don't know if that's good advice, but as long as you trust a few CAs and have a functional software update mechanism, things ought to work out.

The best options might be to run your own CAs, or even have a backup software update system that doesn't use certificates at all.

4

In an environment where you’re in full control of both the server and client side, where the client devices might last many years and where pushing updates to them in a timely manner could become difficult, the Web PKI might not be the best option for you. There have been a number of cases where changes to the security standards (such as the SHA-1 deprecation) in the Web PKI caused difficulties for vendors of, as an example, payment terminals. Publicly-trusted CAs were forbidden from issuing SHA-1 certificates, but these terminals did not support any other hash algorithms. Software upgrades were often not possible and replacement of the physical terminals took years.

My recommendation would be to either use a private PKI (i.e. a set of custom roots generated by you - maybe one RSA and one ECDSA root), or to at least have a private root included in your trust store so you can switch to it if your CA is distrusted, stops operating or is forced to become incompatible with your devices. If you go with Let’s Encrypt for that role, I would include the DST Root CA as well as the ISRG Root X1.

Another operational trick I’ve seen in this space is to use separate server domains per (major) hardware/software/product revision, whichever is most appropriate. This allows you to upgrade things like cipher suites for newer devices that support them (for example when older cipher suites are broken), or deploy a different PKI only for older products that are incompatible with some upcoming change.

4 Likes
5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.