Understanding authentication failures
This chapter explains some common reasons for authentication failures during the SSL handshake:
- A certificate has been found in a Certificate Revocation List or Authority Revocation List
- You have the option to check certificates against the revocation lists published by the Certification Authorities.
A Certification Authority can revoke a certificate that is no longer trusted by publishing it in a Certificate Revocation List (CRL) or Authority Revocation List (ARL). For more information, refer to Working with Certificate Revocation Lists and Authority Revocation Lists.
- A certificate has expired or is not yet active
- Each digital certificate has a date from which it is valid and a date after which it is no longer valid, so an attempt to authenticate with a certificate that is outside its lifetime fails.
- A certificate is corrupted
- If the information in a digital certificate is incomplete or damaged, authentication fails.
- A certificate is not supported
- If the certificate is in a format that is not supported, authentication fails, even if the certificate is still within its lifetime.
- SSL has encountered something it does not support
- You might be trying to access LDAP CRLs on Linux (zSeries platform). This is not possible.
- The SSL client does not have a certificate
- The SSL server always validates the client certificate if one is sent. If the SSL client does not send a certificate, authentication fails if the end of the channel acting as the SSL server is defined:
- There is no matching CA root certificate or the certificate chain is incomplete
- Each digital certificate is issued by a Certification Authority (CA), which also provides a root certificate that contains the public key for the CA. Root certificates are signed by the issuing CA itself. If the key repository on the computer that is performing the authentication does not contain a valid root certificate for the CA that issued the incoming user certificate, authentication fails.
Authentication often involves a chain of trusted certificates. The digital signature on a user certificate is verified with the public key from the certificate for the issuing CA. If that CA certificate is a root certificate, the verification process is complete. If that CA certificate was issued by an intermediate CA, the digital signature on the intermediate CA certificate must itself be verified. This process continues along a chain of CA certificates until a root certificate is reached. In such cases, all certificates in the chain must be verified correctly. If the key repository on the computer that is performing the authentication does not contain a valid root certificate for the CA that issued the incoming root certificate, authentication fails. For more information, refer to How certificate chains work.
For more information about the terms used in this chapter, refer to:
Parent topic:
Working with WebSphere MQ SSL support
sy12950_