On Fri, Jun 20, 2025 at 04:16:57PM +1000, Viktor Dukhovni wrote:
> > Does Google's change break previously-working use cases?
>
> Yes. Let's Encrypt intermediate issuers no longer vend EE certs with a
> "clientAuth" EKU.
Well, actually, perhaps that hasn't happened quite yet. One of my
server certs contains:
# openssl x509 -in $certfile -noout -text -certopt
no_header,no_sigdump,no_pubkey,no_subject,no_serial,no_version | head
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=Let's Encrypt, CN=R10
Validity
Not Before: Jun 17 01:08:52 2025 GMT
Not After : Sep 15 01:08:51 2025 GMT
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
The relevant language in the Chrome program states:
https://googlechrome.github.io/chromerootprogram/#321-applicant-pki-hierarchies
The Chrome Root Program will only accept CCADB Root Inclusion
Requests from Applicant PKI hierarchies that are dedicated to TLS
server authentication certificate issuance.
To qualify as a dedicated TLS server authentication PKI hierarchy
under this policy:
1. All corresponding unexpired and unrevoked subordinate CA
certificates operated beneath an applicant root CA MUST:
o when disclosed to the CCADB…
* prior to June 15, 2025, include the extendedKeyUsage extension
and (1) only assert an extendedKeyUsage purpose of
id-kp-serverAuth OR (2) only assert extendedKeyUsage purposes
of id-kp-serverAuth and id-kp-clientAuth.
* on or after June 15, 2025, include the extendedKeyUsage
extension and only assert an extendedKeyUsage purpose of
id-kp-serverAuth.
o NOT contain a public key corresponding to any other unexpired
or unrevoked certificate that asserts different extendedKeyUsage
values.
2. All corresponding unexpired and unrevoked subscriber (i.e., TLS
server authentication) certificates MUST include the
extendedKeyUsage extension and only assert an extendedKeyUsage
purpose of id-kp-serverAuth.
The R10 issuer was surely "disclosed to the CCADB" well before the June
15th date, and its EKU has:
$ openssl x509 -in leca/r10.pem -text -certopt
no_header,no_serial,no_version,no_pubkey,no_signame | head
Issuer: C=US, O=Internet Security Research Group, CN=ISRG Root X1
Validity
Not Before: Mar 13 00:00:00 2024 GMT
Not After : Mar 12 23:59:59 2027 GMT
Subject: C=US, O=Let's Encrypt, CN=R10
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
X509v3 Extended Key Usage:
TLS Web Client Authentication, TLS Web Server Authentication
So the issuer qualifies under point "1", but point "2" was not yet met
on June 17th. Does someone have a date for when/whether LE will tow the
line on point 2?
--
Viktor.
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
