Yes, You Should Probably Have A TLS Certificate

Last week’s article covering the decision to distrust Symantec-issued TLS certificates generated a great response from our readers. One common question we received, and one that pops up just about any time SSL/TLS comes up, is how to determine when a site does and does not need such a certificate. Spoiler: Your site should probably have a TLS certificate.

A subject of some discussion in the web community surrounds the use of TLS certificates and the implementation of HTTPS that these certificates allow. While their use is critical on sites where sensitive data from visitors may be involved, like payment data or other personally identifiable information (PII), the debate concerns the use of HTTPS in cases where users aren’t providing sensitive input. In today’s post, we’ll take a practical look at the difference between HTTP and HTTPS traffic, and discuss the benefits of being issued a certificate regardless of the way users interact with your site.

What’s TLS? Is It Different From SSL?

Before we really dig in, let’s clear up some terminology for anyone who might be unfamiliar.

HTTPS (short for Hypertext Transfer Protocol Secure) allows for the secure transmission of data, especially in the case of traffic to and from websites on the internet. The security afforded by HTTPS comes from the implementation of two concepts, encryption and authenticationEncryption is a well-known concept, referring to the use of cryptography to communicate data in a way that only the intended recipient can read. Authentication can mean different things based on context, but in terms of HTTPS it means verification is performed to ensure the server you’re connecting to is the one the domain’s owner intended you to reach. The authentication portion of the transaction relies on a number of trusted sources, called Certificate Authorities (CA for short). When a certificate is requested for a domain name, the issuing CA is responsible for validating the requestor’s ownership of that domain. The combination of validation and encryption provides the site’s visitors with assurance that their traffic is privately reaching its intended destination, not being intercepted midway and inspected or altered.

TLS, or Transport Layer Security, is the open standard used across the internet to facilitate HTTPS communications. It’s the successor to SSL, or Secure Sockets Layer, although the name “SSL” has notoriously picked up common usage as an interchangeable term for TLS despite it being a deprecated technology. In general when someone brings up SSL certificates, outside of the off chance they’re literally referring to the older standard, they’re probably talking about TLS. It’s a seemingly minor distinction, but it’s one we hope will gain stronger adoption in the future.

I Shouldn’t Use TLS Unless I Really Need To, Right?

There’s no shortage of conflicting advice across the web regarding when to implement TLS and when to leave a site insecure, so it’s no surprise that a lot of strong opinions develop on both sides of the issue. Outside of cut-and-dry cases like PCI compliance, where payment transactions need to be secure to avoid a policy violation, you’ll find plenty of arguments suggesting cases where the use of TLS is unnecessary or even harmful to a website. Common arguments against the wide use of TLS tend to fall into two general categories: implementation and performance.

Concerns about implementation difficulties with TLS, like the cost of purchasing a certificate, difficulty in setting up proper HTTPS redirects, and compatibility in general are common, but are entirely manageable. In fact, TLS has never been more accessible. Let’s Encrypt, a free certificate issuer which launched in early 2016, has issued just under two-thirds of the active TLS certificates on the internet at the time of this writing. Following the flood of free certificates into the marketplace, many popular web hosting companies have begun allowing Let’s Encrypt certificates to be installed on their hosted sites, or are at least including their own certificates for free with their hosting. After all, site owners are more security-conscious now than ever, and many will happily leave a host if TLS is a cost-prohibitive endeavor.

Other pain points in the implementation of HTTPS, like compatibility with a site’s existing application stack, are no different than the pain points you’d see following other security best practices. Put simply, avoiding the use of HTTPS because your site will break is the same as avoiding security updates because your site will break. It’s understandable that you might delay it for a period of time so you can fix the underlying issue, but you still need to fix that issue.

The other arguments against widespread TLS are those of performance concerns. There’s certainly overhead in play, considering the initial key exchange and the processing necessary to encrypt and decrypt traffic on the fly. However, the efficiency of any system is going to depend heavily on implementation. In the case of most sites, the differences in performance are going to be negligible. For the rest, there’s a wealth of information available on how to fine-tune an environment to perform optimally under TLS. As a starting point, I recommend visiting Is TLS Fast Yet? to learn more about the particulars of this overhead and how best to mitigate it.

My Site Doesn’t Take Payments, So Why Bother?

Each debate ultimately hinges on whether the site owner sees value in HTTPS in the first place. A lot of the uncertainty in this regard can be traced to unfamiliarity with the data stored in HTTP requests, as well as the route that these requests travel to reach their destination. To illustrate this, let’s take a look at the contents of a typical WordPress login request.

