Smooth transition to ISRG possible?

Server
1

I wonder how transitioning from DST Root CA X3 to ISRG Root X1 should work smoothly with the current setup of Intermediate CAs.

AFAIK, a typical setup for a transition from Signing CA to Root CA is as follows.

Old Root CA → New Root CA (signed by Old Root CA) → Signing CA → Server Cert

Servers present the three certificates (Server Cert, Signing CA, New Root CA signed by Old Root CA) to clients which are happy either way: If they still trust Old Root CA, the chain passes. Alike, if they have the New Root CA self-signed certificate in their trust store, they just disregard the last certificate and find the new proper matching chain anyway. After some time, servers will stop serving New Root CA (signed by Old Root CA). Mission accomplished.

In the case of the current LE setup… I don’t see such a clean transition ahead. The main issue is the missing “New Root CA (signed by Old Root CA)“ intermediate certificate. Let’s look at an example.

My FF already contains the ISRG Root X1 certificate, and trust is enabled. If I disable trust on DST Root CA X3 temporarily, my LE-enabled site cannot be displayed anymore because I don’t present a certificate for Let’s Encrypt Authority X3 signed by ISRG Root X1. My server sends the certificate for “Let’s Encrypt Authority X3 (IdenTrust cross-signed)”. If I now add the missing certificate “Let’s Encrypt Authority X3, Signed by ISRG Root X1” to the served chain of certs, FF displays the page. Horray!

However, SSL Labs is unhappy and gives a „Chain issues: Incorrect order“ output. Sure, the server sends two different certificates that form a fork instead of a single chain. I can only fix the chain in this regard by removing the old intermediate certificate, but then I have a direct change from the old DST Root CA to the new ISRG Root CA. This is a hard move which I’d not call a smooth transition. Or do we simply have to live with the SSL Labs warning? (Note that SSL Labs also reports an OCSP error for the new certificate, but that’s not the topic here.)

What’s the technical transitioning plan for LE from the old to the new root? Will the current Signing CA certificate be replaced by a Root CA signature, signed again by DST, together with the new non-cross-signed Let’s Encrypt Authority X3?

And, of course, corrections to my understanding welcome :slight_smile:

2 Likes
2

Hi @ecdsa-chacha20,

I think the likely path is that in several years, if user-agent adoption of the ISRG root is widespread enough, users will be given the option to serve a different chain, which will potentially not work with some older user-agents. This is a slow process and doesn’t guarantee 100% compatibility.

3

You’ve definitely identified an issue, and one we’ve been thinking about. It will be a couple of years before we are ready to recommend that server operators serve a chain to ISRG Root X1 instead of DST Root X3. When that time comes, one of the options we’ve considered is seeking another cross-signature, this time on ISRG Root X1.

Thanks for bringing this up, and putting together such a detailed description of the issue!

3 Likes
4

Is it really that much of a deal that “SSL Labs” is “unhappy”?

I.e., Firefox is happy, other browsers hopefully will be too?

5

@jsha, thanks for your reply. That’s what I was worried about.

Then, why not create the cross signature for ISRG Root X1 in the near future and let anybody serve that chain soon? This way we could profit from the new ISRG Root X1 in browsers now. Otherwise admins will ‘never’ make the hard change to ISRG Root X1 due to the compatibility issue with old client setups.

Or perhaps rethink the ISRG Root approach from the bottom once ECDSA or even EdDSA for Signing/Root CA is on the table, and stay with the DST Root for the RSA chains ‘forever’.

6

@Osiris, it’s not just SSL Labs we have to make happy. Here is an excerpt from RFC5246:

certificate_list
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certificate authority MAY be omitted from the chain, under the
assumption that the remote end must already possess it in order to
validate it in any case.

So it is not RFC conformant to send out both certificates for Let’s Encrypt Authority X3, one cross-signed by IdenTrust DST Root CA X3, one signed by ISRG Root X1.

2 Likes
7

If this norm had never existed (including in implementation logic), the CA ecosystem might look very different! For example, it could have been safer to experiment with more decentralized trust establishment, like in Monkeysphere, while still maintaining compatibility with people whose user-agents use traditional CAs.

http://web.monkeysphere.info/

The rule that a server can only send a single chain tends to entrench the power of the existing CAs, because if you want broad compatibility, you'll have to send a chain based in one of the most widely-propagated roots.

1 Like
8

There are plans to relax the restrictions on certificate_list in TLS 1.3 (currentlly a draft):

   certificate_list  This is a sequence (chain) of CertificateEntry
      structures, each containing a single certificate and set of
      extensions.  The sender's certificate MUST come in the first
      CertificateEntry in the list.  Each following certificate SHOULD
      directly certify one preceding it.  Because certificate validation
      requires that trust anchors be distributed independently, a
      certificate that specifies a trust anchor MAY be omitted from the
      chain, provided that supported peers are known to possess any
      omitted certificates.

…

   Note: Prior to TLS 1.3, "certificate_list" ordering required each
   certificate to certify the one immediately preceding it, however some
   implementations allowed some flexibility.  Servers sometimes send
   both a current and deprecated intermediate for transitional purposes,
   and others are simply configured incorrectly, but these cases can
   nonetheless be validated properly.  For maximum compatibility, all
   implementations SHOULD be prepared to handle potentially extraneous
   certificates and arbitrary orderings from any TLS version, with the
   exception of the end-entity certificate which MUST be first.
3 Likes
9

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