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

[Jakob Bohm]

On 2021-05-28 22:50, Michael Wojcik wrote:

> Just realized I sent this directly to Graham instead of to the list.
>
> -----Original Message-----
> From: Michael Wojcik
> Sent: Friday, 28 May, 2021 09:37
> To: 'Graham Leggett' <minfrin at sharp.fm>
> Subject: RE: X509_verify_cert() rejects all trusted certs with "default" X509_VERIFY_PARAM
>
>> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Graham
>> Leggett via openssl-users
>> Sent: Friday, 28 May, 2021 06:30
>>
>> I am lost - I can fully understand what the code is doing, but I can’t see
>> why openssl only trusts certs with “anyExtendedKeyUsage”.
> Interesting. I wondered if this might be enforcing some RFC 5280 or CA / Browser Forum Baseline Requirements rule.
>
> 5280 4.2.1.12 says:
>
>     In general, this
>     extension will appear only in end entity certificates.
>
> and
>
>     If the extension is present, then the certificate MUST only be used
>     for one of the purposes indicated.
>
> Your certificate has serverAuth and emailProtection, yes? So it cannot be used to sign other certificates, and OpenSSL is correct as far as that goes. 5280 doesn't define an EKU for signing certificates; so perhaps the intent of the OpenSSL code is "if EKU is present, this probably can't be used as a CA cert without violating 5280, but I'll look for this 'any' usage just in case and allow that".
>
> The errata for 5280 and the RFCs which update it do not appear to affect this section.
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.

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).

> The CA/BF BR 7.1.2.1, the part of the certificate profile that covers root certificates, says:
>
>     d. extKeyUsage
>        This extension MUST NOT be present.
>
> Now, there's no particular reason for OpenSSL to enforce CA/BF BR, and good reason for it not to (the "CA" part refers to commercial CAs, and not all clients are browsers). But it's more evidence that root certificates, at least, should not have extKeyUsage because browsers can correctly reject those.
>
> The CA/BF profile is more complicated regarding what it calls "subordinate" certificates, aka intermediates, so for non-root trust anchors there are cases where you can get away with extKeyUsage. But a good rule is "only put extKeyUsage on entity [leaf] certificates".
>
>
> So that really leaves us with the question "do we want OpenSSL enforcing the extKeyUsage rules of RFC 5280?". And I'm tempted to say yes. In principle, the basicConstraints CA flag and the keyUsage keyCertSign option should suffice for this, but defense in depth, and in cryptographic protocols consistency is extremely important.
>
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.
Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded