3

A general question about chaim.pem files; I used a csr obtained from my host, and used the Certbot from LetsEncrypt to generate a https cert; I used the following command

$ certbot certonly --manual --csr file-with-my-csr.txt

The certbot produced 3 files 0000_cert.pem, 0000_chain.pem, 0001_chain.pem; I then used the cert.pem file to install the cert back at my host; It all worked rather smoothly;

My question is what are the "chain" files used for, as I did not use them anywhere; In what scenarios will they be useful?

2

Your Certbot output is slightly unusual. You should've received a "fullchain.pem" file containing everything in the correct order, not as several separate files.

(Not to mention the manual installation itself – you will have to automate this.)

My question is what are the "chain" files used for

All WebPKI certificate authorities have at least a two-tier system:

  1. The root CA certificate, stored securely offline, signs intermediate (issuing) CA certificates.
  2. The intermediate CAs, stored online, sign the server (end-entity) certificates.

For example, here's a diagram by Let's Encrypt, whose hierarchy usually is:

Root: "DST Root CA X3" (or possibly "ISRG Root X1")
\-- Issuing: "Let's Encrypt R3"
    \-- End-entity: "letsencrypt.org"

Most TLS clients (browsers, operating systems) only come with the root certificate pre-installed. This way they don't need to be updated every time a CA changes its infrastructure – only when the CAs themselves are added or removed.

However, to verify each certificate's signature, you need to have the immediately preceding certificate (e.g. you cannot directly verify the server cert's signature using just the root CA – there is no direct cryptographic relationship between the two).

This means that the client must have all intermediate certificates in order to complete the chain between a root CA. If any of the intermediates is missing, the client no longer has enough information to verify the rest.

For HTTPS, the primary method is to have the server send all of its chain certificates – because the server is supposed to already have them.

Some web browsers have alternative mechanisms for this – for example, Firefox keeps a cache of "previously seen" intermediates, while Windows tries to download intermediates using the AIA URL in your certificate.

But not all browsers do this, and importantly, most non-web TLS clients don't have any such alternatives at all. While an incomplete chain will often work for HTTPS, it will not work for things like SMTP or IRC.

I then used the cert.pem file to install the cert back at my host; It all worked rather smoothly

Most likely, it only worked for some users (primarily Windows and Firefox), but many others were left out. Do not assume that because it works on your own system, it must work on everyone else's.

Tools such as SSL Labs or gnutls-cli example.com:443 will warn you about situations where the server doesn't send the full chain.

It is however possible that whatever "your host" is also proactively downloads the intermediates from AIA information (I slightly suspect Windows' IIS may be doing this), filling in the gaps automatically. But if that's done anywhere, it is quite rare.

Regular Certbot usage

Normally Certbot stores the received certificates in "ready for use" format in the /etc/letsencrypt/live folder, with fullchain.pem containing the host's certificate and whatever parent certificates are necessary. For example, in Apache httpd 2.4.x you would use:

SSLCertificateFile    /etc/letsencrypt/live/example.net/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.net/privkey.pem
4
  • I just opened up the cert.pem file where it has a Begin /End Certificate, copied that whole text into my hosting provider (IIS) interface, and that was it, navigated to the site with Chrome and it shows the lock symbol Encryped / Secure. I have also use SSL Labs now that you mentioned it, and most tests pass ok; In my case certbot produced the 3 files in my current working dir on my Ubuntu system; I also checked /etc/letsencrypt and there is no live folder ! only an accounts, and renewal-hooks folder. – joedotnot Apr 17 at 10:15
  • And for what it's worth I just installed a brand new Ubuntu, retrieved the latest certbot as of today 17/Apr/2021 $sudo apt-get update, and $sudo apt-get install certbot , and that is the behaviour of certbot as of today. When looking on the Browser, my certification path is (1) DST Root CA X3 (2) R3 (3) myserver.net – joedotnot Apr 17 at 10:25
  • The chain.pem file has a purpose: some software wants to have the signing chain in a separate file from the end certificate. – Mark Apr 17 at 19:46
  • 1
    "Your Certbot output is slightly unusual." Certbot works very differently when you use --csr. – Matt Nordhoff Apr 17 at 23:00
1

A simple explanation can be found here

First, what is a PEM:

PEM is a container file format often used to store cryptographic keys. It’s used for many different things, as it simply defines the structure and encoding type of the file used to store a bit of data.

What is a PEM file:

PEM is just a standard; they contain text, and the format dictates that PEM files start with…

Pem files used with SSL certificates:

PEM Files with SSL Certificates

PEM files are used to store SSL certificates and their associated private keys. Multiple certificates are in the full SSL chain, and they work in this order:

The end-user certificate, which is assigned to your domain name by a certificate authority (CA). This is the file you use in nginx and Apache to encrypt HTTPS. Up to four optional intermediate certificates, given to smaller certificate authorities by higher authorities. The root certificate, the highest certificate on the chain, which is self-signed by the primary CA.

So what is chain.pem?

chain.pem is the rest of the chain; in this case, it’s only LetsEncrypt’s root certificate

The chain.pem files contain your intermediate certificates.

When you install a SSL certificate, you must install the site certificate but also the intermediate certificates. There are important. As stated here:

An intermediate certificate works as a substitute of a root certificate because root certificate has its own security layers assuring that its keys remain unobtainable. Intermediate certificate plays a “Chain of Trust” between an end entity certificate and a root certificate.

And here:

All major Certificate Authorities use intermediate certificates because of the additional security level. This helps to minimize and compartmentalize damage in the event of a mis-issuance or security event. Rather than revoke the root certificate and literally every certificate that it had signed, you just revoke the intermediate, which only causes the group of certificates issued off that intermediate to get distrusted.

1
  • While I do appreciate your effort and time, I am not sure if I should accept your answer, You did not say what am I going to do with chain.pem, what is the purpose of them, because they appear useless to me; If they are intermediate certificates, why don't I have to install them also ? – joedotnot Apr 17 at 9:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.