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.
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
