PingAuthorize

Certificate trust

When a server presents its certificate chain to a client during TLS negotiation, the client decides whether to trust the certificate chain and concludes whether it is communicating with a legitimate server instead of an impostor.

If a client is tricked through DNS hijacking into communicating with a rogue application instead of with a legitimate server, the application can steal the client’s credentials, or can fool the client into concluding that it has performed an action that it has not performed. If a rogue application acts as a broker between the client and the legitimate server, the client might be unable to detect the change, and the malicious application might be capable of stealing data or altering the communication. Consequently, you should avoid trust all or blind trust options in a production environment.

When determining whether to trust a server certificate chain, a client performs the following steps.

jjt1610752070457

Processing steps

  1. Verifies that it has received the complete certificate chain.

    If a server presents an incomplete chain, the client must ensure that it can complete the chain with information in an explicitly provided trust store or default trust store. If the client cannot complete the certificate chain, the chain is not trusted.

  2. Verifies that each subsequent certificate in the chain is the issuer certificate for, and that its private key was used to sign, the certificate that precedes it.

    If a certificate chain contains extraneous certificates, or if a subsequent certificate did not issue the certificate that precedes it, the chain is not trusted.

  3. Confirms that it has a reason to trust the certificate at the root of the chain.

    This step is generally performed by ensuring that the root certificate authority (CA) certificate can be found in either a default trust store or a trust store that is configured for use by the client. If the client has no prior knowledge of the root CA certificate, the chain is not trusted.

  4. Verifies that the current time lies within the validity window for each certificate in the chain.

    The chain is not trusted under the following conditions:

    • When the notBefore value of any certificate in the chain is later than the current time.

    • When the notAfter value of any certificate in the chain is earlier than the current time.

  5. Verifies that the server certificate at the head of the chain is suitable for the server with which the client thinks it is communicating.

    The client must verify that the address used to connect to the server matches one of the following values:

    • The CN attribute of the certificate’s subject.

    • One of the values of any subject alternative name extension.

These steps represent a starting point. If necessary, the client can perform additional types of validation. For example, if a root or intermediate certification authority maintains a certificate revocation list (CRL) or supports the online certificate status protocol (OCSP), the client must verify that none of the certificates in the chain has been revoked. The client can also verify that the CA certificates include the basic constraints extension, and that the server certificate does not contain too many levels. Other checks, like those that use certificate policy extensions, can also be performed.