Detailed Explanation of HTTPS Certificate Verification Process

Detailed Explanation of HTTPS Certificate Verification Process

1. Knowledge Point Description
HTTPS certificate verification is a crucial step in the TLS/SSL handshake process, ensuring trusted communication identity between the client and server. The verification process involves certificate chain validation, digital signature verification, validity period checks, etc., to prevent man-in-the-middle attacks or forged certificates. Understanding this process aids in troubleshooting HTTPS connection errors, configuring server certificates, and developing secure applications.

2. Detailed Steps of Certificate Verification

Step 1: Client Receives Server Certificate

  • During the TLS handshake, the server sends its digital certificate to the client.
  • The certificate includes: server public key, Certificate Authority (CA) information, validity period, domain name, etc. (complying with the X.509 standard).

Step 2: Build Certificate Chain

  • The client checks the certificate's issuer and looks for the corresponding root CA certificate from the local trusted root certificate store (such as the root certificates pre-installed in the operating system or browser).
  • If the certificate is issued by an intermediate CA, the client needs to verify step by step, forming a complete chain: "server certificate → intermediate CA certificate → root CA certificate".

Step 3: Verify Certificate Signature

  • The client uses the public key of the superior CA to decrypt the digital signature of the current certificate, obtaining the certificate's hash value.
  • The client independently calculates the hash value of the certificate content and compares whether the two match:
    • Match: Proves the certificate has not been tampered with and was issued by a legitimate CA.
    • Mismatch: Terminates the connection and reports an error (e.g., "SSL_CERT_BAD_SIGNATURE").

Step 4: Check Certificate Validity Period

  • The client verifies whether the certificate's start and end times fall within the current time range.
  • If the certificate is expired or not yet valid, an error is triggered (e.g., "SSL_CERT_DATE_INVALID").

Step 5: Check Certificate Revocation Status

  • The client confirms whether the certificate has been actively revoked by the CA through the following methods:
    • CRL (Certificate Revocation List): Downloads the revocation list published by the CA and checks if the certificate's serial number is on the list.
    • OCSP (Online Certificate Status Protocol): Queries the CA's OCSP server for the certificate status (the response must contain a valid signature).
    • OCSP Stapling: The server directly provides the OCSP response during the handshake, reducing client query latency.

Step 6: Verify Domain Name Match

  • The client checks whether the Subject Alternative Name (SAN) or Common Name (CN) in the certificate matches the currently accessed domain name.
  • A mismatch results in an error (e.g., "SSL_CERT_BAD_IDENTITY").

Step 7: Final Trust Confirmation

  • After all the above steps pass, the client trusts the server certificate and uses the public key within it to encrypt the symmetric key for subsequent communication.

3. Common Issues and Practical Significance

  1. Incomplete Certificate Chain: The server did not send the intermediate CA certificate, causing the client to fail in building a complete chain. Solution: Configure the server to include the full certificate chain.
  2. Self-Signed Certificate: Not issued by a public CA, requiring manual import of the certificate into the client's trust store.
  3. Mixed Content Risk: Loading HTTP resources within an HTTPS page may cause the browser to warn of certificate verification failure.

4. Summary
HTTPS certificate verification ensures the authenticity of server identity through cryptographic mechanisms, with each verification step corresponding to the defense against specific security risks. In development or operations, attention must be paid to certificate configuration details to avoid service interruptions or security vulnerabilities caused by verification failures.