High Level Overview of the SSL/TLS process and Inspecting the contents of Google’s certificate
Picture yourself navigating a website, only to be met with a glaring warning that reads, “Your connection is not private” Immediately, an alarm sets off in your mind, cautioning you against potential risks to your personal information.
In contrast, you encounter another website that seamlessly loads, accompanied by a comforting padlock symbol in the address bar, signifying its security. You proceed with confidence, knowing your data is under protection.
Have you ever wondered what makes these two experiences so different? The answer lies in the world of SSL/TLS — a powerful protocol that safeguards our online interactions and ensures data confidentiality, integrity, and authenticity.
This article is not going to explain the basics of SSL/TLS, rather it is a high level overview of the process, as my core purpose is to inspect the contents of Google’s certificate. So, I’ll just dive straight into the technicalities involved in the SSL/TLS process.
CERTIFICATE AUTHORITY
The Certificate Authority (CA) is the cornerstone of the entire SSL/TLS process.
NB: The CA has it’s own public & private key, and the CA also has a self-signed certificate (which is the identity of the CA)
If a server (any website on the internet) wants to acquire a certificate, such that when people visit it, they can do so securely; the server needs to have it’s own public and private key, just like the CA has it’s own public and private key. The second thing the server needs to do is to generate a Certificate Signing Request (CSR). The CSR is the file you submit to the CA to acquire an actual certificate, so that people visiting your site can see that it is secure.
Let me explain the CSR in further details:
The CSR contains the server’s public key, and it is usually signed by the server’s private key i.e. anyone that submits a CSR (which usually includes a public key) will also have its corresponding private key. This proves authentication.
Process of acquiring a signed certificate from the CA
After the process above, the server sends the CSR to the CA, the CA is going to inspect the contents of the CSR, this is to make sure the server requesting a signed certificate for a particular site e.g. example.com actually has the private key for example.com, after the CA validates the identity of the server, it’ll then sign the certificate with it’s private key (the CA’s) using the information from the CSR the server provided to validate it’s identity. The certificate signed by the CA was signed by the CA’s private key, then the signed certificate is then given to the server. Then the server can provide this signed certificate to any of it’s client so that they can connect securely to their site
What is the actual content in Google’s Certificate
We’ll be using a Linux utility called “openssl” to explore and inspect the contents of Google’s certificate. openssl is a utility that gives you a bunch of tools which you can use to examine SSL/TLS
First of all, to create an SSL/TLS connection with Google’s website google.com, we use the command “openssl s_client -connect google.com:443”
It will display the contents of Google’s certificate.
The certificate generated is in base64 encoded format. We’ll need to feed the certificate through an interpreter. openssl has an interpreter we can use. But first, we’ll need to create a text file and paste the contents of the certificate there
After creating the file and pasting in the contents of the certificate, we’ll then enter the command “openssl x509 -in google.com-cert -text -noout”. It’ll present the certificate in a human readable format
All the images above are the human readable contents of a certificate. I’m going to explain the contents of the certificate below:
First of all, the contents of a certificate is governed by the x.509 standards i.e. the standard that says that this is how a public key certificate should look like.
The x.509 standard states that there should be 3 sections in a certificate:
- CERTIFICATE DATA: Remember that it is the CA that creates a certificate, using information it gathers from the CSR sent by the server. So, all the fields above in the Certificate Data section of the certificate was filled by the CA itself. So what the CA does is, it takes all the contents of the certificate data and passes it through an hashing algorithm, and encrypts the resulting digest/hash with the CA’s private key, the result of this is the “Signature” of the certificate (the signature is the third section of a certificate).
2. SIGNATURE ALGORITHM: For the second section “Signature Algorithm”, it specifies the type of hashing algorithm that was used. The signature algorithm section specifies two things: the hashing algorithm that was used and the asymmetric encryption algorithm that generated the public and private keys used for signing the certificate. NB: notice that the “Signature Algorithm” section was also repeated in the “Certificate Data” section, this is because when the certificate is generated, it only takes information from the “Certificate Data” section and pass through the hashing algorithm to generate a “Signature”. And there is a signature algorithm already specified for this particular signature, so basically it is duplicated to make sure that the algorithm used to generate the signature matches the one specified in the certificate itself. This enhances the security of the certificate and further confirms the Authenticity and Integrity of the certificate.
3. SIGNATURE
The most important contents of a certificate are inside the Certificate Data. what you’ll find inside the Certificate Data include:
Version: simply specifies the version of x.509 certificate a particular certificate is using. There are three version types
- (0x0) this is x.509 version 1 and it is no longer used today
- (0x1) this is x.509 version 2 certificate, this is rarely used today and you should avoid using this if possible
- (0x2) this is x.509 version 3 certificate, which is the most commonly used certificate in today’s world.
x.509 version 3 included “certificate extensions”. Certificate extensions are additional fields that you can add to an SSL/TLS certificate.
Google uses the x.509 version 3 certificate
Serial Number: the serial number is a 20 bytes (160 bits) digit that uniquely identifies a certificate given by a particular CA. The serial number is used to lookup the validity of a certificate i.e. no certificate generated by Google's CA should have the same serial number
Signature Algorithm: signature algorithm section consists of the hashing algorithm used to hash the certificate data and the asymmetric encryption used to sign the public and private keys. google.com’s signature algorithm is sha256WithRSAEncryption i.e. it uses the sha256 hashing algorithm and the RSA private key for the signing
Validity: validity is the duration a certificate is valid. It specifies two values: a “Not Before” and a “Not After” value.
google.com’s Not Before date is: May 19 2023 12:53:06 GMT and the Not After date is: August 11 2023 by 12:53:05 GMT. This means that this particular certificate was invalid before May 19 and will also be invalid after August 11
Subject & Issuer: the “Subject” field is going to tell us the identity of the server. The “Issuer” field indicates the CA that issued the certificate. The contents of the Subject & Issuer fields are specified in Distinguished Names (DN) format. Distinguished Name format is a hierarchy of “Attribute:Value” pairs. E.g. “C=NG” C is the attribute that stands for country, while NG is the value that stands for Nigeria. Another example is ST=Lagos. Attribute is ST which is state while value is Lagos. Down to the CN attribute, which stands for Common Name. the most important attribute is the CN, both the subject and issuer must have this, this is according to the x.509 standards that say ther CN must exist in eveery single Distinguished Name. the common name is so important because it is what is verified against the URL in the address bar. The CN can include a wildcard (*) e.g badssl.com is protected while wrong.host.badssl.com is not.
If you check the certificate data for the two, you’ll see the importance of wildcards in protecting domains. In Google's case “map.google.com,” “mail.google.com” can be protected by the single wildcard on google’s CN. which is “*.google.com” but it does not protect “ng.google.com” or “ng.mail.google.com”
Public Key: the public key is presented as two different values: the “Modulus” and “Exponent” this is for RSA encryption. For elliptic curve encryption, they also provide two values: a public key value (pub) and the name of a particular curve which is the case for Google's certificate
Extensions: extensions are optional fields in a certificate that add extra features or restrictions to the certificate. Extensions only exist in x.509 version 3 certificates. And Extensions are the reason we are not going to see an x.509 version 4 certificate, because new certificate features are added as extensions.
