Detailed 2020 hierarchy

Issuance Tech
1

Hi everyone,

Thanks for the great feedback in Let's Encrypt new hierarchy plans. We’re much closer to our key ceremony now. I’ve put together a detailed demonstration at https://github.com/letsencrypt/2020-hierarchy-demo. I’ve attached sample output from a run here, along with OpenSSL textual output. If you see any flaws, please let us know!

Notable things:

  • We’re continuing to use X1 / X2 to identify roots.
  • We’re using O=Let’s Encrypt, CN=E1, E2, R3, and R4 to identify intermediates, where E/R indicates the key type, and we chose non-overlapping numbers across key types to make the names even easier to visually distinguish.
  • We’re using P-384 for our ECDSA hierarchy. We will continue to issue both P-256 and P-384 end-entity (leaf) certificates.
  • Per Ballot SC31, we are not including OCSP URLs in our intermediates. This makes them smaller (for faster handshakes) and also simplifies our operations. The ballot has passed. We plan to perform the ceremony after the ballot’s review period has also passed and it takes effect.
  • We’re adopting a new domain for URLs in certificates: lencr.org. This saves some bytes.
  • For intermediates, we are just including CPS OIDs, not CPS URLs. Our end-entity certificates contain our CPS URL, so including it in the intermediates uses bytes unnecessarily.

Here’s example output from our demo:

root-x2.cert.pem.txt

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            73:dc:e1:40:df:b1:c6:9e:5b:27:b9:28:2a:26:27:c2
        Signature Algorithm: ecdsa-with-SHA384
        Issuer: C = US, O = Let's Encrypt, CN = (FAKE) Let's Encrypt Root X2
        Validity
            Not Before: Sep  4 00:00:00 2020 GMT
            Not After : Sep 17 16:00:00 2040 GMT
        Subject: C = US, O = Let's Encrypt, CN = (FAKE) Let's Encrypt Root X2
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (384 bit)
                pub:
                    04:2d:82:a6:93:d5:dd:a2:8f:60:45:7e:bc:c5:e9:
                    2d:35:90:82:1a:73:4c:7f:90:31:81:e8:d3:7c:01:
                    59:2b:be:7c:ec:b2:3b:6b:47:74:05:f6:0a:50:88:
                    f2:6e:82:8e:e4:d3:48:17:2c:cc:fe:c0:17:f0:dc:
                    6e:4d:47:9d:7e:b6:28:41:dd:6c:5a:df:ae:98:82:
                    20:5a:b5:de:1f:ad:3f:32:cd:d5:e2:79:08:c5:fc:
                    95:bb:e5:f7:60:81:68
                ASN1 OID: secp384r1
                NIST CURVE: P-384
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier: 
                EF:0F:1E:6E:5C:16:E2:A0:46:E5:0D:5D:18:31:EE:45:1D:E5:22:EC
    Signature Algorithm: ecdsa-with-SHA384
         30:65:02:31:00:bf:13:fb:b9:a7:cd:0c:44:9d:80:3e:cc:e9:
         06:ef:80:14:2a:9a:09:0c:7a:8a:94:3a:f7:5e:cb:43:49:5b:
         5b:84:03:a1:bd:7a:18:5a:11:9a:c7:1d:92:fe:72:17:ee:02:
         30:28:96:1c:81:fc:de:e1:a6:05:63:89:70:70:3b:65:17:72:
         c4:53:cc:0f:28:a0:a8:8e:6f:d4:69:b7:f0:8d:d1:95:78:ef:
         fe:80:71:e1:a0:34:b9:cb:a2:f0:1b:75:ff

