x509 verification fails on critical EKU

[nbastin]

If any certificate in the verification chain has a critical EKU, verification will fail. RFC 5280 (and X.509 in general) allows EKU to be either critical or non-critical for any certificate. I've attached a test script and 2 different sets of certs (one that works, one that fails). Both sets pass openssl verify -x509_strict.

The script takes the root cert as the first argument (-cacert.pem) and the to-be-verified client cert as the second (-testuser-cert.pem).

pyca_test.tar.gz

[alex]

From the RFC:

This extension MAY, at the option of the certificate issuer, be either critical or non-critical.

I don't see anything in CABF about requiring it to be critical either. Is this just a bug? If so, let's get a testcase in x509-limbo.

…

On Tue, Jun 25, 2024 at 7:55 PM Nick Bastin ***@***.***> wrote: If any certificate in the verification chain has a critical EKU, verification will fail. RFC 5280 (and X.509 in general) allows EKU to be either critical or non-critical for any certificate. I've attached a test script and 2 different sets of certs (one that works, one that fails). Both sets pass openssl verify -x509_strict. The script takes the root cert as the first argument (*-cacert.pem) and the to-be-verified client cert as the second (*-testuser-cert.pem). pyca_test.tar.gz <https://github.com/user-attachments/files/15980509/pyca_test.tar.gz> — Reply to this email directly, view it on GitHub <#11163>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBBJFAFKCRXGNEMXQI3ZJH7PZAVCNFSM6AAAAABJ4ZILBWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGM3TGOBXGU2TQMI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- All that is necessary for evil to succeed is for good people to do nothing.

[alex]

I did miss it, see https://cabforum.org/working-groups/server/baseline-requirements/requirements/#71276-subscriber-certificate-extensions

So this is a feature request to allow loosening this requirement.

[alex]

Closing in favor of #11165 which tracks this more broadly.