Blog

This is my blog page

State of SSL Certificate Affairs

I’ve never posted publicly about my (and hence the company’s) position on SSL certificates and why we don’t charge for them. I’m hoping this post can serve as a reference not just for our customers, but for anyone who’s looking to build a website and gets confused over parts of the technology involved. This is not really a post meant to describe the technology of SSL in-depth. I focus on some basic how’s and why’s, as well as describe some of the current shady industry practices, and how things are changing for the better.

The motivation to write this post came from a potential client. He expressed confusion over how to handle SSL certificates on his site and whether he should have them. Also, because I’ve been receiving unwanted phone and email harassment from Symantec’s RapidSSL team.

Background of SSL/TLS

SSL (more properly called TLS, but we’ll refer to it as SSL as it’s what people know) is a standard that’s used to secure and authenticate the connection between a server (where the website lives) and your computer (where you view the site on a web browser). Broadly, it’s doing three major tasks:

  1. Making sure information can’t be sniffed by an attacker (protects credit card numbers and login passwords)
  2. Making sure the site can’t be modified in transit by an attacker (could be as simple as ad injection, as complex as a phishing form)
  3. Authenticating the website as legitimate by a third party Certificate Authority (we’ll get into this)

These protections are all good things, necessary for most ecommerce sites, and beneficial for all sites. There used to be arguments against deploying SSL due to the added complexity as well as concerns over performance. This just isn’t the case anymore. In many cases it actually improves performance.

Role of the Certificate Authorities (CA’s)

If you recall in point 3 above, SSL actually verifies the owner of the website. This is so that, in theory, a server can’t be taken over by a different owner and continue to serve pages without a big warning appearing in your browser. While it is possible to generate and issue your own SSL certificates without a CA, it will throw up similar large untrusted website errors. These errors happen because to cover all three tasks a certificate must be ‘signed’ by a trusted figure, the CA. A self-issued certificate only covers tasks 1 and 2.

But what is a Certificate Authority?

A CA is usually a large ‘security’ company that is supposed to go through a process of manually verifying the documentation of a company or individual requesting a SSL certificate. Examples of CA’s include Comodo, Symantec, and Verisign. Documentation usually includes simple things like email verification, name, and/or address. For some of the Extended Validation certificates, more advanced documentation like a business registration or drivers license copy is required. These companies all charge varying amounts and will continually try to upsell more expensive certificates. It’s also typical that domain registrars will attempt to resell SSL certificates with domain renewal.

In my experience, they can also be a pain to deal with and often they take forever to actually issue the certificates. In the case of Symantec StartSSL, I had a client from before I started Uber Motif that bought a certificate from them 5 years ago, shut down that site last year, and let the certificate lapse. StartSSL had been emailing me and calling me nearly daily to renew with them, even after I explained the site was defunct and I did not wish to receive their emails and calls about it. No response from their email teams. Eventually they gave up.

How did they get this power to verify sites?

In short, browsers and operating systems arbitrarily gave it to them. Browsers and operating systems trust the CA signing root and intermediary certificates. Browser developers (Microsoft, Mozilla, Google, Opera, Apple) all agreed to trust a list of CA’s from around the world and they constantly make decisions to add and remove ones from the list. Once a CA is granted this trust unfortunately they can (and do) ignore good security practices and are rarely removed from the lists. Symantec has repeatedly extended the deadline on weakly signed SSL certificates then were given a pass by Mozilla because so many sites use them. Comodo has screwed up so bad in the past that they actually allowed attackers to register fraudulent certificates for Google, Yahoo, and Skype. That’s not even all the major cases I can mention, that would take an entire other post.

How are things changing

Free CA’s now exist that issue certificates with full security that all major browsers trust. Let’s Encrypt (http://letsencrypt.org) is what we use to issue our certificates. Let’s Encrypt is a nonprofit consortium that worked to solve one of the largest headaches of getting SSL certificates: they automated issuance and renewal. We’re now able to deploy new SSL certificates in a matter of minutes that are just as secure as the costly certificates being sold by Comodo and Symantec. This is allowing us to begin to make SSL a default, not an upsell, as it should be. We encourage people to donate to Let’s Encrypt if they’ve benefited from being able to easily issue certificates. As they are a non-profit organization, this is a tax deductible cause.

Why didn’t we market SSL certificates earlier?

I believe I summarized above why we have never really been interested in funding CA’s… the industry model is dishonest. But that’s not the main reason we never prioritized issuing SSL certificates! The main issue has been the search ranking impact on transitioning a new customer over to SSL. Google claims to provide a search boost for implementing SSL, and they very well might. We have found, however, that transitioning a site from non-SSL to SSL triggers a full site reindex and there’s about a month of time where organic traffic falls off. This could be disastrous to a blog or ecommerce store that’s monetizing. So for these sites, we typically now suggest they just direct the login and checkout pages to use SSL and leave the rest non-SSL unless they can afford the temporary drop in traffic. New properties we will be going SSL all the way on launch. Our billing pages have been SSL for some time and this site has a certificate issued. I just haven’t had a desire to take the search hit making it default yet.

Leave Reply