x2-signed-by-x1.cert.pem.txt

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            bc:6f:22:b5:36:99:82:6e:b0:bb:25:52:62:91:d9:a8
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Internet Security Research Group, CN = (FAKE) ISRG Root X1
        Validity
            Not Before: Sep  4 00:00:00 2020 GMT
            Not After : Sep 15 16:00:00 2025 GMT
        Subject: C = US, O = Let's Encrypt, CN = (FAKE) Let's Encrypt Root X2
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (384 bit)
                pub:
                    04:2d:82:a6:93:d5:dd:a2:8f:60:45:7e:bc:c5:e9:
                    2d:35:90:82:1a:73:4c:7f:90:31:81:e8:d3:7c:01:
                    59:2b:be:7c:ec:b2:3b:6b:47:74:05:f6:0a:50:88:
                    f2:6e:82:8e:e4:d3:48:17:2c:cc:fe:c0:17:f0:dc:
                    6e:4d:47:9d:7e:b6:28:41:dd:6c:5a:df:ae:98:82:
                    20:5a:b5:de:1f:ad:3f:32:cd:d5:e2:79:08:c5:fc:
                    95:bb:e5:f7:60:81:68
                ASN1 OID: secp384r1
                NIST CURVE: P-384
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier: 
                EF:0F:1E:6E:5C:16:E2:A0:46:E5:0D:5D:18:31:EE:45:1D:E5:22:EC
            X509v3 Authority Key Identifier: 
                keyid:81:4D:1F:28:4A:B0:CA:6F:1C:74:26:51:6F:40:65:2E:C3:22:35:41

            Authority Information Access: 
                CA Issuers - URI:http://x1.i.lencr.org/

            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://x1.c.lencr.org/

            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.2.1
                Policy: 1.3.6.1.4.1.44947.1.1.1

    Signature Algorithm: sha256WithRSAEncryption
         17:3e:88:48:d7:52:92:81:b6:51:c8:c8:2d:3a:7b:c3:ab:15:
         ab:68:0b:73:a9:b7:9e:f9:43:07:28:73:98:e4:f9:68:f3:02:
         d1:4f:29:0f:12:41:0b:dc:a6:15:5e:1a:7e:62:35:81:71:bc:
         7d:9a:32:b4:85:68:fb:7d:56:66:40:52:09:d8:71:f6:91:46:
         cd:18:b2:f3:5a:55:86:09:aa:ee:ec:17:3a:fd:78:70:6c:c6:
         e5:3b:c8:6b:39:09:68:35:cd:66:34:9a:22:17:54:b8:b0:40:
         42:b8:7e:c8:b0:00:07:23:a3:30:9d:d6:d0:de:1b:ce:1a:92:
         da:fd:e3:05:72:20:ae:60:bf:9a:a7:b2:04:a7:3f:00:1a:93:
         4c:6a:52:11:d9:98:2d:33:78:d2:e3:d2:ff:b7:04:6d:09:ae:
         b1:18:66:81:77:28:e9:55:1f:81:2b:2a:df:37:ef:2d:89:4b:
         cb:26:74:50:4a:d5:c5:14:f0:94:57:90:c1:79:ee:65:d3:94:
         37:d6:b8:15:38:fa:6b:95:46:e3:db:79:f2:19:59:67:a4:74:
         d4:1f:fc:38:76:35:55:b1:b8:f5:91:5c:18:fa:c4:9f:bd:29:
         01:b4:f8:46:0e:32:6b:cc:51:5f:66:9d:01:0a:00:15:ce:d8:
         5f:b6:4b:00:df:a6:d6:e4:51:eb:d5:8b:5c:3f:39:af:ad:3f:
         fe:24:0d:2a:7b:d1:15:6d:e5:2c:8d:e7:88:4f:25:b8:71:dc:
         13:e7:36:44:30:f3:ac:32:85:72:41:ae:19:94:2b:75:f7:27:
         e3:a7:75:df:63:16:0a:98:5d:29:1c:a5:eb:87:e4:6f:63:6a:
         89:6a:91:a4:0a:9f:9a:31:1a:7f:ed:4a:e1:3e:60:72:5c:f9:
         60:a1:8e:e6:f6:e5:b5:ca:af:da:37:42:b1:07:81:da:8c:fe:
         08:24:0d:7e:cb:bb:e2:e3:f5:d2:63:ec:c5:41:fa:cf:f0:be:
         f0:8c:f9:ca:41:7e:a3:ba:6c:84:76:4d:28:25:3d:5a:60:4c:
         11:8d:1a:f2:22:a3:b0:74:bb:84:91:18:42:16:be:cc:80:92:
         9e:a7:a8:7a:01:ab:30:c5:95:65:f0:1f:64:45:52:8f:cd:3b:
         a8:b1:0c:29:0a:d8:f0:f6:d4:6a:4b:d0:f0:98:22:7c:3b:3d:
         d7:c9:6b:1d:c8:04:b0:a9:32:87:15:1f:ee:47:ce:07:2a:11:
         b0:8d:11:2b:51:cb:11:db:aa:f5:37:7a:c3:7e:e7:22:4d:05:
         54:ac:f3:88:f0:f6:33:7d:08:17:ba:78:1f:6f:2f:86:b5:d3:
         1a:d3:fd:bb:b4:29:c0:05

root-x2.crl.pem.txt

