Transport Layer Security (TLS)
What are two questions a client must ask when receiving a certificate from a server?
Is the certificate valid and trusted? The client needs to verify that the certificate is issued by a trusted Certificate Authority (CA) and that it hasn’t expired or been revoked. This involves checking the certificate’s validity period and ensuring it is signed by a CA that the client trusts.
Does the certificate match the server’s identity? The client must ensure that the certificate’s details, such as the Common Name (CN) or Subject Alternative Name (SAN), match the server’s domain name. This helps confirm that the certificate is indeed intended for the server the client is trying to connect to.
How does the client validate that a certificate can be trusted?
Check the certificate chain of trust: The client verifies the certificate chain, which includes the server’s certificate, any intermediate certificates, and the root certificate. Each certificate in the chain must be signed by the next higher authority, ultimately leading to a trusted root certificate.
Verify the certificate’s validity period: The client checks the certificate’s validity period to ensure it hasn’t expired or isn’t yet valid. This involves checking the “Not Before” and “Not After” dates on the certificate.
Match the certificate to the server’s identity: The client ensures that the certificate’s Common Name (CN) or Subject Alternative Name (SAN) matches the server’s domain name. This confirms that the certificate is intended for the server the client is connecting to.
Check for revocation: The client checks if the certificate has been revoked by querying the Certificate Revocation List (CRL) or using the Online Certificate Status Protocol (OCSP). A revoked certificate is no longer trusted.
Verify the digital signature: The client verifies the digital signature on the certificate to ensure it hasn’t been tampered with. This involves checking the cryptographic signature against the issuing CA’s public key.
How does the client validate that the server is the true owner of a certificate?
Certificate chain verification: The client verifies the certificate chain, ensuring that each certificate in the chain is signed by a trusted Certificate Authority (CA). This chain starts from the server’s certificate and ends at a trusted root certificate.
Domain name matching: The client checks that the certificate’s Common Name (CN) or Subject Alternative Name (SAN) matches the server’s domain name. This ensures that the certificate is intended for the server the client is connecting to.
Digital signature verification: The client verifies the digital signature on the certificate using the public key of the issuing CA. This ensures that the certificate has not been tampered with and is indeed issued by a trusted CA.
Certificate validity period: The client checks the certificate’s validity period to ensure it is currently valid and has not expired.
Revocation status check: The client checks if the certificate has been revoked by querying the Certificate Revocation List (CRL) or using the Online Certificate Status Protocol (OCSP). A revoked certificate is no longer trusted.
Why is ownership important if you have already checked that the certificate is trusted?
Certificate validity and trust: This step ensures that the certificate is issued by a trusted Certificate Authority (CA), is within its validity period, and hasn’t been revoked. It confirms that the certificate is legitimate and hasn’t been tampered with.
Server identity verification: Even if a certificate is valid and trusted, it must also be confirmed that it belongs to the server you’re connecting to. This involves checking that the certificate’s Common Name (CN) or Subject Alternative Name (SAN) matches the server’s domain name. This step ensures that the certificate is intended for the specific server, preventing man-in-the-middle attacks where an attacker might present a valid certificate for a different domain.
What are the two methods the client answers this question? What are the two results which occur with either methods?
Domain Name System (DNS) verification: The client checks that the certificate’s Common Name (CN) or Subject Alternative Name (SAN) matches the server’s domain name.
Result:
Match: If the names match, the client can proceed with the connection, confident that the certificate is intended for the server.
Mismatch: If the names do not match, the client will likely terminate the connection or display a warning, indicating a potential security risk.
Public Key Infrastructure (PKI) verification: The client verifies the digital signature on the certificate using the public key of the issuing Certificate Authority (CA).
Result:
Valid signature: If the signature is valid, it confirms that the certificate has not been tampered with and is issued by a trusted CA.
Invalid signature: If the signature is invalid, the client will terminate the connection or display a warning, indicating that the certificate may be compromised or fraudulent.
What determines which method gets used?
Domain Name System (DNS) verification:
Usage: This method is always used as part of the TLS handshake. The client checks the certificate’s Common Name (CN) or Subject Alternative Name (SAN) against the server’s domain name to ensure they match.
Determining factors: This is a standard part of the TLS protocol and is automatically performed by the client when establishing a secure connection.
Public Key Infrastructure (PKI) verification:
Usage: This method is also always used during the TLS handshake. The client verifies the digital signature on the certificate using the public key of the issuing Certificate Authority (CA).
Determining factors: This is another standard part of the TLS protocol. The client will automatically perform this check to ensure the certificate is valid and has not been tampered with.
Which certificates should the server send to the client?
During the TLS handshake, the server should send the following certificates to the client:
End-entity certificate: This is the server’s own certificate, which proves its identity to the client.
Intermediate certificates: These certificates link the end-entity certificate to the trusted root certificate. They help establish a chain of trust from the server’s certificate back to a trusted root certificate.
What are Domain Validation and Extended Validation certificates?
Domain Validation (DV) certificates are a type of TLS certificate where the Certificate Authority (CA) verifies that the applicant has control over the domain. This is typically done by:
Responding to an email sent to the domain’s administrative contact.
Adding a DNS TXT record.
Uploading a file to the web server.
Key characteristics:
Quick issuance: They can be issued quickly, often within minutes, as they require minimal validation.
Basic security: They provide encryption and basic assurance that the domain is controlled by the entity requesting the certificate.
Cost effective: Often cheaper or even free, making them accessible for small websites and personal projects.
Extended validation (EV) certificates are a higher level of TLS certificate that requires a more rigorous validation process. The CA verifies the legal, physical, and operational existence of the entity requesting the certificate. This includes:
Confirming the legal identity and status of the entity.
Verifying the entity’s physical and operational presence.
Ensuring the entity has exclusive rights to use the domain.
Key Characteristics:
High assurance: Provides the highest level of trust and assurance to users, as it involves thorough vetting.
Visible indicators: In some browsers, EV certificates used to display the organization’s name in the address bar, although this is less common now.
Enhanced trust: Ideal for websites that handle sensitive information, such as financial institutions and e-commerce sites.
Which are more secure?
Extended Validation (EV) certificates are generally considered more secure than Domain Validation (DV) certificates due to the rigorous validation process they undergo. Here’s a comparison:
Domain Validation (DV) certificates
Validation Level: Only verifies control over the domain.
Security: Provides basic encryption and assurance.
Use Case: Suitable for personal websites, blogs, and small businesses.
Extended Validation (EV) certificates
Validation Level: Verifies the legal, physical, and operational existence of the entity.
Security: Offers a higher level of trust and assurance due to thorough vetting.
Use Case: Ideal for financial institutions, e-commerce sites, and any website handling sensitive information.
Why EV certificates are more secure:
Thorough vetting: EV certificates require extensive validation, making it harder for malicious entities to obtain them.
Trust indicators: Although less common now, EV certificates used to display the organization’s name in the browser’s address bar, providing visible assurance to users.
Higher assurance: The detailed verification process ensures that the entity behind the certificate is legitimate, reducing the risk of phishing and other attacks.
What is the process for revocation using OCSP Stapling
OCSP stapling enhances the standard OCSP process by reducing latency and improving privacy. Here’s how it works:
Server requests OCSP response: The web server periodically requests the revocation status of its certificate from the OCSP responder (a server maintained by the Certificate Authority, or CA). This request is made in the background and not during each client connection.
OCSP responder provides response: The OCSP responder sends back a signed and timestamped OCSP response indicating the certificate’s status (e.g., “good,” “revoked,” or “unknown”). The server caches this response.
TLS handshake with stapled response: When a client (e.g., a web browser) initiates a connection to the server, the server includes the cached OCSP response in the TLS handshake. This is known as “stapling” the response to the handshake.
Client verifies OCSP response: The client verifies the stapled OCSP response. Since the response is signed by the CA, the client can trust its validity. If the response indicates that the certificate is revoked, the client will not establish a secure connection.
Periodic updates: The server continues to periodically update its cached OCSP response to ensure it always has a current status to provide during the TLS handshake.
This process reduces the need for clients to make separate OCSP requests, thereby improving performance and privacy.
Last updated
Was this helpful?