Discovery has been configured to use SSL client certificate authentication, but it does not work.

The symptoms can be:

1. The browser displays the login banner (an SSL client certificate should allow access to the UI without having to provide a login/password)
2. The browser does not suggest the user to choose a SSL client certificate before displaying the login banner. The suspicion is that this is related to the problem (not necessarily true, see step 8 below)
3. After having selected a client certificate in the browser, the session is not connected. The browser displays the login banner (or an error appears)

How to troubleshoot this?

Check list:

1- Verify that it is possible to connect to the Discovery appliance using https from a desktop. To confirm, use the URL https://appliance/ui. In this example the customer is probably not automatically logged in but there must be a login banner. If the server certificate is not recognized, this does not prevent the SSL client authentication, as long the https connection is allowed.

2- The customer must be able to login with a Discovery local user (like "system").

In case Discovery is integrated with LDAP, then the customer must also be able to login with an LDAP user (at least the one that is in the SSL client certificate that has been specified).

3- The SSL client certificate authentication must be enabled in Administration > Single Sign On > Web Authentication > SSL Client Certificate Verification. More information in the documentation.

4- A client certificate must be installed in the browser. More information in the KA 000369841  Discovery: How to add a default https certificate into the “Trusted Root Certification Authorities” of your OS/browser?. 

5- The desktop being used must own the private key of this client certificate. To confirm, double click on the certificate. In the general tab, check that the message "You have a private key that corresponds to this certificate" is observed.

6- The Discovery web server must accept client certificates. To confirm, execute the following command below in the appliance. There must be at least one issuer in the section "Acceptable client certificate CA names"

7- The client certificate must have an issuer that matches one line in the list "Acceptable client certificate CA names" generated by the command above. To confirm, open the client certificate installed on the browser and go to Details > Issuer.

For example, if the client certificate shows this:

E = admin@bmc.com
CN = myCA
OU = support
O = BMC
L = Austin
S = Texas
C = US

Then the output from the command line from step 6- should contain a line like this in the section "Acceptable client certificate CA names"

/C=US/ST=Texas/L=Austin/O=BMC/OU=support/CN=myCA/emailAddress=admin@bmc.com

8- The client certificate must be compliant with the requests documented in the KA 000402566 Discovery: HTTPS Certificate and CA Certificate File Formats. and in the KA 000331959: Discovery: SSL Client certificate Authentication fails with error ERR_BAD_SSL_CLIENT_AUTH_CERT. 

9- The client certificate must have an attribute matching the "Extract Key" specified in Administration > Single Sign On > Web Authentication > SSL Client Certificate Verification > Configure.

For example:

- If Extract Key = emailAddress (default value), open the client certificate, go to the Detail tab, attribute Subject, check that there is an attribute "E" set like this:

E = user@bmc.com
CN = user
O = my company
L = Milan
C = IT

- Also check the emailAddress value with the one of the openssl commands below :

- In case of pem certificate: "openssl x509 -in  client.pem -noout -text"

- In case of pkcs12 certificate) openssl pkcs12 -in client.p12 -clcerts

It should report a line like this:

Subject: C=IT, L=Milan, O=my company, CN=user/emailAddress=user@bmc.com    
or
subject=/C=IT/L=Milan/O=my company/CN=user/emailAddress=user@bmc.com

- Another example: If Extract Key = subjectAltName.email, the following should be seen when opening the client certificate in Windows:

RFC822 Name=user@bmc.com

Other Name:

Principal Name=othername

Other Name:

Principal Name=othername@bmc.com

- This command:        

openssl x509 -text -noout -in client.pem 

Should return something like this:

X509v3 Subject Alternative Name:

email:user@bmc.com, othername:

10- In the Discovery UI, go to Administration > Logs and set the logging level for User Interface logs to DEBUG. Connect the browser to https://appliance and then check the content of /usr/tideway/log/tw_appserver.log

- This trace means that the browser did not send any certificate. In most cases, this is because the browser has no certificate matching the issuers accepted by the server (or it has no private keys for it):

    ui.web.sso.webauth.sslclientcert: DEBUG: SSL_CLIENT_VERIFY found: NONE
    ui.web.sso.webauth.sslclientcert: DEBUG: SSL_CLIENT_VERIFY is not SUCCESS

- This trace means that the browser sent a certificate matching the details below:

    ui.web.sso.webauth.sslclientcert: DEBUG: SSL_CLIENT_VERIFY found: SUCCESS
    ui.web.sso.webauth.sslclientcert: DEBUG: SSL_CLIENT_S_DN: /C=IT/L=Milan/O=my company/CN=user/emailAddress=user@bmc.com
    ui.web.sso.webauth.sslclientcert: DEBUG: Certificate has 5 extension(s)
    ui.web.sso.webauth.sslclientcert: DEBUG: Add Extension 0: basicConstraints
    ui.web.sso.webauth.sslclientcert: DEBUG: Add Extension 1: nsCertType
    ui.web.sso.webauth.sslclientcert: DEBUG: Add Extension 2: keyUsage
    ui.web.sso.webauth.sslclientcert: DEBUG: Add Extension 3: extendedKeyUsage
    ui.web.sso.webauth.sslclientcert: DEBUG: Add Extension 4: nsComment
    ui.web.sso.webauth.sslclientcert: DEBUG: Username is user@bmc.com (extracted via emailAddress)

- In case of an LDAP problem, the trace above could be followed by a trace like this:

ui.web.sso.webauth.sslclientcert: DEBUG: user@bmc.com is not a valid LDAP user