Certificate Revocation List (CRL):
        Version 2 (0x1)
        Signature Algorithm: ecdsa-with-SHA384
        Issuer: C = US, O = Let's Encrypt, CN = (FAKE) Let's Encrypt Root X2
        Last Update: Sep  4 00:00:00 2020 GMT
        Next Update: Aug  4 00:00:00 2021 GMT
        CRL extensions:
            X509v3 Authority Key Identifier: 
                keyid:EF:0F:1E:6E:5C:16:E2:A0:46:E5:0D:5D:18:31:EE:45:1D:E5:22:EC

            X509v3 CRL Number: 
                100
No Revoked Certificates.
    Signature Algorithm: ecdsa-with-SHA384
         30:65:02:30:31:fb:c7:23:c5:98:55:a8:7b:b7:4b:bc:05:02:
         37:70:37:f8:40:63:bf:ab:cf:2f:30:63:11:94:0d:b7:26:f1:
         7d:f3:4e:14:77:6d:8b:59:7a:a8:bd:ed:47:4a:b7:b6:02:31:
         00:db:bd:44:c5:0d:bd:2b:fc:5d:1b:5a:ad:1e:e9:89:d2:9f:
         74:6d:69:9b:62:8a:48:ae:53:1b:42:b3:e5:07:b9:41:88:c8:
         42:2d:e3:38:b7:d4:ee:f7:8c:3a:87:0e:6b

int-e1.cert.pem.txt

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            e2:ca:7c:fb:8d:85:bd:fb:27:24:35:76:96:e9:8a:a3
        Signature Algorithm: ecdsa-with-SHA384
        Issuer: C = US, O = Let's Encrypt, CN = (FAKE) Let's Encrypt Root X2
        Validity
            Not Before: Sep  4 00:00:00 2020 GMT
            Not After : Sep 15 16:00:00 2025 GMT
        Subject: C = US, O = Let's Encrypt, CN = (FAKE) E1
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (384 bit)
                pub:
                    04:e5:33:6e:b9:0f:65:96:98:81:12:e0:2e:ba:d1:
                    ff:38:3d:74:f1:88:06:27:48:e6:44:79:50:d2:55:
                    d3:d8:8e:78:0e:2b:72:ad:98:8c:2b:53:89:8c:7d:
                    2b:99:f3:9a:88:5a:74:02:f5:d3:d0:2d:21:4f:5b:
                    73:b5:a0:e2:5d:81:14:76:0a:7c:43:af:76:60:82:
                    1c:49:3a:e6:c7:87:68:a3:2f:80:c4:6c:09:c5:1c:
                    bc:60:50:8c:ac:aa:a7
                ASN1 OID: secp384r1
                NIST CURVE: P-384
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
            X509v3 Extended Key Usage: 
                TLS Web Client Authentication, TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Subject Key Identifier: 
                CD:D6:D8:FC:89:CB:3E:9F:72:B6:5E:DF:F2:D8:0A:A9:01:5D:6D:C3
            X509v3 Authority Key Identifier: 
                keyid:EF:0F:1E:6E:5C:16:E2:A0:46:E5:0D:5D:18:31:EE:45:1D:E5:22:EC

            Authority Information Access: 
                CA Issuers - URI:http://x2.i.lencr.org/

            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://x2.c.lencr.org/

            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.2.1
                Policy: 1.3.6.1.4.1.44947.1.1.1

    Signature Algorithm: ecdsa-with-SHA384
         30:64:02:30:30:51:4a:b7:ce:cc:d6:29:49:0e:d0:a3:a3:57:
         56:45:6f:5e:1f:26:13:98:cf:8e:8e:9d:3a:3e:4a:43:d9:2a:
         a5:e7:bb:10:93:66:10:02:22:92:98:2f:4d:1d:8b:89:02:30:
         6a:06:63:58:85:0b:ed:77:20:1c:60:7a:59:c3:1b:89:e1:64:
         af:3a:7e:13:70:e7:8d:78:75:3b:f7:c2:b8:ab:e2:91:1e:45:
         eb:13:67:ad:ef:01:b5:85:b0:5c:19:c2

