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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
*** This is a Security Bloggers Network syndicated blog from Web Security Blog – Acunetix authored by Agathoklis Prodromou. Read the original post at: http://feedproxy.google.com/~r/acunetixwebapplicationsecurityblog/~3/Ez1_8C26GxA/