X.509 CA bundle content

Question

I recently looked into the subject of public key cryptography (especially with X.509 certificates). I am the administrator of a web server using HTTPS which uses 2 levels of certificates (in addition to the end-user certificate for the website). Here is the schema :

The black line is intentional to keep the anonymous. But it corresponds to my end-user certificate.

By looking carefully into the "CA bundle" provided by the CA service (where I bought the certificate), I got a file like this :

1. End-user certificate
2. Intermediate certificate
3. A certificate which I assume it is the root CA certificate (by logic) but it doesn't by comparing with the CA certificate stored in my OS.

Indeed, the third certificate in the bundle file does not match to any of my certificate or the root certificate present in my system. Normally it is the ISRG Root X1 in my case.

However, both end-user and intermediate certificates match perfectly (R3 certificate).

I probably misunderstanding something with this bundle file, but I would need help to understand what happens exactly with it, is it normal that the third certificate in the bundle does not match with the root CA ? Furthermore, in the apache2 HTTPS configuration for example, the bundle file is clearly not mandatory to operate a HTTPS connection to my website. Only the end-user certificate is necessary (and the private key as well).

Why the end-user certificate only is necessary ? How clients web browsers manage to retrieve the whole certificates levels and tree with just this certificate ? I imagine that it is thanks to the "issuer" section in the certificate am right ?

Thank you in advance for your help.

Answer 1

What is likely provided is the the end user certificate + the "chain" of intermediate CA certificates up to but excluding the root. Those are the certificates that your server should send to the TLS clients such as browsers. The clients should of course already have a root certificate as "anchor" to be able to trust the certificates that you send, so although it is not forbidden to send a root certificate, it's probably best left out.

The intermediate certificates may be cached or even configured as a trust anchor. If that's the case then the receiver of the certificate chain will be able to build a trust path to the trust anchor, even if only the leaf certificate of the end-entity is received.

And yes, the issuer of any certificate should match the subject of the "parent" certificate, as specified in section 6.1 of the X.509 RFC:

(a) for all x in {1, ..., n-1}, the subject of certificate x is the issuer of certificate x+1;