int-e2.cert.pem.txt

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            5e:fe:48:a6:4a:fa:2e:1f:e7:09:1e:4d:fd:d1:e5:b6
        Signature Algorithm: ecdsa-with-SHA384
        Issuer: C = US, O = Let's Encrypt, CN = (FAKE) Let's Encrypt Root X2
        Validity
            Not Before: Sep  4 00:00:00 2020 GMT
            Not After : Sep 15 16:00:00 2025 GMT
        Subject: C = US, O = Let's Encrypt, CN = (FAKE) E2
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (384 bit)
                pub:
                    04:aa:58:f7:34:95:8f:ac:70:55:96:33:c2:1a:ad:
                    fe:e1:ff:68:1f:9c:15:29:d2:51:61:bb:76:f0:7c:
                    58:e5:dd:5e:ae:8c:b0:27:43:50:4f:35:48:2e:8a:
                    2d:08:8e:7d:6a:96:d3:2c:e7:d7:bf:f3:4b:3b:6a:
                    5a:b7:b1:34:cb:68:24:b4:84:13:99:1a:82:e9:1a:
                    11:04:03:59:9d:21:a7:eb:13:26:98:cc:9b:af:e1:
                    9c:d9:13:87:cf:5f:62
                ASN1 OID: secp384r1
                NIST CURVE: P-384
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
            X509v3 Extended Key Usage: 
                TLS Web Client Authentication, TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Subject Key Identifier: 
                A2:3F:CA:DE:8A:7D:EA:B4:01:F8:C4:C6:92:D4:50:CC:9B:FB:40:3F
            X509v3 Authority Key Identifier: 
                keyid:EF:0F:1E:6E:5C:16:E2:A0:46:E5:0D:5D:18:31:EE:45:1D:E5:22:EC

            Authority Information Access: 
                CA Issuers - URI:http://x2.i.lencr.org/

            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://x2.c.lencr.org/

            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.2.1
                Policy: 1.3.6.1.4.1.44947.1.1.1

    Signature Algorithm: ecdsa-with-SHA384
         30:65:02:30:0f:96:b2:90:f6:9b:42:e2:60:f7:99:05:44:73:
         2f:a2:e1:1d:dc:e2:f1:23:0a:1e:12:a6:96:72:f1:04:fa:9e:
         0c:de:fc:e5:08:1a:0a:c8:11:22:40:dd:30:cd:f0:3e:02:31:
         00:fb:3d:5c:3e:7a:8d:8d:19:53:63:2f:a1:05:15:3c:15:84:
         67:38:cf:6d:d2:64:02:ce:32:b7:44:ff:7a:9f:60:37:f4:e8:
         a5:02:15:73:a9:5a:0e:25:78:66:ea:b2:1e