The request contains a number of interesting pieces of information:

  • The full URL of the destination, including domain and file path
  • User-Agent details, which describe my browser and operating system
  • My referer, which reveals the page I visited prior to this one
  • Any cookies my browser has stored for this site
  • The POST body, which contains the username and password I’m attempting to log in with

The implications of this request falling into the wrong hands should be immediately recognizable in the fact that my username and password are plainly visible. Anyone intercepting this traffic can now establish administrative access to my site.

Contrast this with the same request submitted via HTTPS. In an HTTPS request, the only notable information left unencrypted is the destination hostname, to allow the request to get where it needs to go. As far as any third party is concerned, I’m sending this request instead:

Outside of examples as obvious as login security, the thing to keep in mind above all is the value of privacy. If a site’s owner hasn’t installed a TLS certificate, even though the site is purely informational and takes no user input, any traffic to that site can be inspected by the user’s ISP, or even the administrator of the network they’re connected to. This is notably problematic in certain cases, like when someone might be researching private medical or legal matters, but at the end of the day the content of a site is irrelevant. Granted, my hat probably contains a bit more tinfoil than most, but there’s no denying this is an era where browsing habits are tracked wherever possible. Real examples exist of ISPs injecting advertising into unencrypted traffic, and the world has a nonzero number of governments happy to inspect whatever traffic they can get their hands on. Using HTTPS by default shows your site’s users that their privacy is important to you, regardless of whether your site contains anything you might consider private.


The internet at large is rapidly adopting improved security standards, and the majority of web traffic is now being delivered via HTTPS. It’s more important than ever to make sure you’re providing your users with the assurance that their traffic is private, especially with HTTP pages being flagged as “Not Secure” by popular browsers. Secure-by-default is a great mindset to have, and while many of your users may never notice, the ones who do will appreciate it.

Interested in learning more about secure networking as it pertains to WordPress? Check out our in-depth lesson, Networking For WordPress Administrators. It’s totally free, you don’t even need to give us an email address for it. Just be sure to share the wealth and help spread the knowledge with your peers, either by sharing this post or giving them the breakdown yourself. As always, thanks for reading!

Did you enjoy this post? Share it!


  • From looking after a largish news website, I've come to find that a lot of general users seem to think that a site without a cert is going to hack their computer and steal all their details, regardless of whether they type something into the site or not.

    For that reason alone, I would install a cert on all sites.

    For me personally, the biggest benefit is from being able to implement http/2 and having faster loading sites without huge combined asset files.

    And then there's Google giving an SEO boost for secure sites which is another nice side effect.

    Since certs are now free I don't see any downside to adding one for any site.

  • You mentioned it in your comment on the previous article, but it would be worth repeating in your "Why bother" section in this article: the search engines are starting to weight their results towards secure sites, which is another distinct reason to implement HTTPS on one's sites.

    In other words, notwithstanding any security advantages, if your site isn't secure, you're probably missing out on search ranking.

  • Thanks for a great article that clearly explains TLS and SSL! If a customer ever asks if they need it in the future, I’ll be sure to send them here! I personally, care about my website, and would rather keep it secure, even if just for myself. Wordfence + TLS = peace of mind.

  • I am just wondering...So if we have an SSL for the website, we should be thinking of switching it to TLS, although in the article, I see that you have mentioned that it's a depreciated technology.

    Or did you mean that SSL is a depreciated technology?

    And is TLS is something you hope that will gain stronger adoption?

    • Hey Carlos! To clarify, the SSLv3 protocol has been deprecated. However, it's a pretty safe bet that if your site is running on modern hosting and using HTTPS, TLS is doing the encryption. If you want to be absolutely sure, you can run a test like the one found at to run some more thorough checks on available protocols.

  • In addition, if you use Google Ads, there is more benifit. Sure Google gives preference to SSL for Organic (SEO), but Google Ads also perfers SSL.

  • Aside from the performance, security, seo, and not being flagged as insecure, there is no reason to use an SSL unless you're taking payments /sarcasm

  • Great article on TLS and SSL. Will continue passing this information along. Have some clients on Let's Encrypt. Hoping to get more signed up as well!

  • Thanks for sharing this wealth of knowledge about web security. Many website owners are very conscious of the security of their site. Unfortunately website security is what many of us are not trained to do, so we rely on our website hosting company to provide optimal security for our sites's visitors information.

  • Thanks Mikey Veenstra, I will check it out....

  • TLS is the new form of SSL. The certificates needed though are still more commonly called SSL Certificates, even though SSL itself is no longer considered secure. (TLS is though)

  • Next, there is a need to educate and push everyone to http/2. It overcomes several limitations and make TLS faster.

  • Thanks so much for this blog post, and for the link to Let's Encrypt. I've now installed on all my sites!