reg: question about SSL server cert verification

[Michael Wojcik]

> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Jakob
> Bohm via openssl-users
> Sent: Friday, 18 June, 2021 09:38
>
> On 2021-06-18 16:23, Michael Wojcik wrote:
>
> >> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Jakob
> >> Bohm via openssl-users
> >> Sent: Friday, 18 June, 2021 07:10
> >> To: openssl-users at openssl.org
> >> Subject: Re: reg: question about SSL server cert verification
> >>
> > And there are a whole bunch of other checks: signature, validity dates, key
> > usage, basic constraints...
>
> Those checks would presumably happen after chain building,
> verifying that signatures, dates, key usage and other constraints
> are correct.

Well, that depends on the implementation; it could perform those checks while building the chain, as each certificate is added to the chain. My point was that they'll happen eventually, since the OP's question was pretty broad.

> > Also, the correspondence between the peer identity as requested by the
> > client, and as represented by the entity certificate, should not be done
> > using the CN component of the Subject DN (as OP suggested), but by comparing
> > against the Subject Alternative Name extension values....
> >
> > (Jakob knows all this.)
>
> Actually, I have heard of nothing at all proposing the use of
> SANs on CA certificates or their use in chain building.  Hence
> why I refer only to matching the complete DN and/or matching
> the "key identifier" field.

I was only talking about the entity ("server", in this case) certificate above. The original message wasn't clear about whether the OP understood the use of SANs for the entity certificate and its validation against the peer name presented by the local application.

> However it is something that should be documented in OpenSSL
> documents such as the "verify(1ssl)" manpage, but somehow isn't.

Yes, that would be ideal. But, of course, someone needs to write that documentation.

> Revocation checks would also be part of the post-chain-building
> checks.

Yeah. I was looking at the bigger verification process.

> > My advice, for someone who wants to understand the certificate-validation
> > process in TLS, is:
> > [Snipped: List of academic texts for those who want to implement their own
> > X.509 code]

Well, opinions can differ. I've dealt with many, many customers who simply couldn't diagnose PKI issues because they didn't understand all the technical aspects of the process. They didn't know that browsers were rejecting the entity certificates generated by their internal CA because they had CA: TRUE in the Basic Constraints. They didn't understand that an entity certificate with no SANs wouldn't match both the bare hostname and the FQDN. They didn't understand how to manually construct the chain to understand which intermediate certificates they needed.

PKIX is a horrible mess of arcane specifications, requirements, and implementation ideosyncracies. In my experience, extensive technical knowledge is required to diagnose even a decent subset of the more common failure modes.

--
Michael Wojcik