Authentication failures

There are a number common reasons for authentication failures during the TLS handshake.

These reasons include, but are not limited to, those in the following list:

    A certificate has been found in a Certificate Revocation List or Authority Revocation List
    We 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 Work with revoked certificates.

    An OCSP responder has identified a certificate as Revoked or Unknown
    We 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 Work 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 TLS client does not have a certificate
    The TLS server always validates the client certificate if one is sent. If the TLS client does not send a certificate, authentication fails if the end of the channel acting as the TLS 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 TLS 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.

For more information about the terms used in this topic, see:

Parent topic: Security reference