What is Certificate Transparency?

Certificate Transparency: A Complete Overview

Many instances have revealed how easy it is to tamper with the HTTPS website’s security. Due to all these, Google made a major announcement in 2015. This is the first time people have come across the term ‘Certificate Transparency’ as Google mandated that all CAs log their EV SSL certificates for CT. Since then, Google has expanded the need to cover the different types of SSL Certificates with CT. About time we understand what it is.

What is Certificate Transparency?

Certificate Transparency is a security mechanism that aims to improve the security of the public key infrastructure (PKI) by publicly logging all issued SSL/TLS certificates. This allows anyone to monitor the issuance of new certificates and detect any suspicious or fraudulent activity. Domain owners use this mechanism to monitor the issuance of certificates for their domains and detect any unauthorized certificates. To accomplish this, individuals send a copy of the certificate to a CT log, which stores all issued certificates and is publicly accessible as an append-only log.

The logs are auditable, meaning that anyone can check that a certificate has been properly logged by looking it up in the log, and also anyone can detect any suspicious or fraudulent activity, like a certificate that was issued for a domain that the certificate authority should not have issues for a domain that was not registered.

To ensure the validity of the presented certificate and that a trusted log has logged it, browsers and other clients can also check the logs. This is done by checking the certificate against the Certificate Transparency logs to ensure that it has been properly logged and that it has not been revoked. Without CT in place, Chrome shows an error message like this:

ERR_CERTIFICATE_TRANSPARENCY_REQUIRED.

So how is certificate transparency achieved? Let’s find out.

How are Certificate Transparency Logs Achieved?

Achieving certificate transparency involves the following step-by-step process:

Step-1: The website owner requests a certificate from the Certificate Authority

First, the website owner requests a certificate from the certificate authority (CA) in order to secure their website using SSL/TLS. The website owner may do this through an online form on the CA’s website or by contacting the CA directly.

The website owner typically provides information to the CA, including the domain name for which the certificate will be issued, the organization that owns the domain, and the contact information for the organization. They may also need to provide additional information, such as the server’s IP address, to prove they have domain control.

Once the CA has received the necessary information, it will verify that the website owner has the right to request a certificate for the specified domain. Doing so helps to prevent the issuance of fraudulent or unauthorized certificates.

Step-2: CA issues a pre-certificate

After the CA has verified the website owner’s identity and the authenticity of their request, it will proceed to issue a precertificate. A precertificate contains all the necessary information for a certificate to be issued, but it is not yet valid. The precertificate includes the domain name, the public key, the expiration date and other information about the certificate.

When the CA issues the precertificate, it also attaches a ‘precertificate poison’ extension. To prevent the precertificate from being used as a valid certificate, this extension uses a hash of the precertificate.

Once the CA generates the precertificate, they send it to one or more CT logs.

Step-3: CA sends precertificates to logs

After the CA issues the precertificate, it sends it to one or more CT logs. CAs typically use the CT protocol, which is a standard way to send precertificates to CT logs, to accomplish this.

The CT protocol defines a set of methods for CAs to submit precertificates to logs and for logs to return SCTs (code signing time stamping)  to the CAs. The protocol is based on HTTP and designed to be simple and easy to implement.

When the CA sends the precertificate to a CT log, it typically includes the precertificate itself and other information, such as the log’s public key, ID, and URL.

The CT log receives the precertificate and performs a series of checks to ensure the precertificate is valid. This includes checking that the domain name is correct, that the public key is valid and that the precertificate poison is present.

Step- 4: Pre-certificates are added to the logs

After the CA sends the precertificate to the Certificate Transparency logs, the CT logs will receive the precertificate and add it to their logs. This process is known as ‘logging’ the precertificate. The log will append the new precertificate to its existing log of all previously logged certificates.

