28

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?

Community
  • 1
  • 1
miha
  • 3,287
  • 3
  • 29
  • 44

3 Answers3

23

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.

Community
  • 1
  • 1
Jcs
  • 13,279
  • 5
  • 53
  • 70
  • My initial approach was to use serial number + issuer. When I examined my certificates I noticed that the renewed certificate has the same serial number as its predecessor -- but looking at RFC5280 I see that CA is not 100% conformant to RFC. The rationale for serial no. was exactly what you mention: renewal. Given that serial no. "MUST" change and fingerprint also changes with certificate renewal, is there an attribute that is not changed and still provides "unique identification within a given CA"? – miha Mar 13 '11 at 18:41
  • My bad: I was examining two copies of the _same_ cert. Serial no. changes, and so does the Subject (in my case it contains some serial no. (different one)). RFC (4.1.2.6): "The DN MUST be unique for each subject entity certified by the one CA as defined by the issuer field. .." This means I can use either Subject or Serial number combined with issuer. The difference being that Subject MAY be reused for the same entity within CA (thus handling renewals). – miha Mar 13 '11 at 19:34
  • 1
    I talked to an administrator of a Slovene CA (Halcom) and for instance, they maintain the subject field with renewal, unless person data changed (email change, marriage, etc). So taking all of this into account, subject and issuer fields of the certifificate seem to be the best candidates to remember. – miha Mar 15 '11 at 05:56
  • Yes, the subject name (or a part of it like the common name) seems to be the best candidate for immutability during a renewal. – Jcs Mar 16 '11 at 18:52
1

The best way to uniquely identify a user is by email address. In the registration process a valid email address must be mandatory. Then you associate the certificate serial number and issuer or perhaps a hash of the the certificate itself with the email and the user id. Then, when the certificate expires or the user changes the certificate he/she will have a "renew certificate link" where he enters the email address and he receives a link to upload the new certificate. You can then replace the old serial/issuer with the new one.

Tofeeq Ahmad
  • 11,935
  • 4
  • 61
  • 87
dikran
  • 19
  • 1
0

I decided to concatenate the issuer name, a delimiter |, and the DN.

Hopefully, this solves the problem of using serial numbers which change on renewal.

colan
  • 2,818
  • 2
  • 20
  • 17