SSL/TLS client authentication - practical client cert validation

Question

How do real HTTPS servers validate client certificates? My context is business-to-business rather than regular human clients. I understand basic chain validation to a trusted root CA cert. But do servers typically have some sort of configuration to specify the subject names of certs they want to trust, or fingerprint values?

In one scenario a private CA acting on the server's behalf could sign the client certs so that ONLY their certs would be accepted. In another scenario the server trusts certs signed by any "regular" trusted CA (of the client's choosing) in their trust store. But if your system is to be closed (as in a business-to-business case) then you want additional filtering.

I realize at the application level if the cert chain is available then any further custom filtering can be done. But I just want to know in the real world, out of the box, what additional config web servers have to deal with this today during the TLS handshake.

Thank you.

Answer 1

When the server uses IIS, client authentication means mapping the client certificate to an identity, i.e. an account (local account or domain account, depending on context). IIS may apply two distinct methods, with confusing names:

• clientCertificateMappingAuthentication: IIS will look for a domain account that either contains a copy of the exact client certificate, or at least a domain account whose User-Principal-Name attribute matches the one contained in the certificate (as a Subject Alt Name of type otherName, identified with a Microsoft-specified OID). Use of the UPN is subject to some arcane conditions, including storing a copy of the immediately issuing CA certificate (not the root CA) in the "enterprise NTAuth" certificate store of the IIS server machine, or that of the AD server, or maybe both. You may use this blog page for some guidance.

• iisClientCertificateMappingAuthentication: this one has two sub-methods, that IIS documentation calls "one-to-one mapping" and "many-to-one mapping". In one-to-one mapping, the IIS configuration contains explicit mappings from an exact certificate (the complete certificate in Base64) to an account (local or domain). In many-to-one mapping, the configuration contains some rules that basically match parts of the IssuerDN and SubjectDN, and explicitly map matching certificates to a given account.

---

In the non-Microsoft world, in the Apache Web server, you would use SSLRequire to implement access rules, based on elements extracted from the certificate (in practice, IssuerDN and SubjectDN).

---

What must be remembered is that:

• Certificates are for authentication, not for authorization. The former is about making sure of who is calling, the latter about deciding whether that specific client should be allowed to perform the requested access. The IIS model does authorization primarily with access rights: once the certificate was mapped to an account, the rest is AD-specific stuff with no relation anymore with certificates; this could be simple file access rights, or possibly finer-grained authorization configuration with AzMan or whatever replaces it in recent Windows versions.

  Trying to do authorization with certificates (e.g. issuing client certificates that contain some information such as "can do operation X") usually ends in tears and grinding of teeth. For all its clunkiness, the Microsoft method has the merit of clearly separating authentication and authorization.

• There is always a certificate validation step, which ensures that the certificate is genuine and acceptable. This includes checking all dates, cryptographic signatures, name chaining, revocation status...

• There may be an additional filtering on paths, like what IIS does when using UPN-based client certificate mapping: the presence of the issuing CA in the enterprise NTAuth store acts as an extra check that will reject certificate paths that are valid, come from an accepted root, but did not go through the expected intermediate CA.

Answer 2

I'm not sure that there's any one solution. Different strategies work for implementing different functionality.

A common strategy for a B2B deployment is for the server's organization to act as CA and sign public keys from clients. When a client cert is received, the server validates the signature and then maps the cert to a user. The user mapping is typically done by extracting a field out of the cert but a cert lookup or other strategy can also be employed.

How you implement this validation and mapping will depend on the server that you're using.

One thing to pay attention to is that you can only trust client certs that have been used in an SSL mutual auth handshake. Don't let the client pass you their cert. You need to get it from the SSL subsystem to make sure it has been validated (ie: the client has proven that they hold the private key corresponding to the cert).