0

I am trying to setup a web service which uses x509 client certificates sent during the TLS handshake for authentication as well as to check whether the user has the auhorization to access the requested ressource.

The idea is that each user is givenan access level, and some ressources are only available to the higher levels. The certificate is then used to match the user to its level.

I have had no problem configuring Apache to verify the certificate against the root CA and to forward the certificate to the back-end application ( a python-based XML-RPC server).

However I am struggling to choose which attribute(s) of the certificate I should use to map the user to his level :

  • The Common Name field seems like a natural choice, but I am wondering how secure this solution would be as nothing prevents multiple intermediary CAs from providing certificates with the same CN
  • The Public Key itself is clearly more secure, but how practical is it to use ? Will it stay the same if the client has to renew his certificate after its expiry ? There is also the problem of storage and speed of comparison of a much larger string
  • The whole certificate itself or its thumprint thumbprint could be an alternative to the public key, but the client will not be able to connect if his certificate is renewed

I am currently leaning towards the public key, but is it the best choice in this situation ? Or is there a better option ?

Thanks in avance

Kevin De Cuyper
  • 13
  • 3
  • The essential part of HTTPS client authentication is that you only accept certificates from your CA (or from certain CAs that follow specific rules on the CN). Once you have done that you can be sure that the CN is authentic. – Robert Mar 03 '19 at 13:07
  • "Will it stay the same if the client has to renew his certificate after its expiry ?" it depends on how it is renewed. By default for example with Let's Encrypt/Certbot it will be a new key. But there is an option to keep old key because sometimes it is a problem, like when you publish the key in the DNS through TLSA records, or if you do HTTP Key-Pining or things like that. – Patrick Mevzek Mar 06 '19 at 20:37
  • Some CAs may allow you to add a specific ID in the certificate, like in an extension. In which case you could control that and do the mapping you need. See also Apache `SSLOptions` case `FakeBasicAuth` for an example of mapping a certificate content to a user ID. – Patrick Mevzek Mar 06 '19 at 20:39

1 Answers1

0

Typically authentication with client certificates is done by having some private CA which issuing the client certificates and only trusting the CA when validating the client certificates. In this case the trusted CA and only this CA has full control over the subject of the certificate which means that mapping the CN to users is perfectly fine and also commonly used.

If you instead for whatever reason want to allow certificates issued by arbitrary CA's then such simple mapping can not be done as you've realized yourself. In this case a mapping between certificate pubkey or certificate fingerprint might be done, which of course requires that it is known up-front which exact certificate to expect for a specific user. And, this mapping need to be somehow renewed whenever the client certificate needs to change because it was expired.

Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172
  • Thank you, this basically confirmed my guesses. Since we do not know the client infrastructure, I'll keep pushing for a dedicated CA in order to use the CN as a basis for authentication. – Kevin De Cuyper Mar 05 '19 at 11:16
  • "And, this mapping need to be somehow renewed whenever the client certificate needs to change because it was expired." if the matching is done on the pubkey, and each certificate renewal uses the same key, then the mapping can stay fixed. – Patrick Mevzek Mar 06 '19 at 20:35