1
$\begingroup$

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 :

enter image description here

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.

$\endgroup$
6
  • $\begingroup$ What do you mean with "match" in this respect? I thought you might mean "are equal" but that isn't the case, as the end-user and intermediate certs also "match". $\endgroup$
    – Maarten Bodewes
    Jun 30, 2023 at 23:33
  • 2
    $\begingroup$ Although the ISRG root X1 is now widely trusted and most clients (like your browser) will use it to authenticate a LetsEncrypt cert, LetsEncrypt still provides a 'bridge' cert to a different root, (IdenTrust) DST X3, for some ancient (Android) devices that don't have the ISRG root and can't be updated. Thus you see the bridge cert in the actual chain configured and sent, but not in the trust path normally used. Note that sending the intermediate is required by RFCs; some clients work without it but some don't. ... $\endgroup$ Jul 1, 2023 at 2:53
  • 1
    $\begingroup$ ... We have dozens of Qs (and As) on multiple Stacks discussing this from Sept 2021 et seq when DST X3, which formerly was actually used by many devices,expired. Just search. $\endgroup$ Jul 1, 2023 at 2:55
  • $\begingroup$ @dave_thompson_085 is right, the third certificate in my chain is issued by "DST Root CA X3, Digital Signature Trust Co.". $\endgroup$
    – hidigoudi
    Jul 1, 2023 at 7:03
  • $\begingroup$ @MaartenBodewes-onstrike Yes "match" means is equal (strings are equals). Only the third certificate in the chain does not. But I have now the explanation. $\endgroup$
    – hidigoudi
    Jul 1, 2023 at 7:04

1 Answer 1

1
$\begingroup$

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;

$\endgroup$
8
  • $\begingroup$ It's almost certainly a mostly-obsolete bridge from LetsEncrypt to IdenTrust/DST, see my comment on the Q. $\endgroup$ Jul 1, 2023 at 2:59
  • $\begingroup$ What I'm currently don't understand is that I'm only providing the end-user certificate without intermediates or root and all my web browsers are able to find the full chain themself. The intermediate certificate in my case is "R3" issued by Let's Encrypt, but in my web browser embedded root certificates or even in my OS, I do not have the R3 certificate. $\endgroup$
    – hidigoudi
    Jul 1, 2023 at 8:36
  • $\begingroup$ Well, the cache is not much use to the end user - you won't find the intermediates in the root store. Apparently 11 years ago the private browsing within Firefox didn't use the intermediate certs apparently, so maybe that will work - or in this case fail. $\endgroup$
    – Maarten Bodewes
    Jul 1, 2023 at 10:53
  • $\begingroup$ Is it possible to retrieve the full chain from the end user certificate ? I mean with an openssl command for example $\endgroup$
    – hidigoudi
    Jul 1, 2023 at 11:00
  • $\begingroup$ Double clicking on the certificate in Windows will give you access to the certificate tree, each of certs can be saved. Of course, that means using the certificate store of Windows not OpenSSL. And you can of course look manually for the root cert. Otherwise you can always enable logging for your TLS sessions or use Wireshark or something like that (in which case TLS 1.2 is easier to use as TLS 1.3 will encrypt the handshake as well). $\endgroup$
    – Maarten Bodewes
    Jul 1, 2023 at 12:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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