> On Mar 14, 2024, at 00:04, Viktor Dukhovni <openssl-users@xxxxxxxxxxxx> 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
