TLS/SSL Explained: TLS/SSL Certificates, Part 3

In parts 1 and 2 of this series, we looked at What is TLS/SSL? and TLS/SSL terminology and basics. In this, the third part in the series, we will be describing TLS/SSL certificates and their use.

As we have already seen, a secure connection can be used to encrypt data and protect our data from being exposed to third parties.

In order for the encryption to occur, the server needs a TLS/SSL certificate to be used. A TLS/SSL certificate essentially binds an identity to a pair of keys which are then used by the server to encrypt as well as sign the data.

Certificate Authority (CA)

A Certificate Authority is an entity which issues TLS/SSL or Digital certificates. These authorities have their own certificate for which they use their private key to sign the issued TLS/SSL or Digital Certificate. This certificate is known as the Root Certificate.

The CA’s Root Certificate, and therefore, public key, is installed and trusted by default in browsers such as Chrome, Firefox, and Edge. This is necessary to validate that the certificate of a website visited was signed by the CA’s private key. Popular CA authorities include Comodo, GlobalSign, DigiCert, GeoTrust, Thawte, and Symantec.

Types of TLS/SSL Certificates

TLS/SSL Certificates are available in different types, grouped by either Validation Level or Domain setup.

Single-Domain

This type of certificate is used to secure only one hostname (or Fully Qualified Domain Name FQDN) or subdomain. For example, you may get a certificate for www.example.com or my.example.com. In either case, however, mail.example.com will not be secured. Nor will any other subdomain. The certificate will only be valid for the hostname you specify during the registration.

Wildcard

This type of certificate is used to secure an entire domain with all its subdomains. For example, *.example.com is used in the registration which means all mail.example.com, secret.example.com, admin.example.com will be secured (as well as any other subdomain). Keep in mind that each domain could be pointed to a different server. The same certificate can be used on multiple servers as long as the domain is the same.

Multi-Domain

This type of certificate is used to secure several different domain names.

TLS/SSL Certificate Validation

Domain Validation

It will only validate that the person who applies for a certificate is the owner of the domain name (or at least has some sort of access to do so). This kind of validation usually takes only a few minutes, but can take up to a few hours.

Organization Validation

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

Extended Validation (EV)

This is the highest level of validation and it includes validation of domain ownership, owner identity, as well as a business’s legal registration proof.

Certificate Generation

For a Certificate Authority to issue a certificate, it first needs to have our server’s CSR, which stands for Certificate Signing Request. We first create a private key which will be used to decrypt our certificate and then we generate a CSR.

While generating the CSR, we will be asked to specify the domain name as well as details about our organization like name, country, and email. The following example shows a CSR:

-----BEGIN CERTIFICATE REQUEST-----
MIICtzCCAZ8CAQAwUTELMAkGA1UEBhMCQ1kxCjAIBgNVBAgMAWExCzAJBgNVBAcM
Ak1lMQowCAYDVQQKDAFhMQowCAYDVQQLDAFhMREwDwYDVQQDDAh0ZXN0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKvFkdX1qwMNu0i0GHW/lotRKYM0I3yvHQmeS5DtYqmnMGsIZaUO7qv+z8CW4cIIqZhR/hlXEsh+ARM/po37OjzzSDo1U7gyKciSf2s+JsuLmlrHoZPto+/4uWgp9xyQW177/MvWtOVejaUnzrjmPnE0
AT9KAZ3w+2uwjrhJG5w52psENUT+tTOMlDgIVlKSbZcvD5bS/X7RvfsOS3Q/y9wG
Q53rbZqK19y5CtM808wGOQhrNfp3M1EA6+m7RRO1Yw2Rp+wLY0aA9UzjzImaL5Sr
/job1EoJWzKClY20GXB6HKn+wJ/n4sz725bF6l6r4yoBY1f4gYBn3QW+sQXLrDsC
AwEAAaAhMB8GCSqGSIb3DQEJBzESDBBkZmpoZ2tqaGpoZGZramhnMA0GCSqGSIb3
DQEBCwUAA4IBAQCFQ7/R+/ioSj7X4gs+GBbDHEcnJHshwoX9vVBDYvOoQ56iER7f
cEtja18yeXu3PNyeOoDLSYd0FhM16XKLlJ0llIy46Vb8RMdS4JNEx2yob3W/bIAS
z2n+p58zp2/Gp7gG2LtH+RwcvRGRGdKhrsU8D+fHGHpSGvGJg++IhS2HZvTs5pkD
3AwMpDojVYtWuJteDVHGc4PH5TeJot7+6lGetkhq1uRhD4KjJDY5KUvCNQIjeoaL
eFf/xGp6JGNE5taK2liBs+QlgLZc8Sm7fTYCi0YXAsEhMm9HjbXX28Ou6zTroDP3
elT3tN9pd1aG6ujGjkrM6T8JiVWxqYFEnFqd
-----END CERTIFICATE REQUEST-----

The CSR is then submitted to the CA in order to create our certificate. When the certificate is ready, it will be sent to our email in *.crt format and it must then be installed on the server.

Secure Browsing

Identifying whether a website has a valid certificate and that you are on a secure connection is very easy. All you have to do is look at the status of the URL bar on the top left of our screen (it is similar across all major browsers).

The green lock with the https:// protocol indicates that the connection to the web server is encrypted and secure.

Insecure Browsing

Identifying a non-secure website is just as easy. There is no green lock and there is no mention of HTTPS.

However, identifying an insecure website which is using HTTPS can be tricky if you are a non-experienced user. The reason is that even though the website is using an SSL/TLS certificate and HTTPS is being used, some parts of the content are delivered via HTTP.

In that case, depending on the browser we will see either of the following:

This is what we refer to as Mixed Content. Mixed content vulnerabilities defeat the purpose of a secure connection, especially since when requesting files from a website to which we are logged in, the browser will automatically send our authentication cookies along the request.

Therefore, if a resource, such as an image, is loaded using HTTP, our request is sent over HTTP which is un-encrypted; meaning that an attacker sniffing the network will be able to see this request in plaintext. This compromises the security of a “secure” session since an attacker can now use the cookie to login to the website and impersonate a victim.