While trying to understand the use or meaning of the fullchain.pem file created by let's encrypt I stumbled upon this post in which fullchain.pem is explained as:
fullchain.pem is a concatenation of cert.pem and chain.pem in one file. In most servers you’ll specify this file as the certificate, so the entire chain will be send at once. Some clients require you to specify the above two files separate. In that case you won’t need
While chain.pem on the other hand is described as
chain.pem contains the intermediate certificate, the certificate from Let’s Encrypt containing the public key which is “coupled” to the private key which signed your certificate (the one above). This intermediate certificate is required for clients to verify your certificate;
But I have troubles really understanding what this means. By this I mean what exactly is intermediate certificate and where does it come from.
I understand the concept of CA's and the fact that CA issue certificates. I understand that the certificate issued by the CA which is put to use is the end user certificate.
I also understand the chain of trust, where there are intermediate CA between the end user certificate and the root CA.
What I can't understand is how let's encrypt can know all the possible intermediate CA between the root CA and the end certificate.
I mean it is possible to know all the CA, that the root CA itself signed. But what if those other CA's created other CA's that ends up issuing the end user certificate, how can this ever be in chain.pem?
Which then begs the question, how can those end user certificate's be ever verified, since it seems the full chain of trust, the full intermediate CA is not known in chain.pem?
Anyone kind enough to help me understand the setup? Thanks!
You shouldn't think of "intermediate certificates" as a separate CA. The intermediate certificates used by Let's Encrypt are from Let's Encrypt themselves. And Let's Encrypt obviously knows which intermediate certificates they have generated and can use.
How do you mean "other CA's"? The only CA relevant here is Let's Encrypt.
How do you mean "full chain of trust"? There normally are just a few possible chains possible, not hundereds or thousands. Let's Encrypt for example can only chain to two roots: their own (ISRG Root X1) and the cross signing root from IdenTrust (DST Root CA X3).
Correct me if I am wrong, but I can imagine a scenario where I get a certificate from Let's encrypt and use that to sign other certificate which is then used. In this scenario, the certificate I receive from Let's encrypt will then be an intermediate CA. Or such a setup can never happen?
Just to be sure, from this, I guess you are saying the scenario where I used my private key and certificate I recieve from let's encrypt to sign other certificate that gets deployed is not possible (or maybe does not make much sense?)
Edit
How is the scenario of a big company who wants to have it's own intermediate CA then set up? A scenario where the IT department has a CA that is used to hand out certificates to other departments but this CA from the IT department is actually a child of Let's encrypt. Is this not possible?
I see. Thanks for clarifying. But what about the scenario of a big company who wants to have it's own intermediate CA? How is that then set up? A scenario where the IT department has a CA that is used to hand out certificates to other departments but this CA from the IT department is actually a child of Let's encrypt. Is this not possible?
If you edit the chain.pem file (with a normal text editor - like: notepad), you should see two one "cert".
[or cat chain.pem]
Your new cert
[which was signed by an intermediate cert]
The intermediate cert.
[which was signed by a trusted root]
All trusted roots are expected to be in the trusted root store.
End leaf certs can never be used to sign any other cert.
Even intermediates are not allowed to create other intermediates.
To expand on @JuergenAuer's response above:
Every certificate in the "WebPKI" (the Web's Public Key Infrastructure) has certain technical limitations imposed on it. These are represented generally by the "keyUsage", "extendedKeyUsage", and "basicConstraints" fields of the certificate.
The basicConstraints field determines whether that certificate (or rather, the keypair represented by that certificate) is allowed to issue other certificates at all. As you can see in this example (a certificate for my own domain), you can see that it says:
X509v3 Basic Constraints: critical
CA:FALSE
This means "nope, not allowed to issue any certificates". This is the same for every certificate that Let's Encrypt issues to subscribers like yourself.
Compare this with the R3 intermediate that Let's Encrypt uses to issue those end-entity certificates:
On the one hand, this has CA:TRUE, which means it can issue other certificates (good!). But it also has pathlen:0, which means "but this has to be the last (0th) CA in the chain; anything issued by this certificate cannot itself also be a CA".
So the situation you describe, in which a company purchases an intermediate and uses that to issue all of its own certificates, is totally possible in general. But it is not possible from Let's Encrypt. LE is focused on securing the entire internet through uniformity and automation, and avoids such custom and one-off situations at all costs.
Based on other people's responses it seems like you were bothered by the idea that Let's Encrypt can provide the "full chain" if additional downstream signatures could happen (which would have the effect of making the chain longer). As other people have said, Let's Encrypt in particular doesn't offer that option at all, although it's true that other CAs do.
In terms of situations that could give rise to uncertainty about which chains are possible:
Currently root CAs are generally not allowed (by policy) to issue totally unconstrained sub-CA certificates without a contractual, auditing, and transparency framework (to govern the behavior of the sub-CA operator). Browser developers—which are the most active and powerful entities in crafting and policing rules about CAs' behavior—have also demanded that all intermediate certificates that are issued be publicly disclosed, which was not the case a decade or so ago (where there could have been, and might actually have been, confidential intermediate CAs).
The web PKI technology does allow name-constrained CAs, which are meant for use cases like the "big company" you mention. That is, you can have a path where one certificate says that subsidiary certificates to it should only be accepted if they refer to names within a specific domain. In theory a technology like the one Let's Encrypt uses could be used to issue name-constrained sub-CAs based on some kind of automated validation process. (I was pretty interested in the question of whether this was possible when we were first setting up the Let's Encrypt system.) For example, if you were the administrator of example.com, you could imagine applying to a CA like Let's Encrypt for a sub-CA constrained to issue only within *.example.com (in which case, if your sub-CA signed certificates covering other names, browsers would reject them because of a violation of the name constraint on the certification path). Conceivably people within your company could then apply to you for sub-sub-CAs for *.accounting.example.com, or something. In that case, Let's Encrypt would indeed not be able to anticipate the eventual chain or chains that would be used to validate some of the certificates issued as a result of this process.
However, Let's Encrypt doesn't even offer name-constrained sub-CAs, so even this issue (which I think is along the lines of what you were thinking of) doesn't arise with any current Let's Encrypt service.
I was in a conversation several years ago about this question and I don't really remember the exact answer, but I believe a likely reason is that browser developers are extra-nervous about sub-CAs (even with name constraints) and simply do not want them to be created by an automated process within some equivalent to the policy constraints that apply to general-purpose CAs (even though the stakes are considerably lower for any individual name-constrained sub-CA)¹. Let's Encrypt has also pointed out that you can get a reasonably large number of certificates for names inside your domain directly from Let's Encrypt quickly and for free, so the need for a sub-CA for most organizations may be reduced compared to the past where this process would be slower and more expensive.
I think more ubiquitous and automated use of name-constrained sub-CAs would be cool, but the infrastructure to usefully operate your own CA can be somewhat complex, and maybe not that many organizations would be in a good position to take advantage of this option. In any case, I expect that it won't happen unless the browser developers can be convinced that it's needed and could be done safely.
¹ I suppose a signing key for all of ibm.com or stanford.edu or navy.mil or whatever is still pretty valuable, compared to a short-lived key that's allowed to answer for only a small number of subdomains under those domains. IBM, Stanford, and the Navy are probably pretty well-equipped to protect such a signing key, but maybe other there are other less-technically-adept organizations with pretty high-value domains that would end up requesting automated sub-CAs if they could get them for free with no human interaction—and would then not protect those signing keys in a way that Internet users would agree was proportionate to their significance.
Others have explained that Let's Encrypt won't (and can't) issue such a CA cert. But a large organization such as you describe would generally be expected to manage its own client machines, such that the organization could deploy its own CA cert as a trusted root to all those client machines. In that case, there's no need for the CA cert to come from a publicly-trusted CA.
This is very often right, but I think an interesting counterexample is the U.S. military, which makes very extensive use of PKI and regularly interacts on the Internet both with internal and external users and devices. Any government that has relatively centrally managed (and sophisticated) IT could also be an example, because the government may want to do its own signing for security reasons, but also wants the public in its territory, and even foreigners, to be able to communicate with it.
I once attended a lecture by someone involved with the Autoridade Raiz Brasileira who was talking all about "sovereignty" and how great it was to have sites in Brazil be authenticated by the Brazilian government. I really didn't agree with that, but then later when I was applying for a new Brazilian visa I had to accept a signature from that very CA (... or an impostor with the same CN field!) in order to access the form, because it was, at the time, a policy decision for some Brazilian government entities to use it. I thought it would have been a great compromise if it had been publicly trusted and name-constrained to .gov.br, because the Brazilian government is reasonably regarded as an authority on identity of its own government web sites.
Another example people sometimes give is universities, which may have a strong identity management system but weak control over users' devices, and have constant electronic interactions both within the university and with the general public. And they also usually want a lot of subdomain names (so that Let's Encrypt has had to make rate limit adjustments for many of them).