int-r3.cert.pem.txt

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            d3:42:da:fa:ea:6f:5c:3c:5c:e6:76:eb:4a:17:18:22
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Internet Security Research Group, CN = (FAKE) ISRG Root X1
        Validity
            Not Before: Sep  4 00:00:00 2020 GMT
            Not After : Sep 15 16:00:00 2025 GMT
        Subject: C = US, O = Let's Encrypt, CN = (FAKE) R3
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:c2:2e:f5:d7:de:40:da:aa:c3:b8:df:3a:fc:4d:
                    64:ec:69:d4:b8:25:89:2d:0a:29:6d:d5:78:02:00:
                    fc:36:87:06:b0:28:98:75:00:a2:ff:c2:03:1b:ab:
                    f7:b5:73:49:bb:31:71:7f:e8:39:17:09:22:a5:6c:
                    8b:f2:e6:4d:0d:5c:1b:12:b5:52:59:fe:5f:ef:05:
                    ff:36:bf:f8:a1:fa:66:f3:1b:74:f4:3e:65:e0:bd:
                    d0:81:32:64:72:a0:d4:f9:e1:88:dd:58:8e:c0:c1:
                    64:96:f2:12:b5:fb:1b:ed:7d:98:34:9b:ef:07:6d:
                    24:1c:79:92:4c:92:a6:a7:be:d2:ee:9f:1b:ae:1e:
                    53:bd:cb:01:1a:04:9c:b0:e9:f5:aa:6f:8f:46:d5:
                    ab:c7:1e:c5:37:90:20:36:07:e1:10:b7:c1:df:18:
                    3d:cc:7f:7f:cc:cc:3a:d4:79:bc:8e:74:c9:e1:09:
                    4e:29:a0:01:14:6b:86:43:0a:b3:9f:4f:48:d8:cf:
                    86:8a:0c:9b:21:27:3c:f2:34:41:15:00:e1:82:7a:
                    44:18:fb:e6:e1:a3:5c:57:61:d4:d6:a7:f1:28:60:
                    a7:f2:8e:12:23:c5:1d:26:4c:3d:53:b7:2e:03:55:
                    ee:0e:01:b1:d3:d1:11:70:7d:bb:85:28:16:32:93:
                    9a:05
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
            X509v3 Extended Key Usage: 
                TLS Web Client Authentication, TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Subject Key Identifier: 
                46:A1:CC:B7:1F:B4:EA:64:51:EB:B2:66:98:79:BF:64:FB:27:78:C4
            X509v3 Authority Key Identifier: 
                keyid:81:4D:1F:28:4A:B0:CA:6F:1C:74:26:51:6F:40:65:2E:C3:22:35:41

            Authority Information Access: 
                CA Issuers - URI:http://x1.i.lencr.org/

            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://x1.c.lencr.org/

            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.2.1
                Policy: 1.3.6.1.4.1.44947.1.1.1

    Signature Algorithm: sha256WithRSAEncryption
         67:16:5f:ed:dd:74:43:30:79:ee:b4:c0:83:0d:4d:9c:b4:7f:
         a6:fe:94:d4:3e:1f:78:15:ee:7a:ef:f0:d5:90:ac:42:fa:61:
         cd:2c:68:5f:e0:fc:ab:cb:e3:a2:ab:24:b7:a6:f1:5d:3b:b1:
         1d:a1:ff:18:40:7e:65:bf:fa:1c:4d:68:f6:29:05:1f:8f:82:
         65:2b:d0:08:d2:fd:32:17:f4:4b:50:6e:83:3f:7a:89:02:d8:
         4e:02:0c:0e:50:1e:45:fb:11:01:87:55:0c:1b:fc:0b:f7:87:
         52:2d:97:1c:b7:8a:a2:89:18:c0:6e:31:8a:a0:c6:ae:93:d2:
         c4:6c:25:8b:8c:e5:5a:25:4b:ee:37:54:a7:ee:b7:e3:78:ba:
         43:36:75:5a:9d:d8:b1:94:1d:3d:26:30:83:26:fa:44:d4:b0:
         95:c3:db:fa:3c:e3:97:ec:b4:9f:1e:51:d2:a0:61:f5:0d:2a:
         8a:54:9c:63:b1:c5:36:79:ec:ce:93:a6:2f:71:cf:ba:50:b6:
         bb:af:f8:85:ec:05:6b:cb:69:c5:2c:76:4d:8d:4c:ee:e7:bf:
         4c:50:c7:90:2a:c8:57:c0:7f:30:ea:23:a3:02:82:f5:9e:1e:
         2a:7d:47:6c:da:83:51:cd:fc:b1:ba:c0:20:77:6f:9d:d4:14:
         39:36:35:ee:7b:60:5b:a9:e5:94:e6:ed:0b:55:63:a7:ed:8d:
         54:97:b6:55:8f:fe:3d:63:d3:4d:3d:22:b6:0f:f0:f7:06:eb:
         92:90:0b:b1:5b:5f:16:75:11:d0:b2:9f:de:db:9d:c8:05:8d:
         5e:80:07:24:a8:35:3b:0d:97:fe:2a:c1:3a:2b:f4:fa:b3:0a:
         b2:21:1b:3c:ab:69:02:a6:aa:ab:0c:5a:a6:74:f2:2c:9c:fc:
         1f:29:41:d9:75:2a:a7:3c:08:57:0e:2b:96:8a:d7:19:73:18:
         5a:31:12:67:0b:b0:1b:14:71:ec:81:e0:14:9f:d3:76:8d:56:
         a1:ce:d2:a8:9a:de:90:34:16:5b:59:54:20:64:76:9f:17:83:
         41:e4:8b:32:a3:e7:67:34:cb:32:8d:ec:7b:e3:cd:a5:8c:34:
         a2:51:53:75:e7:04:e5:2b:72:6c:57:01:23:b3:e5:00:9b:af:
         24:f0:4a:ad:00:f4:41:b0:95:b3:88:b3:c3:c5:77:8f:56:fb:
         88:95:8e:54:d9:95:80:67:5d:59:13:b6:b0:9b:c5:52:f2:55:
         ff:bd:c0:f3:6c:cc:91:e6:15:63:56:67:57:ac:82:d4:9b:62:
         ef:58:2c:f8:08:cf:20:bf:a7:89:27:77:b2:f1:ce:88:0b:f8:
         c4:80:e4:dc:80:76:66:5e

