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.

Single-Domain

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

Wildcard

This type of certificate applies to an entire domain with all its subdomains. For example, if you register *.example.com, the certificate will apply to mail.example.com, secret.example.com, admin.example.com, 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.

Multi-Domain

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.

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

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.

CSR

 


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

  • @Mark Normally people generate private key along with CSR

  • 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 support@acunetix.com as they would be able to assist you further.

  • Leave a Reply

    Your email address will not be published.