Validating Client Certificates

Doug Hardie bc979 at lafn.org
Thu Mar 14 07:47:41 UTC 2024


> On Mar 14, 2024, at 00:04, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
> 
> On Wed, Mar 13, 2024 at 08:50:17PM -0700, Doug Hardie wrote:
> 
>> My client certificates are properly accepted.  However, I am unable to
>> tell just what SSL_accept validates.
> 
> Just the trust path, i.e. that the certificate was issued by *some*
> (transitively) trusted CA.  In particular, you really want to trust
> just your internal CA, and none others.
> 
>> I have not been able to find any documentation on what it actually
>> checks.  My testing shows that the client certificate must be signed
>> by a known root certificate, but does SSL_accept verify that the
>> signing certificate is the one indicated in the client certificate,
>> and how does it check that?
> 
> By constructing a *chain* of certificates from the one presented by the
> client to a "trust-anchor" that you've configured, where each
> certificate in the chain has a valid signature from its successor.

That I have done.  There is only the root certificate and the client certificate.

> 
> 
>> In my server, I am checking the certificate serial number.  Is that
>> necessary and sufficient to ensure that the certificate is the one I
>> generated and not a fake?
> 
> No.  That largerly irrelevant, unless you also have a list of revoked
> certificate serial numbers, or better yet, a definitive list of the
> unrevoked ones, but this is only after the chain validation succeeds, to
> weed out stale certificates that were lost or those that belonged to
> terminated users.

i am planning to use the serial number to handle revoked certificates.  I don't have that setup completely yet, but it is the next item on the agenda.

> 
> In other words the certificate validation just shows that the client
> knows some secret associated with some user and not marked at the time
> for expiration prior to now.  Meanwhile, the user may have moved on, the
> private key may have been lost, ... so you still need to maintain a
> table of which certs are not lost and still correspond to real users.
> 
>> It seems that it might be possible to create a CA that is certified
>> by one of the known root certificates and use it to generate a client
>> certificate with the identical issuer information.
> 
> Correct, a server what wants to consume client certs needs to not trust
> the usual WebPKI roots.  Instead, you'll need to trust *only* your own CA.
> Set up the trust store for the server's SSL_CTX accordingly.

Now that I hadn't thought about.  it makes sense.  I'll have to see about how to do that.  i recall seeing some examples so it shouldn't be that difficult.  I have to make sure that the server will present it's public certificate that is derived from Lets Encrypt while validating on just my root certificate.

> 
> 
>> Obtaining the
>> proper issuer serial number would take some work, but I suspect it is
>> possible.  The rest of that information is trivial.  Thanks,
> 
> Serial numbers are not an authentication mechanism, they are however
> a way of purging stable authenticators.

Thanks so much Viktor.  This has been a real help, and eye opener.

-- Doug



More information about the openssl-users mailing list