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:
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:
-trustResponder
on the OCSP responder as a workaround while you work to identify the root cause and corrective measure.3.147.205.178