int-r4.cert.pem.txt

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            80:eb:27:8a:56:4a:ca:dd:1c:97:2d:f9:21:df:f2:69
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Internet Security Research Group, CN = (FAKE) ISRG Root X1
        Validity
            Not Before: Sep  4 00:00:00 2020 GMT
            Not After : Sep 15 16:00:00 2025 GMT
        Subject: C = US, O = Let's Encrypt, CN = (FAKE) R4
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:a6:94:05:c4:ad:91:d7:9c:01:8f:d9:54:93:87:
                    bd:7e:e7:1e:80:dc:c3:e4:b5:a9:b9:4e:10:11:7f:
                    85:3c:3a:6e:9f:e5:e7:47:b6:90:df:02:7e:d4:92:
                    bb:7a:8f:6a:54:81:83:65:d1:79:30:bf:dd:e9:24:
                    bb:81:e4:e6:32:50:31:d2:23:61:10:42:4f:8a:13:
                    00:22:4a:38:38:8a:e7:a3:43:d1:3a:14:85:a4:f9:
                    55:30:8f:14:71:cd:a3:75:6b:27:83:5d:95:b7:38:
                    da:d1:7c:df:23:67:1e:33:de:6a:b2:f5:75:5f:4f:
                    2d:d9:83:c9:0d:c3:7b:87:ba:b9:0d:e2:36:00:15:
                    0e:69:4c:1c:d0:cf:b7:a8:b2:b6:13:a2:86:7b:ea:
                    9f:c4:d7:0b:d2:53:b4:55:c2:78:d9:31:00:d1:c1:
                    20:73:51:ef:38:76:9f:39:56:03:5a:5f:32:98:7d:
                    ad:fa:ca:e1:a6:0b:d9:c7:e3:da:20:16:c8:3b:8e:
                    3d:70:d3:9b:eb:fc:44:b2:9d:19:f4:37:f4:08:d9:
                    1b:0c:68:01:c7:f8:77:df:01:f1:33:86:f0:e1:28:
                    b0:a9:1c:12:23:7d:f4:c3:bb:19:8a:7e:7d:71:4f:
                    39:9f:47:69:8d:5a:9c:ba:d7:cf:d3:72:31:03:4f:
                    0d:c7
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
            X509v3 Extended Key Usage: 
                TLS Web Client Authentication, TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Subject Key Identifier: 
                A2:CE:4D:FD:53:6A:4E:BD:87:EF:F5:32:B3:F9:67:E0:47:5E:14:4D
            X509v3 Authority Key Identifier: 
                keyid:81:4D:1F:28:4A:B0:CA:6F:1C:74:26:51:6F:40:65:2E:C3:22:35:41

            Authority Information Access: 
                CA Issuers - URI:http://x1.i.lencr.org/

            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://x1.c.lencr.org/

            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.2.1
                Policy: 1.3.6.1.4.1.44947.1.1.1

    Signature Algorithm: sha256WithRSAEncryption
         09:a4:66:2f:6e:34:b1:c2:35:ec:b2:9a:23:49:00:05:0e:c6:
         8e:31:fb:0f:a3:2b:98:67:cb:c8:42:f9:ce:9d:22:25:67:b8:
         c2:32:ee:bd:4d:0f:45:7f:4d:20:f0:00:a9:9d:9b:0f:f6:77:
         fc:e8:47:d6:16:fa:fb:23:72:6f:62:f1:43:4a:2d:d8:3f:f3:
         fe:c6:c3:4e:5d:81:0c:cf:e7:a6:90:70:fa:cd:07:80:8a:ec:
         d8:b4:4a:26:13:b9:5f:71:f3:a3:c0:f9:4e:0d:1e:70:d1:14:
         25:1a:61:c2:d3:8d:c6:d8:30:ad:23:75:7c:1b:0e:a1:84:d7:
         cb:e0:59:b4:f0:18:d1:19:be:dd:08:6c:26:89:54:ca:9b:3a:
         5e:9a:bf:24:9d:a6:50:a8:5d:90:56:44:f5:b2:30:3a:f8:5f:
         8a:22:3d:df:76:e9:56:b6:d8:84:7d:04:52:ec:40:d6:e9:cf:
         f4:c1:83:44:0f:c9:27:ef:6e:55:e4:67:df:fc:00:ec:7c:61:
         d2:8f:62:7d:3f:3f:ff:b7:e5:ae:be:da:7a:e2:6e:e4:0c:9e:
         e1:16:fe:b6:3b:47:8a:1b:b3:70:3e:a7:33:15:b1:7f:0a:18:
         70:0b:d9:71:63:94:1b:2d:68:a6:a2:71:49:73:25:08:6b:91:
         a5:19:3f:7e:4a:9c:1f:98:2a:c4:76:95:ea:3a:f4:74:20:a1:
         64:2d:6e:b7:fb:72:c4:25:85:fe:5e:aa:97:3a:df:87:81:3d:
         b1:b0:e8:5e:74:c5:65:48:b3:70:c5:81:01:3a:20:71:7f:ea:
         12:42:c2:9b:4c:85:02:37:17:6e:87:a7:d6:41:96:08:25:18:
         d4:5a:65:2a:06:96:e1:2a:e9:76:a0:e0:c5:cb:a7:b8:65:74:
         39:23:0b:f4:de:2e:66:df:d0:34:6b:29:2e:3e:aa:c1:2d:9e:
         e4:35:d5:d7:07:b8:5b:10:fe:b2:f4:f4:f1:8d:8f:ff:ce:fd:
         eb:49:55:dc:51:57:ce:65:b4:be:c9:ca:82:48:2c:fa:bb:1b:
         7e:0f:9d:ca:1b:b3:ee:2b:57:97:f4:cf:aa:f5:5a:e4:c7:28:
         fd:71:47:f4:81:42:50:bb:ab:d2:b6:cf:0d:50:26:08:8b:fc:
         d7:ce:27:c5:23:3d:7b:ea:cd:e2:5f:a1:08:cf:55:67:9b:da:
         15:39:38:34:c0:8b:dd:8c:ed:69:ff:94:92:f9:e4:54:e6:d7:
         9e:31:0c:c4:11:c2:c7:3f:e3:0a:68:d1:5f:d7:32:02:58:fd:
         c2:91:19:fd:71:62:f7:d5:39:fd:cb:3a:a5:81:9f:4b:6d:85:
         cc:39:05:70:c9:0e:b1:8f

