Authentication failures
There are a number common reasons for authentication failures during the SSL handshake.
- A certificate has been found in a Certificate Revocation List or Authority Revocation List
- You can check certificates against the revocation lists published
by the Certificate Authorities.
A Certificate 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, see Working with revoked certificates.
- An OCSP responder has identified a certificate as Revoked or Unknown
- You can check certificates using OCSP. An OCSP responder can return a response of Revoked, indicating that a certificate is no longer valid, or Unknown, indicating that it has no revocation data for that certificate. For more information, see Working with revoked certificates.
- 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.
- 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:
- With the SSLCAUTH parameter set to REQUIRED or
- With an SSLPEER parameter value
- There is no matching CA root certificate or the certificate chain is incomplete
- Each digital certificate is issued by a Certificate 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.
However, certain SSL implementations such as GSKit, DCM, and RACF validate the certificates as long as the trust anchor (ROOT CA) is present, with some of the intermediate CA not present in the trust chain. Therefore, it is important to ensure that the server-side certificate store contains the complete trust chain. Also, the technique of selectively removing signer (CA) certificates must not be used to control connectivity to the queue manager.
For more information, see How certificate chains work.