Discovery has been configured to use SSL client certificate authentication, but it does not work. The symptoms can be:
|
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") and 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 4- A client certificate must be installed in the browser. This is been done with a file sent by the local IT group. This file contains both the client certificate and the private key for this certificate. This file can be a .p12 (pkcs12 format). A DER or PEM certificate is not sufficient (it does not contain the private key). To confirm with Chrome, go to Settings > Advanced > Privacy and Security > Manage Certificates > Personal tab. To confirm with IE, go to Settings > Internet options > Content > Certificates. 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" openssl s_client -connect localhost:443 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 ... the output of the openssl command above 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- Use Chrome or Firefox to connect to the Discovery appliance using https://Discovery. The browser should display a popup window with a prompt to choose one of the available client certificates. Note that IE only displays this popup if more than one client certificate has an issuer matching the issuer of the server certificate. If there is only one suitable certificate, IE will use it (and the user won't be prompted about that decision). 9- The client certificate must be compliant with the requests documented in KA 000133223. 10- 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 The command below ... openssl x509 -text -noout -in client.pem should return something like this ... X509v3 Subject Alternative Name: email:user@bmc.com, othername: 11- In the Discovery UI, set the logging level for User Interface logs to DEBUG. Connect the browser to https://Discovery and 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 should be followed by a trace like this: ui.web.sso.webauth.sslclientcert: DEBUG: user@bmc.com is not a valid LDAP user |