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.
> (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.
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.
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.
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.
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…
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
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
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
"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.
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/
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.