TLS Security 4: SSL/TLS Certificates - Security Boulevard

TLS Security 4: SSL/TLS Certificates

When you communicate securely with a third party using data encryption, you usually want to be sure that they are who they say they are. For example, when you use an online bank or an e-commerce site and you send sensitive information, you want to be certain that this is not an impostor website.

For this purpose, the SSL protocol (Secure Sockets Layer) and the TLS protocol (Transport Layer Security) include a security measure called digital certificates. Using this mechanism, a public key can be signed by another party. A certificate also contains identity information pertaining to the owner of the public key.

Certificate Authorities

If you visit the website of a bank and receive a certificate that is signed by another entity, you might still feel uncertain about website security. You may be worried that the entity that signed the certificate is an impostor. This problem is addressed by the Public Key Infrastructure (PKI). The PKI includes everything that is needed to manage digital certificates and public key encryption.

There are several PKI entities that you can trust. They are called Certificate Authorities (CAs). They verify other entities (companies, organizations, individuals) and confirm that they are indeed who they say they are. Upon such verification, a CA signs the certificate using their own certificate. The certificate of a CA is called the root certificate.

The root certificates of all CAs (and therefore their public keys) are considered trusted. They are installed in all browsers such as Chrome, Firefox, and Edge and in operating systems (including Windows). Popular CAs include IdenTrust, Comodo, DigiCert, GoDaddy, GlobalSign, and Symantec. There are currently more than 200 root certificates that are trusted by browsers.

An SSL/TLS web connection requires a TLS/SSL certificate but that certificate can be signed by anyone. It can even be self-signed (signed by the entity that created the certificate). When visiting a website secured with SSL/TLS, the browser checks if that website has a valid certificate by checking if it is signed by a trusted root certificate. It also checks if the certificate is for the domain that you are visiting and displays information about the certificate owner for you to verify. If the certificate is not signed by a trusted root certificate, the web browser displays a clear warning. You can usually choose to ignore the warning (depending on web browser setup) but you cannot miss it.

Secure Browsing

It is very easy to identify if a website has a valid certificate and if you are using a secure connection. All you need to do is to look at the address bar (similar in all major browsers).

SSL secure browsing

The green lock and the HTTPS protocol (https://) indicate that the connection to the web server is encrypted and secure.

Insecure Browsing

It is also easy to identify a non-secured website. There is no green lock and there is no mention of HTTPS.

SSL Insecure browsing

However, some websites use HTTP to deliver parts of the content such as images. In such a case, you will see a message similar to this one:

SSL/TLS delivered via HTTP

connection not secure

Content that is only partly secured is called mixed content. Mixed content defeats the purpose of a secure connection. When you request files from a website where you are logged in, the web browser automatically sends your authentication cookies along with the request.

Therefore, if you load a resource using HTTP, your request is sent over a non-encrypted connection. If an attacker is sniffing the network, they are able to see this request in plaintext. This compromises the security of a session since an attacker uses cookies to log into the website and impersonate you. For this reason, you should treat websites with mixed content the same way that you treat unencrypted websites.

Types of SSL/TLS Certificates

SSL/TLS certificates are available in different flavors. From a technical point of view, they can be divided into three groups depending on the scope of domains that they apply to.


This type of certificate applies to only one hostname (Fully Qualified Domain Name – FQDN) or subdomain. For example, you may get a certificate for or However, will not be included in the scope of this certificate. The certificate will only be valid for one hostname that you specify during registration.


This type of certificate applies to an entire domain with all its subdomains. For example, if you register *, the certificate will apply to,,, and all other subdomains. You can host each subdomain on a different server and use the same wildcard SSL/TLS certificate on multiple servers as long as the domain is the same.


This type of certificate applies to several different domain names. Each domain name may be a single domain or a wildcard. Usually, when you acquire such a certificate, you can change the domain names at any time. This type of certificate is also often called a Subject Alternative Name (SAN) certificate.

SSL/TLS Certificate Validation

SSL/TLS certificates are also available in different flavors from the point of view of identity validation. The more identity validation, the more trustworthy the certificate is but the more time it takes to acquire it.

Domain Validation

A domain validation certificate only confirms that the person who applies for a certificate is the owner of the domain name (or at least has access to it). This kind of validation usually takes only a few minutes up to a few hours.

Organization Validation

The Certification Authority (CA) not only validates domain ownership but also the owner’s identity. This means that an owner might be asked to provide personal information and identification documents that prove their identity. Such validation may take several days.

Extended Validation

This is the highest level of validation. It includes validation of domain ownership and owner identity but it also requires the business to provide proof of legal registration.

Certificate Generation

If you want to apply for a certificate from a Certificate Authority, you need to generate a Certificate Signing Request (CSR). First, create a private key that will be used to decrypt the certificate. Then, generate the CSR. When you generate the CSR, you will be asked to specify the domain name as well as details about you organization, for example, name, country, and email. The following is an example of a CSR.


After you generate the CSR, you must submit it to the CA. When the certificate is ready, the CA usually sends it to your email address as a *.crt file. You must install this file on your server.



Agathoklis Prodromou Web Systems Administrator/Developer

Akis has worked in the IT sphere for more than 13 years, developing his skills from a defensive perspective as a System Administrator and Web Developer but also from an offensive perspective as a penetration tester. He holds various professional certifications related to ethical hacking, digital forensics and incident response.

*** This is a Security Bloggers Network syndicated blog from Web Security Blog – Acunetix authored by Agathoklis Prodromou. Read the original post at: