(2 votes, average: 4.50 out of 5)
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.
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. This is done by sending a copy of the certificate to a CT log, which is a publicly accessible append-only log that stores all certificates that are issued.
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.
Browsers and other clients can also check the logs to ensure that the certificate being presented is valid and has been logged by a trusted log. 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:
So how is certificate transparency achieved? Let’s find out.
This is a step-by-step process of how certificate transparency is achieved.
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 that they have control over the domain.
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. This is done to prevent fraudulent or unauthorized certificates from being issued.
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 is a certificate that contains all the necessary information for the 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. This extension is a hash of the precertificate, which is used to prevent the precertificate from being used as a valid certificate.
After the precertificate is generated, the CA sends it to one or more CT logs.
After the CA issues the precertificate, it sends it to one or more CT logs. This is typically done using the CT protocol, a standard way for CAs to send precertificates to CT logs.
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 is 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.
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.
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.
An SCT is cryptographic proof that the precertificate has been properly logged. It is a digital signature generated by the CT log and is based on the contents of the precertificate and the time at which it was logged. It contains the log’s public key, the timestamp, and a hash of the precertificate. It is sent to the CA, which they use to verify that the precertificate has been properly logged. 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.
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 is issued for a domain, the CA will typically send the certificate to the domain owner via email or through 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.
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.
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.
There are a few ways to check if a website supports Certificate Transparency. Here are some of them:
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.
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.