Client Certificate Based Authentication provides a strong level of security by means of two factors. Also, increasingly (with XenMobile and WorxMail scenarios), it is seen as a key enabler for SSO. The typical use case is that User devices will be provided the certificate to present automatically when accessing certain services. The client side application or browser presents the certificate, which allows the username to be extracted and either prefilled, or used for SSO to the Service.
The ports used by this protocol are typically TCP 443 or TCP 8443. The User will get prompted for a certificate by the service or NetScaler vServer. For browsers, the User experience will be similar to the following screenshot, as the browser checks with the User if it's okay to respond to the certificate request with the User's certificate:
The NetScaler can be set up by using a certificate profile, such as the following, to extract the username from the appropriate field and prepopulate the login form to make it easier for the User to authenticate.
The following screenshot shows one setup to extract the uPN of the User present in the Subject Alternative Name field of the certificate, so that the User doesn't have to remember this. This setting is available when creating an authentication profile of type certificate, as shown in the following screenshot:
The result is that the AAA for TM login page presented to the User has the username prefilled and the User just needs to put in their password:
Let's focus for a moment on what is different between a Client Certificate and a Server Certificate. In the following table we have them side by side for comparison and you can see that the issued to and purpose differ. Client Certificates are issued to individual users instead of an FQDN or a domain.
|
Server Certificate |
Client Certificate |
|---|---|
|
The following screenshot shows how a Server Certificate looks like: 
|
The following screenshot shows how a Client Certificate looks like: 
|
Consider the following Wireshark screenshot:
At the outset, this is very similar to the exchange we saw in the SSL chapter with no Client Authentication in place. Except that here (in the highlighted packet 472), the client also presents its certificate.
There is a key step that the server needs to take that tells the client that it has to present its certificate: Certificate Request. You can find this using the filter ssl.handshake.type==13:
If we look deeper into this packet, we will see that while requesting a certificate, the server also presents the distinguished name of the CA that it expects those certificates to be coming from:
This will help the client choose which certificate it needs to send in case it has many. In the absence of this detail it will present all its certificates. The certificate verify that we see in the same packet is to indicate to the server that it also has the private key to this certificate:
This is an important authentication step; without this confirmation, the certificate is not considered suitable for authentication, as it does not necessarily belong to the User presenting it.
On receiving the Client Certificate, the NetScaler checks three things:
- The NetScaler compares the signature on the certificate with the public key of the bound CA
- It also checks that the certificate is still valid by looking at the date
- CRL/OCSP checks are done to ensure it's not revoked
If any of these fails, the authentication will fail. A common configuration issue is that the CA certificate is not bound to the SSL vServer, or is not the correct one. The following screenshot shows what that failure looks like:
You can approach this either with a trace, or by looking at the ssl_err_clientAuth counters:
Other items to consider here are:
- Time/date on the NetScaler, server or client being incorrect can cause the certificate to incorrectly be identified as expired.
- CRL or OCSP checks failing. If OCSP is in use, ensure that the NetScaler can talk to the OCSP server. Given how critical a failure here is, you can use the
-trustResponderon the OCSP responder as a workaround while you work to identify the root cause and corrective measure.