This is the first part of a series of articles about SSL/TLS certificates. SSL/TLS certificates are certificates that facilitate secure communication over the Internet. We use it to encrypt data between a user’s web browser and our webserver. If a website uses SSL/TLS certificate it basically means it uses HTTPS, which is a secure version of HTTP. However, it doesn’t mean you are safe from hackers.
In this one, we will cover the basics of
- what are the most popular types of certificates,
- what is the level of security for each one,
- what certificates are most often used by hackers,
- when we should use which one,
- how the process of generating and implementing certificates looks like based on Nginx webserver.
Do we always have to use SSL/TLS certificates?
Of course, it’s highly recommended to use SSL/TLS certificates, but still, you don’t always have to use it. We use it to ensure that sensitive information, such as login credentials or credit card details, remains private so nobody can sniff it. BUT if you have eg. a simple static website with no user interactions or sensitive information, and you don’t have concerns about user trust or data security, you can skip it. But why would you?
Here are some advantages of having a certificate installed:
- Increased performance — SSL can improve page load times
- Higher rank in search engines — search engines favor HTTPS websites
- Hiding sensitive data — SSL ensures that the connection between user and webserver is encrypted, so nobody can sniff important data
How signs of SSL/TLS certificates evolved
Green address bar & Organization name
The green bar & organization name was always a sign that we were on a website that had EV, which gave us some level of trust. However, in Google Chrome, the green bar actually was removed in September 2018 with the release of Chrome 69 and since the fall of 2019, the company information has been removed as well.
Here is a link to the official information regarding changes in EV certificate indicators: https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/ev-to-page-info.md
Padlock icon
The padlock is the next sign that represents a level of security between a web browser and the website you are visiting. By clicking on the padlock icon in the URL bar you can see that the connection is secure and encrypted. Chrome decided to remove it and implement a new icon that is described below as a tune icon.
Tune icon
In September 2023 with the release of Chrome 117, Google implemented a new feature instead of a padlock icon which is a tune icon. Here is why:
Replacing the lock icon with a neutral indicator prevents the misunderstanding that the lock icon is associated with the trustworthiness of a page, and emphasizes that security should be the default state in Chrome. Our research has also shown that many users never understood that clicking the lock icon showed important information and controls. We think the new icon helps make permission controls and additional security information more accessible, while avoiding the misunderstandings that plague the lock icon.
Read the whole article about the tune icon here -> https://blog.chromium.org/2023/05/an-update-on-lock-icon.html
The most common types of SSL/TLS certificates
There are several types of SSL/TLS certificates, each designed for different use cases and security requirements:
Extended Validation (EV) Certificate
EV certificate gives us the highest level of security and identity validation. It should be the first choice for all websites that require any sensitive information like banking, e-commerce, and government platforms for example.
Verification process
This verification process is much more strict than in other certifications. The CA checks the legal existence of the organization similarly to OV, but also organizational existence, which means checking if a company is actively running a business.
They verify physical location, address, phone number (they will call you to make sure that you are a part of the company), legal and financial documents, and law and regulations compliance.
EV certificates must comply with the CA/Browser Forum’s Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, which is a guideline with standards for EV certificate issuance and validation.
Here you can check mentioned guidelines: https://cabforum.org/baseline-requirements-documents/
From my personal experience, the verification process may take around 2 weeks, so it’s a quite long period compared to other certificates. It’s also the most expensive one.
Level of security
HIGH
After providing so strict analysis of the company, CA finally issued an EV certificate to the organization. It gives the highest level of security and to make sure that it’s an EV certificate, click on a padlock or tune icon.
In this example, by clicking on the padlock icon in the URL bar you can see that the connection is secure and encrypted.
When clicking on ‘Connection is secure’ and then on ‘Certificate is valid’, you can see certificate details. In the example below, you can see details about EV certificate installed on the website of the Polish bank PKO BP.
This is the way that you can check if the browser is using other certifications as well, so always take a look into this to be sure.
Organization Validated (OV) Certificate
This one is suitable for websites where a higher level of trust is important, but still, they don’t want to spend too much money on this.
Verification process
This verification is typically to check the legal existence of the organization but not the real company address or other extensive verification.
Level of security
MEDIUM
OV is lower in security rank than EVcerts, but still higher than DV certs which I will cover later. A padlock icon on a website next to the address bar adds a level of trust because it means that the connection is secure and encrypted.
Standards of validation may differ and depend on the CA. They may be used by hackers, but not as commonly as DV, because it’s more expensive and time-consuming to obtain.
Domain Validated (DV) Certificate
This one is a good choice for personal websites like blogs. It is quick and simple to get because the Certificate Authorities only verify if you are the owner of the domain for which you generated the certificate.
Verification process
This verification is typically done through email verification or DNS record changes. Usually, they ask you to add a specific TXT record to make sure that you are in control of the DNS for this domain. They are checking domain ownership records in a public WHOIS database or through email verification sent to an email address associated with the domain.
Level of security
LOW
DV certificates do not provide any information about the legitimacy of the business or entity operating the website, so it may be anyone eg. some hacker that bought a domain name and wants to make his malicious/phishing website look more trustworthy.
The padlock icon adds a level of trust, but as you already know it only assures us that the connection is secure and encrypted. However, we don’t know who’s exactly the real owner of webserver. If we deal with some hacker website, then when sensitive information was logged or temporarily stored on the webserver while in transit, before encryption, the hacker has access to this.
Wildcard Certificate
This certificate will not only secure a domain but also all its subdomains with a single certificate. It’s issued for *.example.com instead of example.com.
It’s a good choice for companies or organizations with numerous subdomains under the same parent domain.
Verification process
Wildcard certificates are usually issued after the CA verifies control over the primary domain. They ensure that the entity applying for the certificate has control over the entire domain and all its subdomains.
The verification of subdomains can be done by email to check if you are part of the organization, by DNS record to check if you have control over every subdomain, or by HTTP file authentication to check if you have access to the webserver as it requires you to upload a file there and CA checks it via HTTP request send to your subdomains.
Level of security
MEDIUM
Wildcards come with some potential risks:
- Wide attack surface — when the private key associated with the certificate is compromised, an attacker can potentially impersonate not just one subdomain but all subdomains covered by the certificate, because it’s only one cert to protect the primary domain with all subdomains included.
- Harder to control — certificate may be used by various teams within an organization, so it can lead to problems with managing who has access to the certificate’s private key.
- Subdomain Takeover — hackers can use wildcard certificates to create phishing websites that mimic legitimate subdomains. They can also take over subdomains if they can gain control over DNS settings.
SAN Certificate
SAN is a shortcut for Subject Alternative Name and it’s also called Multi-Domain Certificate. It’s used by companies that host multiple domains or subdomains on a single server or use multiple domain names for different services.
You may ask what’s exactly the difference between SAN and wildcard certs?
SAN secures multiple domains and subdomains within a single certificate when wildcard secures one, primary domain and all its subdomains.
Also, SAN certificates provide granular control over the specific domains and subdomains included in the certificate, because you can specify which domains to include in the certificate. In wildcard, you can’t exclude subdomains.
Verification process
The verification process for SAN certificates primarily focuses on domain validation, so CA checks domain ownership records in the WHOIS database, validates control via DNS records, or sends us verification emails.
A SAN certificate can include eg. an OV or EV component if we opt for a higher level of validation. In that case, the CA performs additional verification processes typical for these certificates.
Level of security
IT DEPENDS
The level of security depends on the validation type associated with the certificate. You can mix different domain validation levels (DV, OV, or EV) in a single SAN certificate.
Self-Signed Certificate
This certificate is not recommended for Internet-facing websites. It’s typically used in testing and development environments and other scenarios where trust is not such an important concern.
Verification process
It’s not verified by CA. This process is minimal as it involves generating the certificate and key pair.
The level of security
Self-signed certificates are generated and signed by the entity that owns or controls the web server. They are not issued or validated by a CA, so these certificates are not trusted by web browsers. Because of this, you will see a warning message informing you that this certificate is self-signed, so it’s not trusted and you will have to manually accept it to proceed.
There is no assurance regarding the authenticity of the website, so it may be vulnerable to man-in-the-middle attacks.
How to generate SSL/TLS certificate?
To generate a certificate we use the OpenSSL tool.
Generate a private key
The first step is to generate a private key. A good practice is to add a domain name to the name of a file with a private key to not be confused when you have a large number of domains to manage.
openssl genpkey -algorithm RSA -out example_com.key -aes256- -out example_com.key — defining in what file we want to save the private key
- -algorithm RSA — defining what kind of cryptographic algorithm is used
- -aes256 — defining the encryption algorithm and key size used to protect the private key. We use AES with a key size of 256 bits. It will provide an additional layer of security for the private key by encrypting it with a passphrase. When you generate the private key, you’ll be prompted to set a passphrase and it will be used to encrypt and decrypt the private key. Keep this passphrase in some Key Management Tools like eg. Hashicorp Vault.
Certificate Signing Request
Use openssl req command to create a CSR and send it to Certificate Authority.
openssl req -new -key example_com.key -out example_com.csrCA or Self-Signed Certificate?
Now, you have to know what type of certificate you need.
- If CA certificate like eg. EV then send a CSR to them. You can choose Let’s Encrypt, DigiCert or other trusted CA.
2. If Self-Signed certificate then run this command:
openssl x509 -req -in example_com.csr -signkey example_com.key -out example_com.crt- -req — indicates a CSR (Certificate Signing Request)
- -in example_com.csr — defines the input file, which is the CSR file you want to use to generate the certificate.
- -signkey example_com.key — defines the private key used to sign the certificate and it’s the same key we generated before. When creating a self-signed certificate, the entity signing the certificate is also the entity requesting it, and it uses its own private key to sign the certificate.
- -out example_com.csr — defines the output file where the generated X.509 certificate will be saved.
Install a certificate on a webserver
I will use Nginx as an example, but it’s quite similar to others like Apache.
Add a certificate and a key on the webserver under the path /etc/certs/.
Your Nginx website configuration should be available under the path /etc/nginx/sites-available/example_com.
Add a certificate and a key on the webserver under the path /etc/certs/.
server {
listen 80;
server_name example.com www.example.com;
# Redirect HTTP to HTTPS
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
server_name example.com www.example.com;
# SSL/TLS configuration
ssl_certificate /etc/certs/example_com.crt;
ssl_certificate_key /etc/certs/example_com.key;
# SSL Configuration
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers 'ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:AES256+EECDH:AES256+EDH';
# Enable HSTS
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
...
}It’s good to add some additional stuff to protect your webserver like allowing only TLSv1.2 and v1.3 or only v1.3 if possible, allowing secure ciphers and enabling HSTS header which will make it impossible to access your webserver using HTTP. It’s basically forcing the use of HTTPS.
Check Mozilla generator for secure webservers configuration: https://ssl-config.mozilla.org/
Summary
In this article I focused on explaining why we need certificates, what are the most common types and what the process of generating and implementing certificates on a webserver based on Nginx looks like.
This is the first part of a series of articles about SSL/TLS certificates. In the next articles, we will learn more about Let’s Encrypt which gives us a free certificate, potential attack surfaces and popular attacks related to SSL/TLS certificates, and how actually certificates work under the hood including SSL handshake, so stay tuned.
