Hacker News new | past | comments | ask | show | jobs | submit login
Let's Encrypt Root and Intermediate Certificates (letsencrypt.org)
216 points by schoen on June 4, 2015 | hide | past | web | favorite | 37 comments



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.


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...

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


> (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.


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


You'll want to locate a copy of Brian Komar's book on Windows PKI; offline root is not hard, but many things in AD:CS land are more mysterious than they ought to be.

Personally I don't like AD:CS for an offline root, oddly bound-up in the OS guts as it is, and with an architecture-dependent cert db; just use openssl to gin up the root, and use AD:CS for issuance / online operations.


I just closed a project that did just this with a Microsoft CA. What issue did you have?


When you set up the intermediate CAs, I installed the root public key, but the intermediate CAs wanted to know "where" the CA running with the root private key was, I didn't have an online root (I generated then took it down), and the intermediate CA wasn't having any of that.


I did this a couple years ago and assisted another admin with an install last year. Here is one of the guides I used to get me through it:

https://itworldjd.wordpress.com/2013/03/20/ad-cs-2008-r2-ins...


If nothing else, you should be able to tell the intermediate CA to pretend that a root and then re-sign its public key with your actual root, and then hand the actual root to clients, and hand the new intermediate CA cert to servers to use in the chain. I'm pretty sure the signing process only depends on the public key, not on the entire cert.

This is how cross-signatures work: new CAs will get their intermediate keys cross-signed by existing CAs, so that you can construct a valid chain from them. This creates a different CA certificate, but it's using the same public key, so the end-entity certs validate with either CA certificate.


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.


It looks like Java will accept it: https://news.ycombinator.com/item?id=8646029


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


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


> 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?


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.


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…


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


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


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.


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...

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...

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

CRL - Certificate Revocation List - This is another way to broadcast certificate revocations. 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

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...

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

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...

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


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


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...


Apparently it's in iOS 8: 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/... -- 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...


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


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


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


    > Ctrl+C …
⌘+C, of course*

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


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


Here's the details for the Intermediate 1 cert (I'm not seeing the cross signature):

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


Here's the details for the Intermediate 2 cert:

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


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?


"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.


beats the current system, where there is multiple single points of failures. :p


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


It's also on our website.

https://letsencrypt.org/about/


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/

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

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


Truly great work here! Thanks




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: