Troubleshooting the User Certificate Authentication feature

Troubleshooting the User Certificate Authentication feature

Find solutions to problems with the User Certificate Authentication feature.

Problem Actions to take
The server is not responding even though it is accessible through the browser when it uses a certificate that is signed by a private CA. Make sure we can reach the MobileFirst Server on your device. For example, go to the operations console on the device's internet browser. If we can reach it, then the most likely error is that the client is not trusting the server's certificate. The server's certificate is most likely a certificate that is signed by a private CA. To fix this problem, install the root CA on the device so that it is trusted. See Establishing trust.
Certificates that are signed by a private CA work on Android but not on iOS. When Android is in debuggable mode, some SSL errors are ignored. This behavior gives the impression that SSL is working. Android is in debuggable mode when the APK is unsigned, or when you explicitly set it in the manifest. . Verify that the debuggable flag is set to false (debuggable:false) in the Android manifest file, or sign the APK. Make sure that there is no explicit declaration in the manifest that sets it to debuggable mode. For more information about how to trust certificates that are signed by the private CA, see Configure SSL using untrusted certificates.
javax.net.ssl.SSLPeerUnverifiedException on Android or WLSecureRequest:sendRequestToServerWithURL A connection failure occured: SSL Problem (Possible causes may include a bad/expired/self-signed certificate, clock set to the wrong date) on iOS. One of the certificates was not trusted. Usually it is because the server did not send the server certificate with the whole certificate chain in the right order, when it uses an intermediate CA. See SSL configuration. Another explanation can be that the certificate was revoked by the certificate revocation list (CRL), and the PKI did not allow the device to renew the certificate.
Authentication fails with an exception in the PKI. There was an exception somewhere in the PKI bridge. To see more information about the exception, make sure the MobileFirst Server has trace that is enabled for com.worklight.*=all, and search for UserCertificate* in the trace file. Possible reasons include a syntax or runtime error in the adapter when we use the adapter-based PKI bridge, or a configuration error in the embedded PKI.
The client certificate is expired or not yet valid. If the certificate is expired or not yet valid, the client logs this information in the client's logs. The client then proceeds with the authentication as if it did not have a certificate. The PKI then decides whether it allows the user to renew the certificate or not. In the 'certificate not yet valid' scenario, verify that the device and the server clocks are set correctly.

Parent topic: User certificate authentication

Problem	Actions to take
The server is not responding even though it is accessible through the browser when it uses a certificate that is signed by a private CA.	Make sure we can reach the MobileFirst Server on your device. For example, go to the operations console on the device's internet browser. If we can reach it, then the most likely error is that the client is not trusting the server's certificate. The server's certificate is most likely a certificate that is signed by a private CA. To fix this problem, install the root CA on the device so that it is trusted. See Establishing trust.
Certificates that are signed by a private CA work on Android but not on iOS.	When Android is in debuggable mode, some SSL errors are ignored. This behavior gives the impression that SSL is working. Android is in debuggable mode when the APK is unsigned, or when you explicitly set it in the manifest. . Verify that the debuggable flag is set to false (debuggable:false) in the Android manifest file, or sign the APK. Make sure that there is no explicit declaration in the manifest that sets it to debuggable mode. For more information about how to trust certificates that are signed by the private CA, see Configure SSL using untrusted certificates.
javax.net.ssl.SSLPeerUnverifiedException on Android or WLSecureRequest:sendRequestToServerWithURL A connection failure occured: SSL Problem (Possible causes may include a bad/expired/self-signed certificate, clock set to the wrong date) on iOS.	One of the certificates was not trusted. Usually it is because the server did not send the server certificate with the whole certificate chain in the right order, when it uses an intermediate CA. See SSL configuration. Another explanation can be that the certificate was revoked by the certificate revocation list (CRL), and the PKI did not allow the device to renew the certificate.
Authentication fails with an exception in the PKI.	There was an exception somewhere in the PKI bridge. To see more information about the exception, make sure the MobileFirst Server has trace that is enabled for com.worklight.=all, and search for UserCertificate in the trace file. Possible reasons include a syntax or runtime error in the adapter when we use the adapter-based PKI bridge, or a configuration error in the embedded PKI.
The client certificate is expired or not yet valid.	If the certificate is expired or not yet valid, the client logs this information in the client's logs. The client then proceeds with the authentication as if it did not have a certificate. The PKI then decides whether it allows the user to renew the certificate or not. In the 'certificate not yet valid' scenario, verify that the device and the server clocks are set correctly.