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).
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.
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:
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.
Frequently asked questions
A certificate is a feature of the TLS protocol that lets you make sure that the resource that you are accessing is real. For example, when you access an HTTPS website your browser checks for the certificate that is served by the web server. If the certificate is not valid (for example, the website is fake), it raises an alarm and will not let you enter that website.
Certificate authorities are companies that 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 its own certificate. Your browser will automatically recognize such a certificate as a valid one. This prevents many security problems including some types of man-in-the-middle attacks like IDN homograph attacks.
If there were no TLS certificates, attackers could easily create fake websites and users would have no way to differentiate them from real ones. For example, if someone made a successful DNS cache poisoning attack on your domain, they could create a website with your domain name that would be automatically accessed by many browsers. The users of those browsers would have no way to know that this is a fake website because the URL would be correct.
To get a certificate, you must purchase it from an official company that is authorized to create such certificates. This way, the certificate will be recognized by all browsers. For your internal test sites, you can generate a TLS certificate yourself, creating a local certificate authority.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
Web Systems Administrator/Developer
