How the web works – TLS certificates
In this post I’d like to discuss TLS certificates.
When a client connects to a TLS server, the TCP handshake is followed by a TLS handshake. The TLS handshake involves exchange various information between the client and the server that eventually enables the client to trust the server and also negotiate the encryption key that would be used to encrypt traffic.
X509 certificates allow the client to establish the identity of the server
The client is able to trust the server by authenticating the server based on a TLS certificate the server sends (which is called server certificate). The TLS certificate sent by the server identifies the server and the server’s identity can be verified as a true identity of the server by the client as the identity is vetted by a trusted certificate authority (CA) which completes due diligence in verifying the server’s identity and then digitally signing the server’s certificate.
The Distinguished Name field and/or the SubjectAltName fields of the server certificate identify the TLS server
The TLS certificate contains a subject field that is set to the Distinguished Name (DN) which identifies the owner of the certificate. The Distinguished name is a sequence of name:value pairs separated by a comma. Some of the common name:value pairs are:
CN: CommonNameOU: OrganizationalUnitO: OrganizationL: LocalityS: StateOrProvinceNameC: CountryName
As can be seen the Distinguished Name identifies the entity/owner of the certificate.
An example Certificate Subject could be:
CN = MyExampleSite
O = XYZ Limited
L = Salford
S = Greater Manchester
C = GBHostName verification check by the client is crucial to verify the identity of the server
When TLS clients connect to the TLS server, they perform an important step called Hostname verification to ensure that the host they are connecting to is indeed the host to which the server TLS certificate is issued/belongs to. Specifically, the value in the HTTP HOST request header must match the value of the CN field in the Distinguished Name field of the certificate.
X509 certificates also have another extension called SubjectAltName. This is an extension that allows a single certificate to belong to multiple subject entities. The SubjectAltName can contain a list of domain names to which the certificate belongs. HostName verification check requires that the value of HOST request header either match the SubjectAltName or the CN field of the Distinguished Name field.
Digital signature of the Certificate Authority present in the certificate assures the client that the certificate is not tampered with.
The TLS server certificate contains the digital signature of a Certificate Authority that has signed the certificate. The digital signature is derived as a two step process:
- A hash of the contents of the certificate.
- The hash generated is then encrypted using the CA’s private key.
The encrypted text is called the digital signature and is a part of the certificate.
The hash algorithm used is also specified in the certificate.
If the certificate is tampered with, the client is able to detect this when the client does a reversal of the two step process:
- Extract the digital signature from the certificate and decrypt it using the CA’s public key.
- Generate the hash of the certificate contents and compare the hash with the decrypted data generated by the previous step.
- If there is a match, the certificate is not tampered with. Otherwise, the communication will be rejected as the certificate is tampered.
In a TLSv1.2 handshake the TLS server certificate provides the server’s public key which is used to encrypt the premaster secret.
The TLS server’s certificate provides the server’s public key. The client uses this public key to encrypt the handshake messages that negotiate the secret key with the server that will be used to encrypt the traffic between the two parties
The above message shows exactly where the server’s public key is used in the TLS handshake. Up until step 3 in the picture above, the handshake happens in plain-text. After step 3, the public key in the certificate is used to encrypt the data exchanged in the further steps of the handshake process.
Conclusion:
In this post, I attempted to understand and explain the purpose of a TLS server’s certificate. In subsequent posts, I hope to discuss the format and storage of these certificates.
