[EXTERNAL] - Validating Client Certificates

[Michael Wojcik]

> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Doug Hardie
> Sent: Wednesday, 13 March, 2024 21:50

> I am developing an application that clients will access.  I don't want to use passwords as the users
> have shown a propensity to use easily guessed passwords etc.  I am trying to use client certificates. 

Client certificates and TLS mutual authentication (sometimes called "mTLS") do not in themselves fix
the weak-passwords problem. The end user needs access to the private key associated with the client
certificate. How that happens depends on the client software, but private keys are often protected
with passwords, those passwords are often selected by the end user, and often nothing ensures *they*
aren't weak.

Using client certificates might be a step in improving the strength of the authentication mechanism,
but they don't do so inherently.

> I have setup a local CA that is used to generate the client certificates.  The user's identity is entered into
> the subject CN.

It's not clear what you mean by "the user's identity". If a certificate identifies a person, then (more or less
by definition) the Subject *DN* should be a sufficient description of that person. Since it's rarely the case
that a person's name is unique across a sufficiently large set - the world population, or even in many
cases within an organization, for common names - the X.500 Common Name RDN (attribute), if its value
is a person's name, is often not sufficient to identify an individual non-ambiguously.

If the CN uses a value that *is* guaranteed to map to a unique individual in some domain, such as an OS
username (properly administered), then that's not an issue, of course. But then the certificate really
identifies an OS account, not a person. Whether it identifies a "user" depends on your definition of that
term.

> My client certificates are properly accepted.  However, I am unable to tell just what SSL_accept validates. 

A definitive description of everything that happens in peer certificate validation would require analyzing
the OpenSSL source to make sure I'm not missing anything. From a high-level perspective:

- OpenSSL must be able to build one or more chains from the entity certificate presented by the client to
one of the roots in the trust collection supplied to OpenSSL by the caller, possibly using intermediate
certificates from the collection sent by the client (if any) and from the trust collection (if there are any).

- Each certificate in the chain must be valid: It must be well-formed, its signature must be valid (which
means it has to be checked against the public key of the certificate that signed it), the current time must
be within the validity times of the certificate, and so on.

- Each certificate in the chain must be appropriate: Fields and extensions such as Basic Constraints, Key
Usage, Extended Key Usage, and so forth must meet certain requirements. I don't recall offhand quite
what requirements OpenSSL imposes, and it depends to some extent on version (you didn't say) and 
perhaps on options set by the program (I don't recall offhand what might be available in the API for
validating client certificates). Generally my advice to customers using client certificates is to use a
commercial CA or ensure their organizational CA follows both PKIX and the CA/Browser Forum Basic
Requirements. The CA/BF BR isn't strictly necessary in most cases, but it's a superset of what various
peers might want to see.
	Key strength and use of appropriate algorithms will also be checked; you'll have trouble if you
use a signing algorithm that uses MD5, for example.

If the program has a certificate-validation callback, it could alter or suppress any of these checks, or
impose others of its own.

> 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,

That's not an accurate description. It must be signed by a root or intermediate that can be chained back to
a root in the trust collection.

> but does SSL_accept verify that the signing certificate is the one indicated in the client certificate,

All certificates must be signed using the private key that corresponds to the public key in the certificate
that's listed as the signer. That's how the signature is verified. (Identifying the signing certificate is a bit
complicated, involving the optional AKID extension as well as the Issuer DN, but the short answer is that
OpenSSL has to find the signing certificate in order to verify the signature.)

> and how does it check that?  In my server, I am checking the certificate serial number. 

That's only necessary if your server includes roots in its trust collection that you don't actually want to trust
for this purpose. While there are use cases for that, they're unusual. If you only put roots you want to trust
into your trust collection, you don't need to do any further checks of the signing chain.

> It seems that it might be possible to create a CA that is certified by one of the known root certificates

It's not entirely clear what you mean by this. "known root certificates" is not a technical description. Known
to whom? If you're referring to commercial CAs, then note that, by definition, you can't have a root signed
by a different root -- root certificates are self-signed. It's possible to have a root that's cross-signed by
another root, so you can have a CA that's endorsed by another CA in that sense. You can also have a
trusted CA (note that "trusted" always means only that the peer you're communicating with has decided
to trust it!) issue an intermediate certificate which is then used to sign other intermediates or entity
certificates.

Good luck getting a commercial CA to cross-sign your root or sell you an intermediate. Won't be cheap.
That's their business, after all.

> and use it to generate a client certificate with the identical issuer information. 

"identical" to what? It's really not clear what situation you're contemplating here.

In general, my advice is that PKI is very complex, difficult to get right, and full of pitfalls and unfortunate
failure modes in general, and PKIX (i.e. certificates) is particularly bad. Using TLS mutual authentication is
sometimes an improvement over other authentication mechanisms, but it needs careful and vigilant
administration. If the user base is of significant size, geographically distributed, or otherwise difficult to
deal with, user certificates are likely to become a large source of problems. And they may not actually
offer any improvement in security because there still has to be some mechanism by which the user gains
access to the certificate (by getting access to the private key). Some operating systems offer private-key
storage, but that just defers the problem: how does the user get access to private-key storage? By logging
in, possibly with a weak password?

The fact is that the IT industry is a long way from having any good solution to user authentication. The
current hotness is Passkey, and Passkey is loaded with undesirable properties like poor device portability
and often being tied to biometrics (the worst sort of authentication). Delegated authentication with OIDC
is similarly a horrible mess, for different reasons. Passwords are terrible (passphrases are slightly better)
and weak multifactor authentication hasn't helped much. There's no silver bullet for authentication. There
isn't even a lead bullet.

-- 
Michael Wojcik