

Let's Encrypt Root and Intermediate Certificates - schoen
https://letsencrypt.org/2015/06/04/isrg-ca-certs.html

======
Someone1234
I'm glad (but unsurprised) to see they're doing things correctly (offline
root, then using the intermediate CAs to generate actual certificates).

I tried to set up a similar (identical) scheme for use internally, but for
some bonkers reason Microsoft's CA on 2008 R2 makes doing this almost
"impossible." Or at least if it is possible it is insanely complex. It just
really hated and rejected the concept of an offline root CA that didn't have a
Microsoft CA running for it.

I'd love to be able to tell everyone doing an internal/corporate key-chain
that "this is how it should be done" but holy heck does the tooling make it
more complicated than it needs to be. I should just be able to install the
public root key, hide the private root key indefinitely and it should "just
work" for any key generated via the two intermediate CAs.

~~~
geofft
Root-and-intermediate is a required practice by the CA/Browser forum. See
section 6.1.7:

[https://cabforum.org/wp-content/uploads/CAB-Forum-
BR-1.3.0.p...](https://cabforum.org/wp-content/uploads/CAB-Forum-BR-1.3.0.pdf)

(I'm sort of curious how people still have trouble with cert chains, given how
long this has been a requirement for all CAs.)

~~~
kijin
> _(I 'm sort of curious how people still have trouble with cert chains, given
> how long this has been a requirement for all CAs.)_

There are several reasons for widespread confusion:

1\. Different web server software have different ways to install intermediate
certificates. Apache wants them to be in a separate file, nginx wants them
concatenated with the main certificate.

2\. The same certificate can take different chains of trust depending on the
client. For example, recently issued PositiveSSL certificates come with two
intermediate certificates, but most browsers already trust the second one. So
a lot of people just install the first intermediate certificate and call it a
day. This setup blows up as soon as you try to run some sort of API on your
server (accessed with curl), because unlike browsers, the cacert package on
most distros don't contain the second intermediate.

3\. The certificates themselves are just a bunch of random letters delimited
by a line of dashes. It's not clear at all in which order you should cat them
together, and most GUI tools for viewing certificates don't clearly indicate
the relationship between certificates, either.

Hopefully, the shell scripts provided by Let's Encrypt will prevent most of
the obvious misconfigurations.

~~~
rjgray
Another factor is that some browsers will automatically retrieve intermediate
certificates that aren't supplied by the server. I'm not sure if it's still
the case, but it used to be that Firefox would fail on HTTPS connections with
a broken chain where IE would succeed.

[http://serverfault.com/a/449144](http://serverfault.com/a/449144)

------
lemming
They mention that the cross-signing means that their certs will be trusted by
all browsers out of the gate. Does anyone know if this includes other
platforms such as Java? I'm assuming so, but I don't actually know how the
cross-signing works.

~~~
yuhong
Anything that has "DST Root CA X3", I think.

------
markwakeford
Cant freaking wait, you guys are truly doing awesome things! Well done.

------
mino
> All ISRG keys are currently RSA keys. We are planning to generate ECDSA keys
> later this year.

Why, oh why, not ECDSA from the start?

~~~
bifurcation
Unfortunately, ECDSA support is not as universal as RSA.

But I understand that the plan is to start working on ECDSA support pretty
much as soon as the first root is stood up, so it shouldn't be long after the
start.

------
rmoriz
I wonder why they didn't create intermediate CAs by usage type. Most CAs have
different intermediates for, e.g. TLS/SSL (one each for DV, OV, EV),
CodeSigning, S/MIME, TimeStamp…

~~~
diafygi
I believe that Let's Encrypt will only be doing DV.

~~~
rmoriz
that would be sad :( At least S/MIME is underrated given the wide support in
MUAs (see [http://smime.io](http://smime.io)) but most CAs break the ux.

------
aubergene
So many acronyms, this page could certainly benefit from using the <abbr> tag
to explain, or link off to a definition of what they stand for.

~~~
diafygi
From the article:

ISRG - _Internet Security Research Group_ \- Let's Encrypt was in stealth mode
for a while before they announced the project, and they used this generic name
as the official certificate authority so they could fly under the radar while
starting to lay the ground work to get the project going.
[https://en.wikipedia.org/wiki/Internet_Security_Research_Gro...](https://en.wikipedia.org/wiki/Internet_Security_Research_Group)

OCSP - _Online Certificate Status Protocol_ \- If Let's Encrypt wants to
revoke certificates, they need broadcast those revocations. This is one of the
protocols to do this, and it requires a different key pair.
[https://en.wikipedia.org/wiki/Online_Certificate_Status_Prot...](https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol)

CA - _Certificate Authority_ \- This is someone who signs certificates for
other websites. Browsers and operating systems have a list of CAs they trust,
so if you want the https lock to show up without warning, you need to get your
https certificate signed by one of the trusted CA (Let's Encrypt is going to
be a free CA).
[https://en.wikipedia.org/wiki/Certificate_authority](https://en.wikipedia.org/wiki/Certificate_authority)

CRL - _Certificate Revocation List_ \- This is another way to broadcast
certificate revocations.
[https://en.wikipedia.org/wiki/Revocation_list](https://en.wikipedia.org/wiki/Revocation_list)

RSA - _Rivest Shamir Adleman_ \- A public key cryptography algorithm that most
CAs use for their root and intermediate certificates. It's been battle tested
for 40+ years, so it's a safe bet.
[https://en.wikipedia.org/wiki/RSA_%28cryptosystem%29](https://en.wikipedia.org/wiki/RSA_%28cryptosystem%29)

ECDSA - _Elliptic Curve Digital Signature Algorithm_ \- The next generation in
public key cryptography algorithms that has many advantages over RSA. It's
still relatively new (10 years), so CAs are hesitant to adopt it right now.
[https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signatu...](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm)

From this discussion thread:

PKI - _Public Key Infrastructure_ \- The general term for a network of public
keys. The PKI used by browsers is their list of trusted CAs plus any
certificates from websites that are signed by those CAs (or chained to the CA
through an intermediate).
[https://en.wikipedia.org/wiki/Public_key_infrastructure](https://en.wikipedia.org/wiki/Public_key_infrastructure)

DV, OV, EV - _Domain Validation, Organization Validation, Extended Validation_
\- These are different levels of audits done by CAs before they sign a
certificate for a website. DV just checks that you have control over that
domain (this is what Let's Encrypt will only do), OV checks that you are the
organization you claim to be (usually by calling you), and EV does a lot more
checking around to make sure that your organization is real and you are
running the website (this is the level that gives you a green bar in your
URL). [https://www.globalsign.com/en/ssl-information-
center/types-o...](https://www.globalsign.com/en/ssl-information-center/types-
of-ssl-certificate/)

S/MIME - _Secure /Multipurpose Internet Mail Extensions_ \- A protocol for
signing email with a certificate that has been signed by a CA. Most CAs have a
different key pair to sign keys with for this protocol, but Let's Encrypt will
only be doing DV certs, so it doesn't need one.
[https://en.wikipedia.org/wiki/S/MIME](https://en.wikipedia.org/wiki/S/MIME)

------
toast0
Anyone know how well installed the cross-signed root is? Sounds like it's
going to be DST Root CA X3?

[https://ssl-tools.net/certificates/cv0tp9-dst-root-ca-x3](https://ssl-
tools.net/certificates/cv0tp9-dst-root-ca-x3)

~~~
diafygi
Windows, OSX, Debian, and NSS (Firefox) all have it in their root trust
stores. Dunno about mobile.

EDIT: I can't find it on my Android phone (4.3)...

EDIT2: Found it! Was added in 2010 under the name Digital Signature Trust.

[https://android.googlesource.com/platform/libcore/+/master/l...](https://android.googlesource.com/platform/libcore/+/master/luni/src/main/files/cacerts/12d55845.0)

~~~
codeka
Apparently it's in iOS 8: [https://support.apple.com/en-
gb/HT204132](https://support.apple.com/en-gb/HT204132)

There doesn't seem to be an authoritative list for Android, but I did find
this:
[https://android.googlesource.com/platform/libcore2/+/master/...](https://android.googlesource.com/platform/libcore2/+/master/luni/src/main/files/cacerts/12d55845.0)
\-- not sure whether it means it's in the latest versions of Android, or
whether that means it's going to be _all_ versions of Android (e.g. with
manufacturer/carrier modifications, etc) or what...

~~~
christop
While the vast majority of users upgrade to iOS 8, certainly not everybody
does, so it's good to know that iOS 5 (I didn't check any earlier) also
includes the "DST Root CA X3" certificate: [https://support.apple.com/en-
gb/HT201388](https://support.apple.com/en-gb/HT201388)

------
diafygi
Here's the details for the Root cert:

    
    
        $ openssl x509 -in isrgrootx1.txt -text -noout
        Certificate:
            Data:
                Version: 3 (0x2)
                Serial Number:   82:10:cf:b0:d2:40:e3:59:44:63:e0:bb:63:82:8b:00
            Signature Algorithm: sha256WithRSAEncryption
                Issuer: C=US, O=Internet Security Research Group, CN=ISRG Root X1
                Validity
                    Not Before: Jun  4 11:04:38 2015 GMT
                    Not After : Jun  4 11:04:38 2035 GMT
                Subject: C=US, O=Internet Security Research Group, CN=ISRG Root X1
                Subject Public Key Info:   Public Key Algorithm: rsaEncryption
                        Public-Key: (4096 bit)
                        Modulus: 00:ad:e8:24:73:f4:14:37:f3:9b:9e:2b:57:28:1c:87:be:dc:b7:df:38:90:8c:6e:3c:e6:57:a0:78:f7:75:c2:a2:fe:f5:6a:6e:f6:00:4f:28:db:de:68:86:6c:44:93:b6:b1:63:fd:14:12:6b:bf:1f:d2:ea:31:9b:21:7e:d1:33:3c:ba:48:f5:dd:79:df:b3:b8:ff:12:f1:21:9a:4b:c1:8a:86:71:69:4a:66:66:6c:8f:7e:3c:70:bf:ad:29:22:06:f3:e4:c0:e6:80:ae:e2:4b:8f:b7:99:7e:94:03:9f:d3:47:97:7c:99:48:23:53:e8:38:ae:4f:0a:6f:83:2e:d1:49:57:8c:80:74:b6:da:2f:d0:38:8d:7b:03:70:21:1b:75:f2:30:3c:fa:8f:ae:dd:da:63:ab:eb:16:4f:c2:8e:11:4b:7e:cf:0b:e8:ff:b5:77:2e:f4:b2:7b:4a:e0:4c:12:25:0c:70:8d:03:29:a0:e1:53:24:ec:13:d9:ee:19:bf:10:b3:4a:8c:3f:89:a3:61:51:de:ac:87:07:94:f4:63:71:ec:2e:e2:6f:5b:98:81:e1:89:5c:34:79:6c:76:ef:3b:90:62:79:e6:db:a4:9a:2f:26:c5:d0:10:e1:0e:de:d9:10:8e:16:fb:b7:f7:a8:f7:c7:e5:02:07:98:8f:36:08:95:e7:e2:37:96:0d:36:75:9e:fb:0e:72:b1:1d:9b:bc:03:f9:49:05:d8:81:dd:05:b4:2a:d6:41:e9:ac:01:76:95:0a:0f:d8:df:d5:bd:12:1f:35:2f:28:17:6c:d2:98:c1:a8:09:64:77:6e:47:37:ba:ce:ac:59:5e:68:9d:7f:72:d6:89:c5:06:41:29:3e:59:3e:dd:26:f5:24:c9:11:a7:5a:a3:4c:40:1f:46:a1:99:b5:a7:3a:51:6e:86:3b:9e:7d:72:a7:12:05:78:59:ed:3e:51:78:15:0b:03:8f:8d:d0:2f:05:b2:3e:7b:4a:1c:4b:73:05:12:fc:c6:ea:e0:50:13:7c:43:93:74:b3:ca:74:e7:8e:1f:01:08:d0:30:d4:5b:71:36:b4:07:ba:c1:30:30:5c:48:b7:82:3b:98:a6:7d:60:8a:a2:a3:29:82:cc:ba:bd:83:04:1b:a2:83:03:41:a1:d6:05:f1:1b:c2:b6:f0:a8:7c:86:3b:46:a8:48:2a:88:dc:76:9a:76:bf:1f:6a:a5:3d:19:8f:eb:38:f3:64:de:c8:2b:0d:0a:28:ff:f7:db:e2:15:42:d4:22:d0:27:5d:e1:79:fe:18:e7:70:88:ad:4e:e6:d9:8b:3a:c6:dd:27:51:6e:ff:bc:64:f5:33:43:4f
                        Exponent: 65537 (0x10001)
                X509v3 extensions:   X509v3 Key Usage: critical
                        Certificate Sign, CRL Sign
                    X509v3 Basic Constraints: critical
                        CA:TRUE
                    X509v3 Subject Key Identifier: 
                        79:B4:59:E6:7B:B6:E5:E4:01:73:80:08:88:C8:1A:58:F6:E9:9B:6E
            Signature Algorithm: sha256WithRSAEncryption
                 55:1f:58:a9:bc:b2:a8:50:d0:0c:b1:d8:1a:69:20:27:29:08:ac:61:75:5c:8a:6e:f8:82:e5:69:2f:d5:f6:56:4b:b9:b8:73:10:59:d3:21:97:7e:e7:4c:71:fb:b2:d2:60:ad:39:a8:0b:ea:17:21:56:85:f1:50:0e:59:eb:ce:e0:59:e9:ba:c9:15:ef:86:9d:8f:84:80:f6:e4:e9:91:90:dc:17:9b:62:1b:45:f0:66:95:d2:7c:6f:c2:ea:3b:ef:1f:cf:cb:d6:ae:27:f1:a9:b0:c8:ae:fd:7d:7e:9a:fa:22:04:eb:ff:d9:7f:ea:91:2b:22:b1:17:0e:8f:f2:8a:34:5b:58:d8:fc:01:c9:54:b9:b8:26:cc:8a:88:33:89:4c:2d:84:3c:82:df:ee:96:57:05:ba:2c:bb:f7:c4:b7:c7:4e:3b:82:be:31:c8:22:73:73:92:d1:c2:80:a4:39:39:10:33:23:82:4c:3c:9f:86:b2:55:98:1d:be:29:86:8c:22:9b:9e:e2:6b:3b:57:3a:82:70:4d:dc:09:c7:89:cb:0a:07:4d:6c:e8:5d:8e:c9:ef:ce:ab:c7:bb:b5:2b:4e:45:d6:4a:d0:26:cc:e5:72:ca:08:6a:a5:95:e3:15:a1:f7:a4:ed:c9:2c:5f:a5:fb:ff:ac:28:02:2e:be:d7:7b:bb:e3:71:7b:90:16:d3:07:5e:46:53:7c:37:07:42:8c:d3:c4:96:9c:d5:99:b5:2a:e0:95:1a:80:48:ae:4c:39:07:ce:cc:47:a4:52:95:2b:ba:b8:fb:ad:d2:33:53:7d:e5:1d:4d:6d:d5:a1:b1:c7:42:6f:e6:40:27:35:5c:a3:28:b7:07:8d:e7:8d:33:90:e7:23:9f:fb:50:9c:79:6c:46:d5:b4:15:b3:96:6e:7e:9b:0c:96:3a:b8:52:2d:3f:d6:5b:e1:fb:08:c2:84:fe:24:a8:a3:89:da:ac:6a:e1:18:2a:b1:a8:43:61:5b:d3:1f:dc:3b:8d:76:f2:2d:e8:8d:75:df:17:33:6c:3d:53:fb:7b:cb:41:5f:ff:dc:a2:d0:61:38:e1:96:b8:ac:5d:8b:37:d7:75:d5:33:c0:99:11:ae:9d:41:c1:72:75:84:be:02:41:42:5f:67:24:48:94:d1:9b:27:be:07:3f:b9:b8:4f:81:74:51:e1:7a:b7:ed:9d:23:e2:be:e0:d5:28:04:13:3c:31:03:9e:dd:7a:6c:8f:c6:07:18:c6:7f:de:47:8e:3f:28:9e:04:06:cf:a5:54:34:77:bd:ec:89:9b:e9:17:43:df:5b:db:5f:fe:8e:1e:57:a2:cd:40:9d:7e:62:22:da:de:18:27

~~~
baby
And here's how to do it yourself. Ctrl+C the pem file (comment + base64
encoding of the certificate) and in your terminal in osx:

$ pbpaste | openssl x509 -noout -text

~~~
jonhohle

        > Ctrl+C …
    

⌘+C, of course*

* the only thing I can contribute to a discussion on certificate chains.

~~~
baby
I'm still transitioning to osx :D thanks. I'm surprised the cmd icon exists.

------
TheLoneWolfling
Is it just me who is concerned that this will _very_ quickly become a single
point of failure?

Or rather, a single point of vulnerability?

~~~
JoachimSchipper
"Put all your eggs in one basket, then watch that basket". This is an issue
that we more-or-less know how to deal with (HSMs, procedures, etc.) I'm more
worried about other parts of the CA system, like obscure CAs with bad
judgment/security.

------
zx2c4
Their intermediate certificates have reference to the location of their
Certificate Practice Statement:
[http://cps.root-x1.letsencrypt.org/](http://cps.root-x1.letsencrypt.org/)

~~~
joshmoz
It's also on our website.

[https://letsencrypt.org/about/](https://letsencrypt.org/about/)

~~~
ademarre
Naturally, I tried to change HTTP to HTTPS in that URL but was met with a
domain mismatch error (followed by a HTTP 403):
[https://cps.root-x1.letsencrypt.org/](https://cps.root-x1.letsencrypt.org/)

Fortunately, I see that the actual URL linked from letsencrypt.org is
[https://letsencrypt.org/ISRG-CPS-
May-5-2015.pdf](https://letsencrypt.org/ISRG-CPS-May-5-2015.pdf)

Nonetheless, since
[http://cps.root-x1.letsencrypt.org](http://cps.root-x1.letsencrypt.org) is
out in the wild, that server should have its HTTPS configuration in working
order.

------
shaaaaawn
Truly great work here! Thanks

