Updated july second ’19. Linked to Mozilla cipher configurator and removed the HPKP part which is hardly used today.
SSL is becoming the standard for communication on the web, that’s a fact. Apple is even requiring encrypted connections within apps on iOS10. While this marks a milestone, there’s also still a lot of confusion around SSL. It’s not quite that hard! In this article I’ll talk about different validation types, differences between security and how to up your security.
Only the ownership of the domain is checked, for example by sending an e-mail to email@example.com.
The ownership of the domain is checked, your company is checked against public registers and the WHOIS data is checked and should match your company registration.
EV-certificates are best known for the green bar in most browsers. For an EV-certificate all the checks for an OV certificate are performed. Also, you have to sign a legal agreement (Subscriber Agreement) , phone verification is performed and depending on the CA some additional checks are done.
What is important to note in the definition list above is that all of the differences are in the ‘Validation’-part, technically every type of certificate is equally secure. But it’s important to divide the meaning of the certificate being ‘secure’ in to two seperate parts, with ‘secure’ people might think of the assurance that the website where they are purchasing something is actually the same as they think it is and some people might think of security as the technical security, meaning that the connection between the user and the website is technically secure. Also there’s a third group that has never even noticed there’s a padlock showing up in their browser, no offense.
The difference between different types of certificates is mostly in the way they are validated. A simple DV-certificate does not prove the domain is owned by the company it claims to be, take Apple for example. If someone were to register theofficialapplerepairstore.com, he might be able to purchase a DV-certificate for it, with that certificate the green padlock would show up and one might believe it was an actual Apple website. But this certificate does not prove that, and neither is it meant to prove that.
What a DV-certificate can actually do is enabling a webserver to prove to it’s clients that he is actually allowed to host the website for that domain name. Because only the owner can verify it is his domain name only he will be able to get a DV-certificate issued.
As the name of this certificate implies it’s able to make the connection between a physical/reallife company and an online domain. The additional checks that are performed include the following.
The CA checks if the company wanting to have a certificate issued actually exists, for example by checking the Chamber of Commerce (In the Netherlands) or the D&B database.
The CA checks if the WHOIS data for the domain is the same as the details the company is officially registered with.
Some CA’s also call the publicly registered phone-number for the company and ask a company official to state the certificate was intentionally ordered.
The above are additional checks performed, of course also the domain ownership is checked.
Freave’s green bar EV-certificates give website users the highest form of assurance, in most browsers the adressbar turns green and displays the company name.
The checks performed for an EV-certificate are in fact not much more rigorous than those for an OV-certificate, however, CA’s are more strict when issuing an EV-certificate, example below. And some CA’s require the company to sign a legal agreement with the CA. Furthermore for EV-certificates it’s not possible to have a wildcard issued. This is so the CA can verify each and every domain that a certificate is issued for.
So now we know exactly how SSL-certificates are validated, logically the certificate with the most thorough validation is also the most expensive (which is an EV-certificate). Does this mean that you’ll need EV to secure your website? Simple answer; for the technical security of a website it does not matter which kind of certificate one purchases.
For the technical security of a website it does not matter which kind of certificate one purchases.
Let’s clarify the statement above. Because the technical security is dependent on the webserver the certificate is installed on we could very well state that a website with an EV-certificate could potentially be less secure then a website which uses a DV-certificate. Like I said, it depends on the way the web server is configurated, so what could one do to make his website safer?
Use strong cipher suites
When a browser connects to a website (over HTTPS) an SSL-handshake is performed, this concists of some back-and-forth ‘talking’ between browser and client. At one point of this handshake the webserver presents the cipher suite of his choice, the webserver can be configured to only use secure cipher suites. The client presents which cipher suites it can handle and the webserver chooses the most secure one from the list is has. That does indeed mean that older webbrowsers which might not support newer ciphers could be locked out from a website. (Which I think is not a bad thing since it’s safe to say the connection would just be insecure).
As a web server administrator it’s therefore very important to configure the webserver like so that it will only setup a connection when the client supports strong cipher suites. So, maybe you’re just starting out as an administrator or just host a basic blog and at this point you’re like Cipher suites? What? How do I configure this?, well, not to worry! Mozilla has created an awesome tool that can generate a configuration file with the proper ciphers. You can even decide which browser versions you’d like to support.
Before you read any further, open up your terminal and stand ready to implement it. So, what is HSTS? It stands for HTTP Strict Transport Security and is just like HPKP a configuration we send to the browser using HTTP headers.
HSTS however tells the browser to from the moment it receives the header only fetch the website over a secured connection. The main paramater of this configuration is the max-age and tells the browser for how long to remeber the setting. After browsers start receiving this header, there’s no way back, so when you enable this make sure you’ll be able to serve your website over HTTPS for the coming time.
Implement HSTS on your webserver by adding the following header to your configuration.
If you’d wanted you could also include includeSubDomains so webbrowsers will also only try to connect to your subdomains using HTTPS, I wouldn’t recommend this however because you never now if the services you’ll be using in the future support HTTPS (I know, they should).