TLS/SSL Explained – TLS/SSL Certificates, Part 4

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 or In either case however, 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, * is used in the registration which means all,, 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

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). This kind of validation usually takes only a few minutes 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.


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 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).

SSL secure browsing

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

Insecure Browsing

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

SSL Insecure browsing

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.

SSL/TLS delivered via HTTP

connection not secure

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.

Share this post
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.
  • Typo: “Thatwe”, should be Thawte

    And this sentence, in context, doesn’t make sense; it is at least ambiguous: “So does any other subdomain.”

    Thanks for the articles.

    • Hi Justin,

      Thanks for your for comment, it has been corrected.

  • The article says, “When the certificate is ready it will be sent to our email in *.crt format and it must then be installed on the server.” But doesn’t the private key need to be installed at the server?

    • Hi Mark, thanks for your comment.

      Yes of course. In the article it is assumed that the CSR generation is done on the server on which the certificate will be installed. In that case the private key is already on the server.

      The webserver (or any other service) will need to be configured to use both the certificate and the private key (as well as an Intermediate Cert).

  • Hi
    When we use HTTP/TLS, do we need to configure the server or client with a TLS certificate

    • You will need to configure TLS / SSL on the server. You can optionally configure the server to require a client SSL certificate from clients too.

  • HI,
    when I scan my website with acunetix online scanner for vulnerabilties, the report says ssl/tsl certificate is expired.
    But when I checked my ssl certificate is valid and still have two months to expire. I want to solve this vulnerabilty please help me with this issue.

    • Hi Mahesh,

      This could be due to various reasons. To further analyze scan reports, it would be best to get in touch with our support team over at as they would be able to assist you further.

  • Leave a Reply

    Your email address will not be published.