In this blog post, we’ll explore SSL/TLS encryption and its vital role in securing Internet communication. Discover the validation process for establishing trusted connections and learn about the authentication mechanisms behind SSL/TLS. Let’s dive in together!
What is SSL and TLS?
SSL is technology your applications or browsers may have used to create a secure, encrypted communication channel over any network. However, SSL is an older technology that contains some security flaws. Transport Layer Security (TLS) is the upgraded version of SSL that fixes existing SSL vulnerabilities. TLS authenticates more efficiently and continues to support Both operates at the transport layer 4.
What is the difference between SSL certificates and TLS certificates?
At present, all SSL certificates are no longer in use. TLS certificates are the industry standard. However, the industry continues to use the term SSL to refer to TLS certificates.
TLS certificates have iterated upon SSL certificates and improved them over time. The final function of SSL certificates and TLS certificates hasn’t changed.
However, it’s important to note that TLS 1.0 and TLS 1.1 were also formally deprecated in 2021.
What is a TLS certificate?
A TLS certificate is a file installed on a website’s origin server. It’s simply a data file containing the public key and the identity of the website owner, a signature from a Trusted CA along with other information. Without a TLS certificate, a website’s traffic can’t be encrypted with TLS.
Technically, any website owner can create their own TLS certificate, and such certificates are called self-signed certificates. However, browsers do not consider self-signed certificates to be as trustworthy as TLS certificates issued by a certificate authority.
What is Certificate Authority?
A Certificate Authority (CA) is a trusted entity that issues digital certificates used in public key infrastructure (PKI). It plays a crucial role in establishing the trustworthiness of online communication and verifying the authenticity of digital entities, such as websites, servers, or individuals.
The primary function of a Certificate Authority is to validate and issue digital certificates. These certificates contain information about the entity they identify, including its public key and other identifying details. When a client (such as a web browser) connects to a secure website, the website presents its digital certificate, which is verified by the client’s trust in the issuing CA.
Who are certificate authorities?
- DigiCert
- Sectigo
- GoDaddy
- GlobalSign
- Entrust
- Trustwave
- Network Solutions
- Letencypt (Free)
So let’s say a certificate issued by the CA DigiCert is more likely to be trusted by a certificate issued by randomCA.
How does a CA issues A Certificate?
Let’s say we are issuing an SSL certificate for the domain example.com pointed to the server 192.168.1.1.
I am using Certbot client. When you use Certbot to obtain or renew an SSL/TLS certificate from Let’s Encrypt, it automatically handles the ACME challenge process on your behalf. Certbot communicates with the Let’s Encrypt ACME server to generate the necessary challenges and fulfill them.
What is the ACME challenge?
When a certificate authority (CA) issues an SSL/TLS certificate, it needs to ensure that the entity requesting the certificate actually owns or controls the domain for which the certificate is being issued. The ACME challenge is a way to verify this ownership or control.
During the certificate issuance or renewal process, the CA generates a unique challenge, typically in the form of a random token or cryptographic value. This challenge is then communicated to the entity requesting the certificate. The entity, often the server administrator, needs to prove its control over the domain by satisfying the challenge.
The ACME challenge typically involves placing a specific file or record at a predetermined location within the domain’s web server. The CA then performs an HTTP or DNS request to that location, expecting to find the challenge value. If the challenge is successfully fulfilled and the CA can confirm the presence of the expected value, it verifies that the entity requesting the certificate has control over the domain.
What is happening behind the scenes?
- Certificate Request: Certbot generates a Certificate Signing Request (CSR) that includes the necessary information for the certificate issuance. The CSR contains details like the domain name (example.com), the IP address (192.168.1.1), and the public key associated with the private key on the server.
- Domain Validation: Certbot will attempt to validate your ownership or control of the domain example.com via ACME challenge. It may use various methods such as DNS verification or website verification to confirm that you have administrative access to the domain.
- Communication with Let’s Encrypt: Certbot communicates with the Let’s Encrypt certificate authority to submit the CSR and request a certificate for the domain example.com. This involves establishing a secure connection and transmitting the necessary information to Let’s Encrypt.
- Certificate Issuance: Let’s Encrypt verifies the information in the CSR and, if everything checks out, issues a signed SSL certificate for the domain example.com.
- Certificate Installation: Certbot automatically retrieves the issued certificate from Let’s Encrypt and installs it on the server where the domain example.com is hosted. It updates the server’s configuration files to include the newly installed certificate.
What is the difference between Sectigo and Let’s Encrypt?
The main differences between Sectigo and Let’s Encrypt are their business models target audiences, validation methods, and certificate lifetimes:
Sectigo is a commercial Certificate Authority that offers a wide range of SSL/TLS certificates, including extended validation (EV) certificates, organization validation (OV) certificates, and domain validation (DV) certificates. Sectigo operates as a for-profit entity, providing paid certificate solutions with various features and options.
On the other hand, Let’s Encrypt is a nonprofit Certificate Authority that focuses on providing free SSL/TLS certificates through automation. Let’s Encrypt aims to make HTTPS encryption accessible to all website owners by removing financial barriers and simplifying the certificate issuance process.
TLS Validation process explained.
Certbot is a software client which automates the SSL creation process.
Let’s assume we are issuing an SSL certificate for the domain example.com pointed to the server 192.168.1.1 Server via Certbot client.
Example.com.
Certbot client installed in the server
Domain Validation (DNS, HTTP).
Certbot generates a CSR with the help of a Certbot client.
CSR contains the details of the domain and public key –Pvt key kept in the server. itself.
Request a certificate for the domain from CA.
Lets-encrypt verified the CSR and issues a TLS certificate for the domain.
Signing it with Let’s Encrypt’s intermediate certificate.
Let’s Encrypt generates the TLS certificate for example.com, signing it with Let’s Encrypt’s intermediate certificate.
Certbot automatically downloads the certificate from CA(let-encrypt).
Certbot automatically updates the webserver confs.
Steps:
- Domain Validation: Certbot will attempt to validate your ownership or control of the domain example.com. It may use various methods such as DNS verification or website verification to confirm that you have administrative access to the domain.
- Certificate Request: Certbot generates a Certificate Signing Request (CSR) that includes the necessary information for the certificate issuance. The CSR contains details like the domain name (example.com), the IP address (192.168.1.1), and the public key associated with the private key on the server.
- Communication with Let’s Encrypt: Certbot communicates with the Let’s Encrypt certificate authority to submit the CSR and request a certificate for the domain example.com. This involves establishing a secure connection and transmitting the necessary information to Let’s Encrypt.
- Certificate Issuance: Let’s Encrypt verifies the information in the CSR and, if everything checks out, issues a signed TLS certificate for the domain example.com.
- Certificate Installation: Certbot automatically retrieves the issued certificate from Let’s Encrypt and installs it on the server where the domain example.com is hosted. It updates the server’s configuration files to include the newly installed certificate.
- Server Configuration: Certbot modifies the server configuration (e.g., Apache or Nginx) to enable SSL/TLS and configure the domain example.com to use the issued certificate. This includes setting up appropriate virtual hosts, configuring SSL directives, and linking the certificate files.
What are Domain Validation, Extended Validation and Organisation Validation?
Domain validation:
This is the method which we have seen by the let’s encrypt to provide the SSL certificate of example.com by checking the validation process involves demonstrating control over the domain, typically through DNS verification or file-based verification.
It includes adding a cname record to the domain DNS or adding a txt file to the domain .well-known directory.
Let’s Encrypt focuses on automating the certificate issuance process, making it simple and efficient.
Extended Validation and organisation validations?
EV certificates provide the highest level of trust with a prominent green address bar, indicating rigorous validation of the organization’s legal identity. OV certificates offer a middle ground with organization verification but do not trigger the green address bar. Both EV and OV certificates enhance the trustworthiness and authentication of websites compared to DV certificates.
What are certificate chains?
A certificate chain is a list of certificates (usually starting with an end-entity certificate) followed by one or more CA certificates (usually the last one being a self-signed certificate), with the following properties:
- Root Certificate. A root certificate is a digital certificate that belongs to the issuing Certificate Authority. It comes pre-downloaded in most browsers and is stored in what is called a “trust store.” The root certificates are closely guarded by CAs.
- Intermediate Certificate. Intermediate certificates branch off root certificates like branches of trees. They act as middlemen between the protected root certificates and the server certificates issued to the public. There will always be at least one intermediate certificate in a chain, but there can be more than one.
- Server Certificate. The server certificate is the one issued to the specific domain the user is needing coverage for.
In the case of DigiCert, the DigiCert Global Root G2 certificate would be the root certificate, the DigiCert EV RSA Certificate Authority certificate (also known as DigiCert EV Rsa) would be an intermediate certificate and www.digicert.com is the server certificate
SSL AUTHENTICATION.
Let’s explain the working of SSL trust and authentication mechanisms via a simple story.
In this story, we can consider the player as the certificate of the domain ie the certificate of example.com.The caption as the intermediate certificate and the coach as the root certificate.
The browsers are considered as the tournament where the new player is trying to enter.
The coach has a direct connection with the Tournament coordinators.
Tournament coordinates already have a certificate trusted by the coach. Hence player is allowed with that certificate is allowed to access the tournament.
Now, when you visit a secure website (e.g., https://example.com), here’s how the team works together:
- The website’s server presents its end-entity certificate (player) to your web browser.
(Tournament) - Your web browser checks the end-entity certificate’s signature and says, “Okay, I see you have a certificate signed by the intermediate certificate (captain). Let me check if I trust the captain.”
- Your web browser then looks at the intermediate certificate and says, “Alright, I trust this intermediate certificate because it is signed by the root certificate (coach). Now let me check if I trust the coach.”
- Your web browser(Tournament) checks its list of trusted root certificates and sees if the root certificate (coach) is in there. If it finds a match, it says, “Great! I trust the coach, and since the intermediate certificate is also trusted, I can trust the end-entity certificate presented by the website/server.”
- If the entire certificate chain is trusted, your web browser establishes a secure connection with the website/server. Hence player (example.com) is secured.
Summary:
In this lecture, We learned about the SSL/TLS encryption validation and authentication mechanism.