When the CT logs receive the precertificate, they will perform a series of checks to ensure that the precertificate is valid. This includes checking that the domain name is correct, that the public key is valid, and that the precertificate poison extension is present. The CT logs also check that the precertificate is not duplicated and wasn’t already logged.

Once the CT logs have confirmed that the precertificate is valid, they will add it to their logs and make it publicly available for anyone to see. By doing so, the CT logs provide transparency into the process of issuing SSL/TLS certificates and allow anyone to monitor the issuance of new certificates and detect any suspicious or fraudulent activity.

Step-5: Logs return SCTs to the CA.

After the CT logs have added the precertificate to their logs and confirmed that it is valid, they will return an SCT to the CA.

A SCT provides cryptographic proof that the precertificate has been properly logged. The CT log generates a digital signature based on the contents of the precertificate and the time at which it was logged, which results in a SCT that provides cryptographic proof of proper logging. SCT contains the log’s public key, the timestamp, and a hash of the precertificate. The CT log sends the SCT to the CA, and the CA verifies that the precertificate has been properly logged using it. The CA will receive one SCT from each log of the precertificate sent.

Once the CA has received the SCTs, it will use them to confirm that the precertificate has been properly logged. The CA will verify that trusted CT logs issued the SCTs and that they are still valid.

Step-6: CAs send the certificate to the domain owner

CAs use the CT protocol to log SSL/TLS certificates they issue in publicly available logs. These logs allow domain owners to monitor for fraudulent or mistakenly issued certificates. Once a certificate is logged, it is considered ‘CT-compliant.’

When a Certificate Authority (CA) issues a certificate for a domain, it typically sends the certificate to the domain owner through email or their account portal. This process can vary depending on the CA and the method used to verify the domain ownership.

If you are the domain owner and have not received your certificate, you can contact the CA for assistance in retrieving it. Once the CA has received the SCTs, it issues the final certificate and sends it to the domain owner.

Step-7: Browsers and user agents help keep the web secure

Browsers and user agents help keep the web secure: Browsers and other user agents check the CT logs when a certificate is presented to ensure that it has been properly logged and that it has not been revoked.

Step-8: Certificate Transparency Logs are cryptographically monitored

CT logs are cryptographically secured and auditable, meaning anyone can check that a certificate has been properly logged by looking it up in the log and detecting any suspicious activity.

Voila! This is how Certificate Transparency is achieved. Now let us see how to check whether a website supports CT.

How to Check if Certificate Transparency Log is Supported on a Website?

There are a few ways to check if a website supports Certificate Transparency. Here are some of them:

• Use a CT Log Viewer: There are several CT log viewers available online, like CRT.sh and Decoder, that allow you to search for a specific domain and check if it has any CT-compliant certificates.

• Check the Certificate Details: You can check the details of a website’s SSL/TLS certificate by clicking on the lock icon in the browser’s address bar and selecting ‘Certificate.’ Look for the ‘CT Compliance’ section in the certificate details to see if it is marked as CT-compliant.

• Use a CT Scanner Tool: Online CT scanning tools allow you to check if a website supports CT.

• Use Browser Developer Tools: Some browsers, such as Google Chrome, have developer tools that allow you to view a website’s certificate details, including CT compliance. To access this feature, open the developer tools by pressing F12 and navigating to the Security tab.

These are some of the ways to check if CT is supported on a website. That said, always remember that even though a website may support CT, it does not necessarily mean it is secure or free from vulnerabilities.

Wrapping Up

The idea behind CT is to create a publicly available append-only log of all SSL/TLS certificates, which can be used to detect the misissuance of certificates in real time. In the future, it is possible that other web browsers may also implement support for CT and may show warning indicators for sites with certificates that are not present in CT logs.

You can always use Certificate Transparency search tools to review SSL/TLS certificates that have been issued to you. It will provide an open way for website owners to monitor certificates that have been issued to them, thereby promoting transparency. That said, always remember that CT can help improve the security and transparency of the PKI, but it is just one aspect of a robust security infrastructure.

Search