Re: [TLS] Regulations for EKU validation for CA certificates in the certificate chain

[Viktor Dukhovni <[e-mail]>]

On Sat, Jan 28, 2023 at 11:57:46AM +0200, Oleg Pekar wrote:

>   "If the extension is present, then the certificate MUST only be used
>    for one of the purposes indicated.  If multiple purposes are
>    indicated the application need not recognize all purposes indicated,
>    as long as the intended purpose is present.  Certificate using
>    applications MAY require that a particular purpose be indicated in
>    order for the certificate to be acceptable to that application.

Note, for the record, that OpenSSL does not require EKUs in CA
certificates, but *if* they're present, *then* the EKUs in the CA
certificate need to be compatible with the purpose to which the EE
certificate is used (e.g. TLS client or TLS server).

With Let's Encrypt DV TLS certificates the chain (sans root) looks like,
for example:

        Issuer: C=US, O=Let's Encrypt, CN=R3
        Subject: CN=dnssec-stats.ant.isi.edu
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication

        Issuer: C=US, O=Internet Security Research Group, CN=ISRG Root X1
        Subject: C=US, O=Let's Encrypt, CN=R3
            X509v3 Extended Key Usage:
                TLS Web Client Authentication, TLS Web Server Authentication

The EKUs on the "R3" intermediate (some prefer "subsidiary") CA are
clearly intended to express the purposes to which certificates it issues
can be put.  The "R3" certificate itself is not used for TLS connection
establishment.

In some configurations there's also a cross certificate from DST, which
has no EKUs:

        Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
        Subject: C=US, O=Internet Security Research Group, CN=ISRG Root X1

-- 
    Viktor.