Should we compare thumbprints in Mutual TLS?

Question

When implementing Mutual TLS using https://learn.microsoft.com/en-us/aspnet/core/security/authentication/certauth?view=aspnetcore-5.0 I see they are comparing the thumbprint of the client certificate to the thumbprint of the server certificate. But are these always guaranteed to be the same in production? Doesn't one only contain the public key and the other contains both the private and public keys? And if that was the case, wouldn't they have different thumbprints?

Answer 1

I found your point there and here is the answer, one paragraph before

Because the same self-signed certificate is used in this example, ensure that only your certificate can be used.

for some reason they chose to use same certificate for server and client (maybe for simplicity?) which is indeed a *BAD* practice in real world. Sharing same certificate between different entities never was a good idea. Client and server certificates must be different.

Certificate-based client authentication is more difficult, because you need to have a an account directory to validate client certificate against. For example, Active Directory. This directory should implement certificate <-> principal mapping. When you receive the certificate, you search for principal in directory and if found, you can uniquely distinguish clients, validate their permissions, rights and perform logging.

If no mapping found -- reject authentication, because you don't know the client.

If you don't care in distinguishing clients, then you clearly don't need mutual authentication.

And never hardcore client certificates/thumbprints in code, because they are periodically changed, therefore external account directory (which is updated using out-of-band process) is necessary.

Though, you can implement the logic when arbitrary clients can connect to your server only when they have certificate issued by your private CA. It is valid scenario. In this case, you don't need external account directory and you validate that client certificate is issued by exact, or by one of pre-defined CAs in the list, then you allow subsequent communication. But they still are anonymous to your system.

Edits based on your additions:

If your case fits last paragraph, then:

• validate general chain (i.e. time validity, extensions, revocation, etc.)
• validate that immediate issuer is in the explicit list of approved by you CAs (private)