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