Domain Validation: SSL’s Other Job

SSL certificates are a hot topic today. Website owners are becoming increasingly aware that collecting information on non-HTTPS secured pages is a bad idea and the larger web ecosystem is definitely moving in the direction of full web encryption. This is why we have created a guide for beginners illustrating how to adopt SSL on your site for free.

Google has indicated they’re giving a ranking boost to HTTPS encrypted sites with heavier rankings likely to come in the future. Initiatives like Let’s Encrypt are issuing free SSL certificates to anyone who wants them, and the speed-increasing HTTP/2 (while technically able to operate over HTTP) is being supported by major players such as Google and Mozilla only over TLS to speed up the adoption of encryption.

Most people understand that SSL certificates provide security by allowing the encryption of traffic between a website and a web browser. That’s a critical part of security, but it’s not the only thing SSL certificates do for you.

Arguably, the most important task they perform is done silently in the background, and you have no idea it ever happened.

Before any encryption is established in a web browsing session, the first thing the certificate does is assure your web browser that it’s actually connecting to the website it thinks it is connecting to. This is called authentication and it is a critical part of any security process.

Domain Validation Error

If the domain in your browser bar and the domain in the SSL certificate do not match, you’ll see an error like this (Chrome screenshot):

Confidentiality

Stepping away from the complexities of internet security, it’s useful to understand how we humans exchange confidential information on any level.

If I wanted to tell my wife something personal I would want to ensure two things before I disclosed that information:

• First, I would want to ensure I am talking to my wife and not someone else.
• Once I’ve established that, I would want to make sure that I can’t be overheard.

Going back to Internet security, the process of establishing that I am talking to my wife is the authentication step. Ensuring I am not overheard is the encryption step.

What’s worse?:

• Having a highly encrypted conversation with a bad guy?
• Having an open conversation that anyone can overhear with a good guy?

There’s simply no correct answer to this; complete security requires both.

SSL Authentication

How is authentication achieved? Your browser does this by checking that the website address in your address bar matches the website address in the SSL certificate the server presents.

But why does that matter? I can make a self-signed certificate for any domain I want… so why is that check useful?

It’s useful because the issuer of the SSL certificate is taken into consideration by the browser and it only trusts certificates that have been issued by authorities who do proper ownership validation before issuing a certificate. Therefore, what your browser is really doing is trusting an SSL issuer, not the certificate per se. More on that later.

Ownership Validation

How do SSL issuers perform this ownership validation? When I ask my SSL provider for a certificate for my domain I have to prove that I own that domain, then they’ll tell me how they want me to do it. The most common ways are to either respond to an email challenge to the email address in the domain’s public WHOIS information, or enter some sort of validation file on my website, or make an arbitrary change to my domain’s DNS records. The certificate that will be issued to me after proving I have control of a domain is called a Domain Control Validation level  (DCV) SSL certificate.

It’s important to note that a DCV certificate simply proves that I am in control of a domain, which essentially means I own it (or at least I owned it long enough to pass the DCV test). It is the lowest level of validation and it doesn’t verify whether the activities I am involved with while utilizing that domain are legal or ethical. In fact, it doesn’t tell website visitors anything about the type of activities the website is involved in.

This is not a post about different validation levels, but here’s a five-cent tour:

• There are additional levels of validation called Organizational (OV) and Extended Validation (EV); each level requires the applicant to provide more information about themselves to the issuer.
• An EV certificate requires the SSL issuer to do more than just validate domain control. EV certificates are not available to normal humans, they are only issued to legal entities, such as businesses and organizations.
• Part of the extended validation procedure requires the SSL issuer to verify that the organization requesting the certificate can provide legal proof of their existence, which leverages local governmental laws and other validation steps. If a business is legitimate enough to be issued a government business license then that’s a big step to EV, but generally, there is more validation done than that.
• EV certificates not only prove domain control, they also add more credibility that the website in question is actually tied to some level of legitimate business operation.
• EV certificates contain identity information, such as the business name in the certificate.

Visually, the main difference that website visitors see between the two certificate types is in their browser address bar. A DCV SSL certificate will simply show a padlock in the address bar, whereas an EV certificate can put a green bar with the organization’s name in the address bar as long as there are no other problems with SSL on the site or visitors’ browsers.

A Note on SSL Issuers

Going back to the authority trust issue, astute readers are probably wondering if they can even trust the SSL issuer. If I can’t trust the web server to be honest with me, why should I trust some SSL issuing company I’ve never heard of to vouch for that website via an SSL certificate? The answer lies deep within your browser.

Inside every browser is a list of certificate authorities that the browser trusts. If the SSL certificate presented from a website was issued by one of those authorities, then the browser will trust it. Sometimes there are layers of trust – your browser may not directly trust the issuing authority that actually issued the SSL certificate for the site, but it trusts some other issuing authority that does trust the certificate issuer. It’s the “friend of my friend is my friend” type of thing, and it is achieved through the use of intermediate bundles that establish a chain of trust between the browser and the issuing authority.

So, there you have it. The next time you visit an SSL encrypted site, take a moment to thank your browser for doing all that work you never knew it did under the hood.