In part 1, 2 and 3 of this series we looked at What is TLS/SSL?, took a brief look at the History of TLS and SSL and looked at TLS/SSL terminology and basics. In this fourth 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 an 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.
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. The certificate will only be valid for the hostname you specify during the registration.
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.
This type of certificate is used to secure several different domain names.
TLS/SSL Certificate 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). This kind of validation usually takes only a few minutes up to a few hours.
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.
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.
Identifying whether a website has a valid certificate and that you we on a secure connection is very easy. All we have to do is look at the status of URL bar on the top left of our screen (it is similar across all major browsers).
The green lock with the https:// protocol indicate that the connection to the web server is encrypted and secure.
Identifying a non-secure website is 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 we are a non-experienced user. The reason is that even though the website is using a 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 is 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.