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