[Edit 2020-08-18: Replaced x2-signed-by-x1.cert.pem and .txt with a fixed version]
[Edit 2020-08-31: Re-generated with digitalSignature bit set for all intermediates]

11 Likes
2

Following up this comment … is the new default fullchain for ECDSA certificates going to be (leaf, int-e1, x2-signed-by-x1)?

If so, I’m wondering whether ACME clients are prepared to gracefully deal with more than one issuer in the chain.

5 Likes
3

That's correct.

Hopefully so! But you make a good point that this is something we should try and find out. I'll have the team prioritize alternate chains should be enabled by default · Issue #317 · letsencrypt/pebble · GitHub and Add alternate chains of varying path length · Issue #318 · letsencrypt/pebble · GitHub.

4 Likes
4

A post was split to a new topic: Publish new root certificates soon

6

I’ve updated the top post to change x2-signed-by-x1.yaml to use the new “cross-certificate” ceremony introduced in https://github.com/letsencrypt/boulder/pull/5031. This fixes an issue where the cross certificate has a path length constraint of zero, which would have rendered it non-useful, and it had EKUs when it should not have.

3 Likes
7

Is the plan to follow this process to make a new “fake” hierarchy for the Staging Environment, and leave that for some amount of time before following it for the real new hierarchy?

5 Likes
8

This would be the ideal and I think we can do this. I’ll check in with our SREs about time availability to do this.

6 Likes
9

3 posts were split to a new topic: Certbot support for ECDSA certificates

11

I’m wondering if there’re two root certificates named Let’s Encrypt Root x2, one is self-signed, the other is signed by ISRG Root x1.
Do we have a plan to submit the self-signed one to the major browsers and OS(like Windows, Java,etc.,)?

Is it possible to use sha384WithRSAEncryption or 4096 bit keys to protect the new int-r3 and int-r4 certificates? I think it could provide a better safe protection.

2 Likes
12

Every root cert is self-signed.

i guess the new CA will be submit to the different major browsers soon after it is created.

2 Likes
13

I think I understand what’s happening; please correct me if I get something wrong.

X2 is a brand new root. It’s going to end up getting published to the various browser/OS/etc root stores, after which both the existing X1 and the new X2 will be the true real ISRG/Let’s Encrypt roots, and both will be valid normal roots, it’s just that one is RSA and one is ECDSA.

X1 is the existing root, which hasn’t been used for most purposes directly since it takes time to get into all the root stores, but now it’s been 5 years and is in most places so it can start getting used.

So, in the short-to-medium term (whenever they start using these new certificates, which I think is within the next few months?), RSA leaf certificates will get signed by R3 (or R4), which will be signed by X1. ECDSA leaf certificates will get signed by E1 (or E2), which will be signed by X2, which will be signed by X1.

