FW: X509_verify_cert() rejects all trusted certs with "default" X509_VERIFY_PARAM

[Michael Wojcik]

> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Jakob
> Bohm via openssl-users
> Sent: Tuesday, 1 June, 2021 09:58
>
> There is a very common extension to the validation of X.509
> certificates (which should ideally be available as an option
> parameter to OpenSSL validation APIs): The EKU in a CA:True
> certificate limits the end cert EKU values that are acceptable.
> The rule is NOT applied to ocspSigning due to a conflict with
> that EKU authorizing the CA public key to sign OCSP responses
> for the parent CA.
>
> For example a CA with EKU=emailProtection,clientAuth cannot be
> used to issue valid EKU=serverAuth certificates, however it can
> still issue a delegated EKU=ocspSigning delegated OCSP signing
> certificate.
>
> In this filtering anyExtendedKeyUsage acts as a wildcard
> indicating a universal CA, and   In practice, the complete
> absence of the EKU extension acts as an equivalent wildcard.

Makes sense. It would be nice if this were standardized as an update to RFC 5280.

> The OpenSSL 3 code discussed, as described by Graham, appears
> to incorrectly apply the wildcard check without ORing it with
> the normal check for inclusion of the usage for which the chain
> is built and validated.  (I recommend that where such filtering
> is done, it is part of chain building as different chains may
> succeed for different usages).

Yeah, I suspected that, but I wanted to see if other people more familiar with this area of the code were going to comment.

> The CAB/F "guidelines" tend to include arbitrary restrictions above and
> beyond what good X.509 software libraries should do, such as limiting
> validity to 1 year, requiring end certificate holders to be magically
> able to respond to sudden revocations for bureaucratic reasons etc.  Or
> as quoted by Michael, a rule that all roots must be universal roots with
> the no-EKU implicit wildcard.

Agreed. I refer our customers to the CA/BF Basic Requirements when they're dealing with browsers and mainstream web servers -- since those programs are often written to follow the CA/BF rules -- but try to make it clear that the CA/BF doesn't control PKIX.

--
Michael Wojcik