SSL Certificates vs. Bundles vs. Intermediary vs. Root

82 views
0

The more I refresh my understanding the more confused I get.

Say I have example.com and it’s time I update the SSL cert for that site. I have my private key, but then I end up downloading what appears to be a crt bundle and a csr. What is the difference between these?

CA bundle is a file that contains root and intermediate certificates. What are these two certificates types? How do they work in concert with SSL?

What is the base level of “new files” I would need, basically, to renew my certificate? It’s still not clear to me.

Are the root certs for example certificates that sit on my local machine for various things? I see them in different Windows and Linux and Mac hosts.

In: 5

> I have my private key, but then I end up downloading what appears to be a crt bundle and a csr. What is the difference between these?

A CSR is a certificate signing *request*. It’s a standard data format saying “hey, Certificate Authority, can you sign me a certificate with this name and these parameters valid for 2 years?”, or whatever . It’s not a (trusted) certificate itself. The CA could decide to not accept that CSR for whatever reason (remember it’s a certificate signing *request*).

You likely didn’t get a CSR and a crt bundle, but a *certificate* (the output of a CSR after approval by a CA) and a CA bundle (containing the certificate of the CA that signed your certificate).

Depending on the product, you may have to concatenate these two files in a single file on your web server.

> CA bundle is a file that contains root and intermediate certificates.

Correct

> What are these two certificates types?

A root CA is a CA you can usually find in the “trust store” of your device (often at the operating system level). There are relatively few root CAs. They are the ultimate source of trust as far as certificates are concerned. Therefore, root CA certificates are usually self signed by those CAs.

There are a lot of organizations providing certificates. Since it is not practical to have thousands of root CAs in a trust store (also, root CAs have extremely stringent requirements), intermediate CAs exist, which are trusted to sign certificates for everybody (including your example.com, or maybe even other CAs!), but their certificates are provided by root CAs.

> How do they work in concert with SSL?

Servers provide their certificate to the client. If there is a certificate chain, they send all the certificates in chain (their own certificate + the intermediate CA certs. The root CA may be skipped). The client checks that each certificate in this path is signed by another CA at an upper level, and the intermediate CA certificate is ultimately signed by a root CA the client recognizes as such. If these checks succeed, the green lock is displayed (valid certificate) and the SSL handshake process continues.

You are getting a few things confused, all SSL certs have a private key and a public key. CAs are used to sign other keys “say that CA XYZ trusts cert 123”. Typically, a CA will make short-er term certs “intermediary certs”, and these are actually what is used to sign user certs. With the intermediary cert signed by the “root” CA cert.

When you have a website you make a private key (just pick a random prime basically), and a CSR that has details about your cert you want to make (what website it should be for), and the CA uses their intermediary cert to sign your CSR to make a crt file (your cert, which has some of the info from your CSR, and a signature, which will work with your private key). Note, the CA never gets your private key, it is NOT within the CSR.

A bundle is just a list of certs, and it’s used by things like web browsers to verify signatures. The CA bundle is typically configured by your browser so that the browser trusts any cert signed by any cert in the bundle. Since it contains all intermediary certs, it should always work.

Now, when a CA makes a new intermediary cert for signing certs, that might not be in everyone’s bundle, but the root CA is. So when making certs your CA will give you the cert chain (all intermediary certs between your cert and the root), and tell you to configure your server to include this with it’s certs. Now when a browser connects they’ll get all the certs in the chain, and can look it up in the bundle for certs, and it will match against the root cert and that will be enough to prove your servers cert is good.

A certificate contains a domain name (or some other identifier), “the subject”, a public key, and a signature over that name and key made using a private key for which there is some other certificate “the issuer”. A valid certificate has a chain of certificates, such that for each subject you have an issuer certificate, for which you have an issuer certificate, and so on up until eventually you end up at a “root certificate” which you trust absolutely.

The original idea was that browsers would have a set of root certificates, and those root certificates would directly sign end-user certificates. But there are good reasons why that’s not ideal: having the key matching that root certificate available to sign things exposes it to risk, and compromise of that key is very serious. Those certificates need to have very long lifetimes, too.

So now, there are a chain of intermediate certificates, either one or two deep, between the root certificate and the certificate you are issued by a CA. So your LetsEncrypt certificate is (currently) issued by R3, which your browser probably doesn’t trust, but that is in turn signed by ISRG, which your browser does. So if you were just presented with a certificate signed by R3, you’d reject it: you don’t know anything about the intermediate certificate. Instead, you are handed both the R3 certificate and the subject certificate, so you can trace the path back to a certificate you do know about.

In general, a website (or whatever) needs to serve the certificate covering its name, but also any intermediate certificate which a client may need to trace to a root certificate.