Which parts of the client certificate to use when uniquely identifying users?

Question

I'm designing a system where users will be able to register and afterward authenticate with client certificates in addition to username/password authentication.

The client certificates will have to be valid certificates issued by a configured list of certificate authorities and will be checked (validated) when presented.

In the registration phase, I need to store part(s) of the client certificate in a user repository (DB, LDAP, whatever) so that I can map the user who authenticates with client certificate to an internal "user".

One fairly obvious choice would be to use certificate fingerprint; But fingerprint itself is not enough, since collisions may occur (even though they're not probable), so we need to store additional information from the certificate. This SO question is also informative in this regard.

RFC 2459 defines (4.1.2.2) that certificate serial number must be unique within a given CA.

With all of this combined, I'm thinking of storing certificate serial number and certificate issuer for each registered user. Given that client certificates will be verified and valid, this should uniquely identify each client certificate. That way, even when client certificate is renewed, it would still be valid (serial number stays the same, and so does the issuer).

Did I miss something?

Answer 1

You have several solutions:

1. Storing a fingerprint. Yes you are right, a collision is theoretically possible but the probability is really really low and you can consider it does not happen : 2 users in your system will not have accidentally the same certificate fingerprint. However hash algorithms are getting weaker over time and an attacker may try to forge a certificate whose fingerprint matches a registered one. This attack is called second preimage attack and is pretty hard to do since the attacker does not try to forge some random data matching the fingerprint but a real X.509 certificate which can pass the initial validation phase (i.e. hacking the PKI). Pretty hard :) But if you really want to prevent yourself against collision you can store 2 fingerprints with 2 distinct algorithms (e.g. SHA-1 and SHA-256).

2. Storing the certificate issuer and serial number. Yes it can be used as a unique certificate identifier. As you wrote, the standard (RFC 5280 obsoletes RFC 2459) indicates [The serial number] MUST be unique for each certificate issued by a given CA. However it also means that when the certificate is renewed the serial number changes since a new certificate is issued by the CA.

A final remark: you want to handle certificate renewal and it is a good idea, a lot of software editor forget that certificates have to be renewed. But you must be aware that almost everything may change in the certificate: the subjet name (people may change their name, women get married...), the issuer name (the certificate supplier company may change...), the key algorithm, the key size, the extensions... In your system the certificate renewal process will probably be pretty close to the initial user certificate registration.