Longer-term, some number of years from now, once X2 is trusted everywhere that X1 is now, you won’t need that last signature for ECDSA certificates. So leaf ECDSA will get signed by E1 (or E2), which will just be signed by (the self-signed version of) X2.

Did I get that all right?

5 Likes
14

by the way why root cert need to expire at all? If it’s not secure enough like private key leak or crypto break it will removed from trust store, and if it’s still secure but it expired then it will only cause problem to clients.

5 Likes
15

You did a great job explaining things, @petercooperjr! Thanks for that. :slight_smile:

Also worth noting, since we mentioned it in previous posts but not here: We're planning to also get a signature from DST Root X3 -> R3. That will help current Let's Encrypt subscribers who need the additional compatibility provided by that root. They can configure their ACME client to select an alternate certificate chain provided by the server. But that will only be good for about a year because DST Root X3 expires in 2021.

To put this question another way: Currently "Let's Encrypt Intermediate X3" has a 2048-bit key. R3 and R4 will also have 2048-bit keys. Should it be longer? In my opinion, no. Longer keys for our RSA intermediates significantly increase the size of the certificate chain served. And based on currently available knowledge, I believe 2048-bit RSA keys should be safe against factorization for the lifetime of these certificates (5 years).

5 Likes
16

Thanks, I’m glad I’m understanding. So now I have a question, which is really just out of curiosity: If it takes around 5 years before you can rely on root trust stores having a new root, and these intermediates have lifetimes of around 5 years, why would one have E1/E2 signed by X2 rather than X1? That is, if you need to chain up to X1 for the next 5 years or so anyway (and so you can’t really have a full-ECDSA chain until the next set of intermediates comes along), what’s the advantage of the added step in leaf→E1→X2→X1 over leaf→E1→X1? Especially considering the efforts being made here to squeeze every last byte possible (including a custom URL shortener‽) to allow servers to present smaller certificate chains, I’m just assuming I’m missing what the benefit is of the extra layer.

I’m far from being a PKI expert, so I’m just trying to learn what’s going on and why. Thanks!

3 Likes
17

Good question! Mainly the folks who have been interested in an ECDSA hierarchy have wanted an all-ECDSA hierarchy, but it's true that at first deployment they would not be able to get that and would need to serve the chain that goes through X2. However, signing X1 -> E1 would give shorter chains for such users. Will think about it! BTW, I tend to use the notation from RFC 4158 - Internet X.509 Public Key Infrastructure: Certification Path Building, where an arrow indicates the direction of signing.

FYI lencr.org is not a URL shortener. It's just another hostname that we control and will configure to directly serve the relevant resources.

3 Likes
18

Heh. Wouldn’t be the first thing I’ve done backwards. I’ll see if I can remember to draw arrows from root to leaf from now on since that’s the “standard”. :slight_smile:

One possibility that occurred to me was I didn’t know if routing through X2 allowed browsers/validators to shortcut the top-level X1→X2 link once X2 was in their root trust store. That is, even if servers needed to serve a full X1→X2→E1→leaf chain to handle cases where only X1 was in the trust store, once one particular user’s browser was updated to trust X2 would it be able to do an only-ECDSA validation and then just ignore the signature by X1? Which might make things faster for those users than a chain that includes RSA? Or is that not how it works since X2-signed-by-X1 is “different” from X2-signed-by-itself-in-the-trust-store?

My next question (I keep coming up with them I guess) is unrelated, but just based on the naming: Why would you include the key type in the intermediates’ names but not in the roots’ names? It seems a little weird to me that “ISRG Root X1” and “Let’s Encrypt Root X2” are part of the same “series” with the main difference being the key type (though it wouldn’t be obvious from looking in a list that they’re from the same entity since the ISRG brand isn’t nearly as well-known as Let’s Encrypt), but the intermediates are distinguished by key type where it’s obvious if I’m talking about the RSA one or the ECDSA one. Separately, there already exists a “Let’s Encrypt Authority X2” listed as retired which seems like it could cause confusion since “Let’s Encrypt Root X2” and “Let’s Encrypt Authority X2” sound similar if one isn’t paying close attention (though I don’t know if it would actually cause any issues in practice). I guess I want to know what the “X” stands for. (And I do understand that naming things is the hardest problem in software engineering by far.)

3 Likes
19

any chance that domain name might change to something that reads more like "encrypt"?

4 Likes
20

I assumed it was for X.509

2 Likes
21

🔒.org ? (xn - - lv8h . org)

22

“This ending .ORG doesn’t support this combination of international characters”