3. . If the value for DS Mapper usage is Disabled, run the following command to enable it:
netsh http add sslcert ipport=0.0.0.0:443 certhash=20c70a6c6e66c3f82cf6098b7bcd2859486ecd10 appid={4dc3e181-e14b-4a21-b022-59fc669b0914} certstorename=my verifyclientcertrevocation=Enable VerifyRevocationWithCachedClientCertOnly=Disable UsageCheck=Enable dsmapperusage=Enable clientcertnegotiation=Enable
 
 
B)Troubleshooting From the Netscaler Perspective.
The ideal Netscaler HTTP traffic for the Certificate based authentication would be similar to :

 
If the certificate is pushed to the devices and fails at the Netscaler AG, we could validate the configuration on Netscaler and collect the traces for further analysis.
From the traces we could validate the certificate along with the serial number send as shown below:
 
 
*Filter the traffic using the client IP and the Netscaler AG vip and we could see the cert exchange:

 
Validate the cert IDs to confirm whether the right certificate is used for authentication and trust purposes.
Also from the working trace (as shown above) and non working traces we could find the difference in the flow of the traffic: For eg: We could see the following error from the traces:

 
From the above trace we could see that after the cert validation and NS AG discovery, the NS AS (IP: 10.107.93.147) sends a 403 access forbidden error. On further analysis we could see that the user is Not a privileged user.
 *This issue mainly happens when the two factor auth is enabled and only one primary cert authentication policy is defined.  To fix this you could disable the two factor from ON to OFF from the cert policy and verify once.
 
            During real time scenarios we may come across other issues as well which we could be able to tackle or narrow down from the XM debug logs and the traces.
Hope this is helpful.