Score:1

Crypto

X.509 CA bundle content

hidigoudi

6/30/24, 10:27 PM

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 :

End-user certificate
Intermediate certificate
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.

1 + 6

x.509

Maarten Bodewes

6/30/24, 11:33 PM

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".

dave_thompson_085

7/1/24, 2:53 AM

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](https://letsencrypt.org/2020/12/21/extending-android-compatibility.html) 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. ...

dave_thompson_085

7/1/24, 2:55 AM

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

hidigoudi

7/1/24, 7:03 AM

@dave_thompson_085 is right, the third certificate in my chain is issued by "DST Root CA X3, Digital Signature Trust Co.".

hidigoudi

7/1/24, 7:04 AM

@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.

Maarten Bodewes

8/6/24, 4:36 PM

Do you mind if I migrate this to [security.se]? Sorry to bother you after so long, but as all the mods were at mod-strike we were not able to migrate. It would require you to use your current profile on the IT security site.

Score:1

Crypto

Maarten Bodewes

6/30/24, 11:54 PM

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;

+ 8

dave_thompson_085

7/1/24, 2:59 AM

It's almost certainly a mostly-obsolete bridge from LetsEncrypt to IdenTrust/DST, see my comment on the Q.

hidigoudi

7/1/24, 8:36 AM

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.

Maarten Bodewes

7/1/24, 10:53 AM

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.

hidigoudi

7/1/24, 11:00 AM

Is it possible to retrieve the full chain from the end user certificate ? I mean with an openssl command for example

Maarten Bodewes

7/1/24, 12:43 PM

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).

hidigoudi

7/1/24, 1:12 PM

Ok I see, thank you for information. My apache server sends only the end user cert, on my OS I have only the root cert stored (ISRG Root X1), how the web browser manages to validate the full chain and especially the intermediate cert ?

Maarten Bodewes

7/1/24, 5:18 PM

It probably has seen and stored the intermediate certificate before, and stored it in an **internal cache that you don't get to see**. I've seen this situation before, including when troubleshootinger servers for a client. In my opinion they might as well not cache the certs, it would at least not end with misconfigured servers that can serve some clients and not others. Remember that CA's issue multiple certs, so the intermediate CA may be cached from an entirely different connection.

hidigoudi

7/1/24, 7:10 PM

I see, thank you very much for your help.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: X.509 CA bundle content

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.