Please update the "Certificate Compatibility" page to include information about the new ISRG roots


#1

This page on Let’s Encrpt’s website documents what systems Let’s Encrypt’s certificates are and are not compatible with: https://letsencrypt.org/docs/certificate-compatibility/

The page currently says:

The main determining factor for whether a platform can validate Let’s Encrypt certificates is whether that platform includes IdenTrust’s DST Root X3 certificate in its trust store.

Since Let’s Encrypt is transitioning to ISRG’s root, this will no longer be true in the near future.

Could someone at Let’s Encrypt please update that page to indicate what clients will and will not be compatible with Let’s Encrypt once the transition to ISRG’s roots is complete? The existing compatibility information for IdenTrust’s roots should also be retained until such a time as using those roots is no longer an option.


What's the truth of device compatibility without cross-signing?
#2

The website is on Github if you have suggestions: https://github.com/letsencrypt/website :wink:


#3

Since the both intermediate certificate are using the same private key, machines that does not support new ISRG signed certificate should still be able to pull the DST one (from a alt-link inside the ISRG certificate) and continue to trust it until 2021 (when the intermediate certificate expires OR the DST root certificate expries).

Thank you


#4

Correct. Having up-to-date information on what systems are supported by what roots would be helpful in deciding whether or not that step is necessary for any particular site.


#5

There is a mechanism in some browsers that will automate alternative trust path building (so that if a browser caches and trusts the DST intermediate, it can still use it even if the site suggests the ISRG intermediate), although I haven’t heard of the “alt-link” that you suggest. Currently the ISRG intermediate cert doesn’t mention or refer to the DST intermediate in any way:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            d3:b1:72:26:34:23:32:dc:f4:05:28:51:2a:ec:9c:6a
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Internet Security Research Group, CN=ISRG Root X1
        Validity
            Not Before: Oct  6 15:43:55 2016 GMT
            Not After : Oct  6 15:43:55 2021 GMT
        Subject: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus: [...]
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.2.1
                Policy: 1.3.6.1.4.1.44947.1.1.1
                  CPS: http://cps.root-x1.letsencrypt.org

            X509v3 Subject Key Identifier: 
                A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1
            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://crl.root-x1.letsencrypt.org

            Authority Information Access: 
                OCSP - URI:http://ocsp.root-x1.letsencrypt.org/
                CA Issuers - URI:http://cert.root-x1.letsencrypt.org/

            X509v3 Authority Key Identifier: 
                keyid:79:B4:59:E6:7B:B6:E5:E4:01:73:80:08:88:C8:1A:58:F6:E9:9B:6E

    Signature Algorithm: sha256WithRSAEncryption [...]

#6

That’s great! Unfortunately I don’t actually know what devices are and are not supported by the new root, so I wouldn’t be able to make that change myself. Would you like me to file an issue so this doesn’t get lost?


#7

Yep, we will update that page soon. Thanks for the suggestion.

There are two mechanisms:

  1. If a browser has seen the DST Root X3-signed copy of the Let’s Encrypt Authority X3 intermediate, it will cache it for some amount of time for use in future chain building. This is why sites that don’t send a full chain sometimes work and sometimes doesn’t. It makes chain issues notoriously hard to debug!
  2. A certificate can contain an “Authority Information Access” section with a “CA Issuers” URL that allows fetching the parent certificate if it’s not in the chain. To make effective use of this, we would have to get a second cross-sign, this time on ISRG Root X1, instead of on Let’s Encrypt Intermediate X3, and provide that cross-signed root at the AIA CA Issuers URL in our intermediates. That would let browsers that don’t have our root in their root store download a cross-signed copy of our root so they could trust it.

Unfortunately AIA CA Issuers is not implemented by Chrome on Android, which is the main source of compatibility issues. And this technique could not extend trust beyond the expiration of DST Root X3 anyhow. So right now we don’t plan to pursue that path.


#8

Can’t we just include both intermediate on fullchain.pem? both DST Root X3 and ISRG Root X1. I think most things supports branchs in certificate path.

for exemple:

-----BEGIN CERTIFICATE-----
[lets-encrypt-x3-cross-signed.pem]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[lets-encrypt-x3.pem]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[end Cert for site]
-----END CERTIFICATE-----


#9

@orangepizza, unfortunately Internet standards don’t currently allow that (although indeed many clients will accept it). I believe there are a few clients that will actively reject it, so it might create a trade-off where compatibility increases in some areas yet decreases in others.