> From: openssl-users <openssl-users-boun...@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-boun...@openssl.org> On Behalf Of Jakob
> >> Bohm via openssl-users
> >> Sent: Friday, 18 June, 2021 07:10
> >> To: openssl-users@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
