Why sometimes intermediate certificates don't include a "CA Issuers" part?

Question

I'm learning about certificates, and would like to understand:

How is it possible for intermediate certificates to not include a CA Issuers part?
Is it not a must so that clients can figure it the Chain of Trust?

I'd like to give here 2 examples:

One whose intermediate certificate includes a CA Issuers (*.stackexchange.com), and one who doesn't (udemy.com).

Let's start with security.stackexchange.com:

openssl s_client -connect security.stackexchange.com:443

Outputs:

[...]
-----BEGIN CERTIFICATE-----
MIIHJTCCBg2gAwIBAgISA72+1m+qM4K1gtDMN1jR2FJbMA0GCSqGSIb3DQEBCwUA[...]
-----END CERTIFICATE-----
[...]

Let's save this conent into a file named stackexchange.pem and parse it:

openssl x509 -in stackexchange.pem -text -noout

Outputs:

Certificate:
    Data:
        [...]
        X509v3 extensions:
            [...]
            Authority Information Access:
                OCSP - URI:http://ocsp.int-x3.letsencrypt.org
                CA Issuers - URI:http://cert.int-x3.letsencrypt.org/

Now, let's go to that issuer:

http://cert.int-x3.letsencrypt.org/

Once browsed, a file named download.cer (der encoded) is downloaded, which I'm not sure how to use openssl to directly parse it, so let's first convert it to pem and save it, and then parse it:

openssl x509 -inform der -in download.cer -out download.pem 
openssl x509 -in download.pem -text -noout

Outputs:

 [...]
 Authority Information Access:
   OCSP - URI:http://isrg.trustid.ocsp.identrust.com
   CA Issuers - URI:http://apps.identrust.com/roots/dstrootcax3.p7c

(The next certificate up the path is the root, so we'll leave it).
Great, so both certificates have a CA Issuers part.

Now let's do the same for udemy.com.

Its leaf certificate has:

[...]
X509v3 extensions:
   X509v3 Key Usage: critical
      Digital Signature, Key Encipherment
   Authority Information Access:
      CA Issuers - URI:http://secure.globalsign.com/cacert/gsrsaovsslca2018.crt
      OCSP - URI:http://ocsp.globalsign.com/gsrsaovsslca2018

But parsing the certificate at http://secure.globalsign.com/cacert/gsrsaovsslca2018.crt has no CA Issuers:

[...]
Authority Information Access:
   OCSP - URI:http://ocsp2.globalsign.com/rootr3

How then, should clients go up the Chain of Trust path?

Now, I know that browsers have a predefined certificates list, and also that Windows have a predefined certificates list, so technically that udemy path may be resolved, but what if a client (let's say it's not a browser nor a Windows app) doesn't have that predefined data? How can the intermediate CA certificates be followed?

score 1 · Accepted Answer · answered Oct 01 '20 at 01:19

How then, should clients go up the Chain of Trust path?

The clients use the Issuer information (and X509v3 Authority Key Identifier) and not the AIA CA Issuer information to build the certificate chain. The intermediate certificates are supposed to be send by the server during the TLS handshake and are not downloaded by the client separately using the AIA information. And this is also the case for the domain you mention as for example openssl s_client -connect udemy.com:443 -showcerts shows.

In other words: AIA CA Issuers is not needed for certificate validation at all and that's why it does not matter if it is included in the certificate or not. See SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate? for more information.

I would say that this part has the following constraints: AIA is not much necessary for CA certificates directly below the root (2nd tier) and when certificate is used strictly with HTTPS only. In other cases it is recommended to have issuer information in AIA extension in 3+ tier CA certificates. — Crypt32, Oct 01 '20 at 06:07
Thank you. Can you add some info about when AIA CA Issuers *are* needed (or maybe even guaranteed to be included)? — OfirD, Oct 01 '20 at 08:44

Why sometimes intermediate certificates don't include a "CA Issuers" part?

1 Answers1