Use SSL/HTTPS To Rank & Look Better on Google (Updated 2020)
Updated: September 2020
Migrating to HTTPS protocol has now become the norm. It is a more secure and performant web that also includes some additional benefits like search ranking boost for secure pages. In case you still haven’t implemented the HTTPS protocol on your website, here’s a detailed and actionable guide on how to set this up for top-tier SEO results.
Enjoy the read!
Table of contents:
- What is SSL?
- What is TLS?
- What is SSL/TLS Used For?
- How Safe is SSL/TLS Protocol?
- Major SSL/TLS Library Implementations
- How to Get a Certificate?
- Which Certificate to Get?
- How Does HTTPS Work?
- How to Get and Implement HTTPS Protocol?
- What Are the Benefits of Using HTTPS?
- What Are the Drawbacks of Using HTTPS?
- Advanced Configuration & Additional Security Mechanisms
- Encryption as the Future of the Web
- Public Interest, Outcry & Feedback
- Introduction of GDPR
Right now, there’s a term salad thrown around by less tech-savvy people around this topic, causing some confusion and uncertainty with questionable use of terminology and vague recommendations. That’s why we first have to outline a clear and simple overview of the most important definitions. This way everyone knows what’s what, why do they need it, how to get it and how to implement it in production.
By the end of this article, you should be well versed not only with the meaning behind the terms SSL and HTTPS, why they’re important, how do they work, and how to implement them on your website; but we’ll also take a look at their significance in your overall digital marketing setup.
Without further ado, let’s encrypt… I mean, start (you’ll get the pun later on).
What is SSL?
SSL (Secure Sockets Layer) is a cryptographic protocol that establishes an encrypted connection between a client and a server (i.e. your visitor and your website). “SSL” is actually a legacy term from the time when it was still the only protocol of that kind available on the web. Today, the term isn’t used much (or at least it shouldn’t be) due to its age/weaknesses and has been replaced by its successor TLS (Transport Layer Security). Most of the time, when someone says “SSL”, they actually mean “TLS” without knowing it.
What is TLS?
TLS is an improved cryptographic protocol that uses stronger encryption algorithms and, compared to SSL, offers unparalleled privacy and performance. Its most recent version (TLS 1.3) is now being adopted by a great number of security-minded web hosting and CDN companies, even though the rollout has been quite slow (much like it is the case with all other infrastructure changes that are this bug (e.g. IPv6 address space adoption).
The biggest benefit induced by TLS 1.3 is that it brings a faster and more secure connection when compared to 1.1 and 1.2 protocols.
What is SSL/TLS Used For?
This protocol is most typically used to:
- encrypt connections to web and mail servers
- encrypt the connection between your smartphone and manufacturer servers when they’re searching for an update or syncing contact list
- encrypt the connection when you’re using an e-banking app or endlessly swiping through Tinder and/or Instagram, etc
Here’s an example.
It is likely that at some point you had to configure an email client to receive Gmail or Outlook email. Here, you probably noticed several port numbers to choose from:
- TLS ports (for modern software)
- SSL ports (for legacy software)
Chances are you’re already using TLS without knowing it. It’s also being used by a whole range of IoT devices such as IP cameras, refrigerators, thermostats, smart cars, and basically everything that requires a secure, encrypted connection to its HQ.
When it comes to sites and pages, TLS is used to provide a secure HTTP protocol (notice the “S” in HTTPS). This is basically a bi-directional data tunnel between two endpoints (the website you’re visiting and the computer you’re browsing from).
How Safe is SSL/TLS Protocol?
The real answer is that SSL/TLS is as safe as it can be these days. The big picture is that the overall security of your website also depends on various factors outside this protocol (or are loosely related to it).
Stealing your personal data during an online transaction or communication involves a lot of technical challenges, which is why these breaches are usually performed by highly skilled people who are often sponsored by the state. They typically have budgets and resources of such magnitude that if they really want/need to hack into your system and steal your information, they probably will. It happened numerous times in the past, even to some of the most powerful companies in the world, and it will continue to happen.
Terms like BEAST, BREACH, CRIME, FREAK, Heartbleed, DROWN are all connected in the web-related context as they account for protocol vulnerabilities that got exploited and led to the extensive damage done to many companies and their customer base. More detailed info on SSL/TLS vulnerabilities available here.
The best-case scenario involves privacy issues where the attacker collects personal information (names, email addresses, etc). The worst-case scenarios typically include massive leaks of passwords, credit card details, business secrets and a plethora of other real-world-impact pieces of data.
The best practice here is to obtain necessary certificates from trustworthy authorities and keep them secured, with read-only file system permissions so only authorized and trusted personnel and applications can access them.
If an unauthorized 3rd-party gains unrestricted access to your web server and its config files, it can lead to much more serious problems than mere web traffic security.
Cipher Suites determine the strength of your encryption. They are a set of algorithms deployed by a web server/browser pairing that is, figuratively speaking, their mutual agreement on how to communicate with each other.
The groups of cipher suites include:
- Modern compatibility
- Intermediate compatibility
- Old backward compatibility
These groups are used by system administrators and DevOps engineers to designate minimum application end-user compatibility. This enables them to determine whether or not to support legacy mobile devices that do not offer modern security features to their users.
Choosing modern cipher suites will enable only the latest and greatest clients to communicate with the server. Mozilla offers an excellent resource for developers on this subject. Mozilla’s specifications for the three compatibility groups are (the following web client versions and above):
Firefox 27, Chrome 30, IE 11 on Windows 7, Edge, Opera 17, Safari 9, Android 5.0, Java 8
Firefox 1, Chrome 1, IE 7, Opera 5, Safari 1, Windows XP IE8, Android 2.3, Java 7
Windows XP IE6, Java 6
Mozilla’s SSL config generator is another great resource for developers/system administrators as it allows you to generate web server HTTPS configurations for specific versions and compatibility groups.
Major SSL/TLS Library Implementations
SSL library is a set of reusable cryptography functions. There are several different implementations of these libraries which are, to a certain degree, compatible and can be used as drop-in replacements for one another. These implementations are meant to clean up the code, tighten the security and/or provide additional features, depending on the nature of the project or the company goals.
- OpenSSL (project website) – The original open-source library managed by the community, used in the majority of software and hardware implementations. However, the majority of the above-mentioned vulnerabilities specifically apply to this version. Software such as OpenSSH and OpenVPN depends on it.
- LibreSSL (project website) – An alternative library forked from the original by the OpenBSD project. Its goal is to modernize the code base, improve security, and apply best practice development processes. Compared to OpenSSL, it has considerably fewer vulnerabilities and has been increasingly adopted within the tech and security community. Major players also opt for this one. Apple, for example, uses it as a default SSL/TLS library in MacOS, their operating system.
- BoringSSL (project website) – Another alternative library, forked from the original one by Google to be used in their projects. According to the source above, this library is not intended for general use. There are certain ways to use it via operating system pre-built packages. BoringSSL is the default SSL/TLS library in Chrome/Chromium, Android, and other Google apps. It is also utilized by certain security-focused CDN vendors (like Cloudflare).
- GnuTLS (project website) – Alternative library built to comply with the GPL license and is used in numerous open-source projects (including GNOME, Exim, Wireshark, Emacs, CUPS, etc).
How to Get a Certificate?
To use the HTTPS protocol, you first need to acquire an X.509 certificate and the necessary files from a trusted Certificate Authority (CA) organization by filling a Certificate Signing Request (CSR) form where you provide the information on your company and domain as proof of identity.
When the Certificate Authority organization validates your identity, you are (typically) provided with a ZIP archive that contains the files necessary for your web server configuration.
There are numerous CAs companies out there that you can trust: Symantec, GoDaddy, GlobalSign, GeoTrust, DigiCert, Comodo. This certificate can be free of charge, depending on your needs and the nature of your project.
We highly recommend (and prefer) Let’s Encrypt. It provides high-end cryptography, it’s free, and is easy to automate and utilize in dynamic environments, as well as during the app containerization process and cloud migration.
It is important to note that Let’s Encrypt certificates last for 90 days, while those provided by commercial vendors last for 12+ months. Though this may seem like a bit of a hassle, this practice actually serves a couple of crucial purposes:
- Shorter-lasting certificates reduce the attack vector from compromised keys and mis-issuance. Since their duration is shorter, there’s less time for the attacker to use the certificate/key combo and cause damage.
- It encourages automation of certificate renewal. This is important for dynamic and busy environments, as system administrators are typically no longer expected to do this procedure manually (since it is now part of an outmoded workflow). When certificate renewal is automated, their short lifetime will no longer make them less convenient than longer-lasting ones as there’s no need for human involvement in the process apart from occasional infrastructure security audits.
Back in 2016 when the Internet Security Research Group (ISRG) launched Let’s Encrypt, it was an important breakthrough as it marked the beginning of a more open (and cheaper) web, wherein purchasing of quality certificates and cryptography was no longer the practice. You can now simply ask for it. Although this was a substantial blow to the CA industry, it was great news for individual webmasters and SMBs, as they didn’t have to pay for web security from that moment on.
This initiative was backed and sponsored by some of the most prominent companies in the industry, including Mozilla, Akamai, Cisco, EFF, Google, Facebook and more. Additionally, more and more web hosting companies are now bundling Let’s Encrypt-generated certificates for free with their own offers, which is quite handy for those who are just starting their business or migrating to the other host, as you likely won’t have to do anything more than click a button to acquire an automatically renewed certificate – basically, just set it and forget it. Others, however, will have to do a bit more reading and clicking, but nothing too serious.
Note on self-signed certificates:
In the past, when a developer needed to test an app through HTTPS protocol, they would need to generate the certificate themselves via a couple of OpenSSL utility CLI commands. These are called self-signed certificates and they can provide you with the same level of encryption, security and privacy (virtually creating your own CA). Unlike certificates obtained from services like Let’s Encrypt, however, these self-signed certificates are not trusted by browsers. This means that when a user visits a page with this type of certificate, the browser will show a security warning:
Although self-signed certificates are still useful, especially in development and for non-critical stuff, the free and trusted certificates are squeezing them out, thanks to organizations like Let’s Encrypt.
You can easily generate certificates through some command-line fiddling or through certain web services (like SSL for Free, which is basically just a front-end to the Let’s Encrypt service).
About Certificate Authorities
CA companies are being vetted by web browser vendors (Google, Mozilla, Microsoft, etc.) who then determine if the certificate can be trusted or not. This decision depends on several factors like credibility, quality, and potentially even money.
Several years ago, Google removed Chinese CAs StartCom and WoSign from Chrome as they failed to meet the high standards expected of a Certificate Authority. The consequence was that the domains (that used certificates issued by these Chinese vendors) started showing safety warning messages to their visitors because their CA wasn’t recognized by the browser anymore. Other popular browsers soon followed suit, which led to StartCom’s business crashing overnight.
When we take into consideration all the info mentioned above, we can conclude that the CAs are (to a certain extent) regulated by browser vendors, which means they are to keep their operative standards at high levels in order to remain present in browsers and keep their business running. The minimum requirement for CAs to reach and maintain these high-level standards is not issuing the same certificates for multiple domains, while they also mustn’t issue certificates for fake domains and/or companies.
To put this into a tangible context: let’s say you own the website shop.com and you have the certificate for that domain. If someone else is capable of obtaining the same certificate for myshop.com, for example, they would be able to impersonate your business and potentially perform malicious actions against the consumers who mistake the fake shop for yours, which can lead to serious damage done to your business and brand.
This is why it is paramount for CAs to conduct business identity validation in a proper and thorough manner.
Which Certificate to Get?
If a company needs to communicate high trust levels to its users/visitors, they get an Extended Validation (EV) certificate displaying a green browser address bar or text, indicating that the company underwent a rigorous identity verification process and that this business can be trusted.
The branding segment of EV certificates used to display the geolocation of the website along with the brand name in the browser’s address bar, as it is shown here:
This practice was abandoned once the browsers stopped directly showing the EV certificate in the address bar, thus decreasing the website’s need for having an EV certificate. This resulted in EV prices dropping, as the presence of an EV certificate stopped being as conspicuous as before this trend. Nonetheless, the EV-related information and the geolocation can still be accessed by clicking on the padlock icon in the URL, as shown here:
EV certificate prices may range from $50 to even $300+, depending on the vendor, but note that today all EV, OV (Organization Validated) and DV (Domain Validated) certificates work the same way (for the most part) and offer the same security levels in terms of encryption strength. For instance, Let’s Encrypt issues DV certificates.
What’s the Difference Between SSL Certificate Types?
DV – Domain Validated SSL Certificates
DV certificates are the fastest and most budget-friendly solution. They involve the minimal amount of identity validation work done by the CA, as it boils down to the verification of the domain so it is clear that it is owned by the person or entity listed on the domain’s WHOIS entry. According to vendors, it’s intended for small businesses, small-volume e-commerce stores, and general websites and blogs.
OV – Organization Validated SSL Certificates
These SSL certificates are a bit more costly, as the issuing of these involves checking the online government databases or other publically accessible authority resources to validate the data provided by an individual or organization during CSR submission.
EV – Extended Validation SSL Certificates
EVs are the second most expensive certificates and are actually the slowest to obtain due to a thorough identity validation process that (aside from the steps listed above) requires uploading existing company legal documents, bank statements and other details. This is done so it can be proven that a genuine company is behind the certification request. When we take into consideration the pricing and all the requirements, these certificates are aimed at major corporations, large businesses and government entities so individuals who are not business owners can’t get it.
According to commercial CAs, the benefits of purchasing an EV certificate, inlcude:
- Increased transaction conversion rates
- Lowered shopping cart abandonment
- Gaining an edge over your competitors
- Showing customers you care about their security
- Increased security against phishing schemes
It is also important to know that commercial CAs often offer the so-called “assurance warranty” for their certificates. This is basically a promise that they will compensate the end-user (in millions of dollars) in case that they get their credit card charged in a fraudulent manner by the holder of the certificate. This practice is used as reimbursement and proof that they perform their identity validation process properly, with many CAs stating they never had any such warranty claim, thus showing how serious their validation is.
Wildcard SSL Certificates
This is the most expensive certificate that also involves identity and ownership validation of all subdomains that you want to secure using a single certificate. Typically, this certificate type is used by large companies with 1 or more subdomains involved in their operation and they want to cover www, webmail, along with different language-targeted subdomains such as fr.domain.com, de.domain.com, etc.
Those running big international companies that are often under higher levels of scrutiny and find other benefits of the EV certificate useful should definitely opt for that one. SMBs, online stores of similar sizes, as well as SaaS-based product websites, however, should be in pretty good hands with the Let’s Encrypt-issued DV certificate.
According to a recent update coming from, as of September 2020, all publicly trusted TLS certificates need to last 398 days or less. This change affects only the certificates issued from the Root CAs preinstalled with iOS, iPadOS, macOS, watchOS, and tvOS.
The most recent update coming from Apple states that as of September 2020, all publicly trusted TLS certificates need to last 398 days or less. This change affects only the certificates issued from the Root CAs preinstalled with iOS, iPadOS, macOS, watchOS, and tvOS.
How Does HTTPS Work?
A greatly simplified interpretation of client/server communication over HTTPS would look something like this:
- The client attempts a connection to the server.
- The server sends a certificate to the client.
- The client acknowledges that the certificate was signed by an organization it trusts and that this organization certifies that the certificate belongs to the server the client wants to communicate with securely.
- Then the client generates a random key, encrypts it with the public key in the certificate, and sends it back to the server.
- The server decrypts the key and uses the shared secret the server and client now have to secure further communications.
How to Get and Implement HTTPS Protocol?
There are numerous web servers and CMSs available and although all are configured differently, the basic implementation concept is shared across all of them, and it involves:
- Obtaining the certificate and key files and placing them in the permissions-restricted path on the server.
- Editing the main web server or individual vhost configs so the SSL engine is enabled and to specify paths to the certificate, as well as the key file.
- Restarting web server software to activate the changes.
- Configuring your CMS (sometimes this is not required) to use HTTPS schema and perform the find/replace operation within your database to change all HTTP schema URLs to HTTPS. Our agency has used the WP Migrate DB WordPress plugin countless times in order to achieve this successfully for our clients, so we highly recommend it.
- Performing global 301 redirect rule(s) so that HTTP requests for a certain page would be redirected to the same page with HTTPS schema in its URL.
- Creating a new Google Search Console property for the website that uses HTTPS schema and adjusting the Google Analytics configuration so it contains the new website URL as well.
- Testing your pages via Qualys SSL Labs tool.
It is important to note that performing a full website backup prior to this entire procedure is highly recommended, just to be on the safe side.
The optimal configuration and setup test should look something like this:
Note: When server IP is clicked, more connection information is revealed.
We won’t be listing all the web server software packages and their configurations here, as it would be impractical, so here’s a link to one of CAs that offers this info in one place: DigiCert’s SSL Certificate Installation – the article contains a list of around 100 web servers and their SSL configuration instructions for those using some obscure, proprietary web server software.
Those using modern, widely adopted solutions (like Nginx or Apache), we recommend checking out the H5BP project’s Github repository. These configurations are crowdsourced and tested for performance, compatibility, and security by the community.
What Are the Benefits of Using HTTPS?
This is, most likely, the article section you’re here for. If you’re an online business owner, there are multiple benefits to using a secure protocol (HTTPS) instead of the plain, old HTTP:
1. Improved Brand Perception
A couple of years ago, as a part of an initiative to make the web a safer place, the most popular web browsers such as Google Chrome and Firefox started marking HTTP-only websites as insecure if they contained any text inputs such as login forms or credit card data fields.
Since October 2017, when you land on an HTTP-only page it displays an icon in the address bar which should get your attention that something is not right with the page/website. After you start entering text in any text input field on the page, the address bar changes and displays a “Not secure” label which should prevent you from continuing or at least raise your attention that an unsafe operation is in progress.
This works great in theory, but ask your aunt if she understands this UX or does she want to buy that new magical weight loss ebook so much that she doesn’t care for that small address bar glitch. What’s the worst that can happen, right?
When using HTTPS protocol, there’s a certain dose of credibility in your visitor’s eyes; trust that you know what you’re doing and that you respect their security and privacy. Since trust and credibility are important aspects of online shopping and the general perception of a brand, avoiding that “Not secure” label and instead showing green letters in the browser address bar can do great things for your conversion rate and sales.
When it comes to actual user perception of HTTPS as a security protocol, different reports show that internet users generally pay insufficient attention to online security despite the fact they express concerns about this issue.
When it comes to SSL/TLS, however, it could be assumed that an average user is not familiar with the technical jargon related to it, as pointed out in a study by researchers from both Carleton University and National Research Council in Canada.
The study showed that people make little difference in terms of decision making between websites that use SSL and those that don’t. According to them, this is especially important for the Chrome browser, where little space is available for showing security cues.
On the other hand, when a proper trust badge is placed anywhere on a website, users feel more secure using their personal information on it. Some websites decide to place this badge in the footer section and especially on product pages, where users are required to leave their data and perform a transaction. Additionally, there has been a study by ConversionXL Institute which tested how trusted these badges really are, and what their efficacy is.
Therefore, despite the fact that average internet users make little difference between http:// and https:// protocols, companies should consider using the latter to prevent data loss and gain users’ trust.
With people gradually becoming aware of online data security and privacy issues, business websites need to raise the standards in this respect. Coupled with better search rankings, SSL implementation obviously offers multiple benefits and should be at least considered by most modern companies.
2. Improved Performance via HTTP/2
The HTTP protocol provides a way for web browsers to communicate with web servers and display web pages. The HTTP/2 protocol is a big upgrade of existing HTTP/1.1 in terms of features and performance. We wrote about HTTP/2 around 6 years ago when it started becoming mainstream tech.
Some benefits of HTTP/2 over HTTP/1.x, inlcude:
- Data compression of HTTP headers
- HTTP/2 Server Push
- Pipelining of requests
- Fixing the head-of-line blocking problem in HTTP 1.x
- Multiplexing multiple requests over a single TCP connection
All these features help to make HTTP/2 the best foundation for the future of the web-verse by making requests smaller, parallelized and better prioritized.
What does HTTP/2 have to do with HTTPS and ranking in Google you might ask?
As Google considers web performance and user experience as top priorities, this search engine gives a ranking boost to websites which are fast by making speed a ranking signal.
HTTP/2 is important for HTTPS since HTTP/2 cannot be used without HTTPS, as it requires it explicitly. Visiting the website on port 443 (default HTTPS port) triggers HTTP/2 connection when the web server is configured to support it. These two make up a perfect combination as you’re getting a more secure and faster website that both your visitors and Google will love.
To leverage the biggest advantages of the HTTP/2 and HTTPS combo, it is recommended to check out the H5BP project that offers configurations containing industry’s best practices for security and performance for one of the most popular web server software pieces including Nginx, Apache, Lighttpd, IIS and Node.
HTTP/3 expands on the concepts established by HTTP/2, and although it still isn’t widely used worldwide, HTTP/3 support has been recently added to Chrome, while certain platforms are already using it (like YouTube in the Chrome browser). Although third-generation HTTP hasn’t yet become the default standard protocol, it does have non-default support and can be enabled in Chrome and Firefox stable versions.
3. Improved Security
As HTTP is a text-based protocol, it is quite easy to intercept its traffic and access anything that is being transmitted through it. By using HTTPS (a binary protocol), potential attackers cannot see the actual content of the request, only the artifacts. This means that transferred data is safe from prying eyes unless they’re able to get a hold of the key and decrypt the traffic to snoop on.
4. Improved Google Rankings
Though Google’s HTTPS Everywhere initiative guarantees a slight boost in the ranking for websites that offer HTTPS by default, this increase alone isn’t too dramatic and is not a “silver bullet” ranking boost solution as some tend to represent it.
This ranking boost is what Google calls a “very lightweight signal” and it accounts for a very, very small advantage over your direct competitors who haven’t moved onto HTTPS yet. The implementation of HTTPS alone isn’t likely to push you to the top of the SERPs, as there are many other more important signals at play here, like high-quality content and high-authority backlinks.
The main value of HTTPS for Google rankings lies in the combining of the migration itself with the previously mentioned benefits which also guarantee improved rankings (website speed from HTTP/2 – especially on mobile, increased CTR from using HTTPS schema in URL – yes, CTR is a ranking signal). All these combined can actually result in a meaningful rankings improvement. This holistic approach accounts for a synergy of individual components and provides more value than each individual component alone.
We recommend watching the HTTPS Everywhere talk by Ilya Grigorik and Pierre Far from Google I/O 2014 , especially if you are looking into migrating to HTTPS. The discussion tackles some interesting aspects of the entire process as well as busting decade-old myths (please disregard any mention of SPDY protocol as it was deprecated in 2016 in favor of the HTTP/2).
Additionally, Google has an informative ‘Secure your site with HTTPS’ article in Search Console’s Help section that gives best practices and points to some common issues of the process. You can also take a look at their Site Move help article that has an FAQ covering some burning questions in regards to website migration to HTTPS and its benefits.
What Are the Drawbacks of Using HTTPS?
The pitfalls of using HTTPS are not related to the protocol itself, but to the complexity of the implementation process and possible outcomes. For example, the most common case (from our experience) is that clients implement the HTTPS protocol but do not perform all other necessary procedures that help Google to understand that you’ve performed the migration.
Those who implement HTTPS but omit the precise configuration of 301 redirects and the changes in paths (so only HTTPS URLs exist), often face a multitude of problems. Some of the most impactful issues include:
Although the negative impact of content duplication on rankings is greatly exaggerated within the SEO community (typically in an effort to sell more services to the client), there are certain benefits to not using duplicate content. According to Google, content duplication can be both non-malicious and malicious, depending on the content volume and intention behind its duplication.
By non-malicious duplicate content, Google considers:
- Regular forum pages that have stripped-down versions of themselves intended for mobile devices
- E-commerce product page URLs with various sorting/filtering parameters
- Print-only page versions
By malicious duplicate content, on the other hand, Google considers pages that are deliberately duplicated across different domains and subdomains in order to manipulate rankings and drive more traffic. Using this methodology results in subpar UX because the visitor ends up getting the same (or extremely similar) content in search result pages, which typically leads to user frustration.
According to Google, they are capable of reducing duplicate content display in search results to a minimum, but I beg to differ and believe there’s much room for improvement here.
Now, you don’t have to worry if your website has both HTTP and HTTPS pages indexed as there’s no duplicate content penalty. However, if you want to provide a top-tier experience to your potential visitors, we recommend consolidating HTTP and HTTPS site versions by performing global 301 redirection so that only URLs with the desired schema appear in search results.
This strategy comes with an added bonus wherein the value from inbound links will continue to pour into a single page, rather than being distributed across multiple. For those who assume that these redirections have negative impact because inbound link value is lost during redirection, we assure you that this is merely a misconception as Google confirmed that 301 redirects are transferring 100% of the value to the destination.
This may affect the overall UX score because the web page might not be displayed as intended, or is lacking features, or is utterly unusable.
The mixed content problem can easily be identified with a web browser on a single page, but tracing this issue across an entire website requires crawling software (like Screaming Frog).
Here’s what the mixed content issue looks like in a browser:
Note the little, crossed shield icon at the right. When clicked, it displays this dialog:
It is essential that you try to detect and, if necessary, fix this problem after the migration is performed.
Advanced Configuration & Additional Security Mechanisms
Aside from SSL/TLS implementation, there are also several optional HTTP headers that can be added to the web server configuration in an effort to make connections and SSL/TLS implementation even stricter.
HSTS – HTTP Strict Transport Security
This header commands browsers to cache the certificate for a designated period and to connect exclusively via HTTPS from that moment on. Use this if – and only if – you’re completely sure that you are not switching back to HTTP-only. Once the web browser is instructed to do so, it won’t be able to load the HTTP-only version of the website until the time value entered in HTTP header configuration runs out (this period is typically 6-12 months).
In addition to the root domain, this header can be also configured to cover subdomains as well. Note that this particular configuration might not be what you want if you’re using HTTP-only subdomains for any purpose (staging area, analytics, webmail, etc.).
Also, the domains that use HSTS can be submitted to the preload list – a service for website inclusion into Google Chrome’s (and some other major browsers) hard-coded list of HTTPS-only websites, which the web browser doesn’t even try to connect to over plain HTTP. For more details on implementation, we suggest reading these instructions for Nginx and Apache.
HPKP – HTTP Public Key Pinning
Note: this is an outmoded (legacy) header and we are mentioning it purely for the contextual value of the next header on this list.
Back in 2018, Google Chrome deprecated support for HPKP due to usability issues that make this security mechanism difficult to adopt and use by most.
In simple terms, the idea behind the introduction of HPKP was to detect certificate public key change for a specific host/domain. This can occur when the CA gets compromised (or tricked, remember the StartCom and WoSign story?) rendering the attacker capable of issuing or obtaining valid certificates for literally any domain.
Webmasters can limit the number of CAs that can issue certificates for their domain by adding an HTTP header containing one or more SHA-256 (cryptographic hashing algorithm) values of certificate public keys.
Expect-CT – Certificate Transparency
Google introduced and advocated this header as a safer replacement for HPKP. It is flexible as it gives webmasters a chance to recover from configuration errors that can result in a website being unusable in certain cases. It also fixes certain structural flaws in the SSL certificate issuance system. You can find more details on Expect-CT on the project’s official website.
This mechanism allows the monitoring and auditing of SSL certificates almost in real-time, allowing you to detect mistakenly/maliciously issued certificates and CAs gone rogue.
Expect-CT HTTP header is meant to be used in conjunction with external monitoring services such as ReportURI where security policy violations can be reported, observed and acted upon. Those who seek in-depth material on Expect-CT and implementation can check out Scott Helme’s (security researcher and international speaker) blog posts on this subject: A New Security Header: Expect-CT & Certificate Transparency, an Introduction.
OCSP Stapling – Certificate Status Request Extension
OCSP is a way for a client to check the certificate revocation status. In the case where the web host gets compromised, an attacker is able to steal a certificate and impersonate the website/company by using the same certificate on their own website with similar domain name and branding, for instance, to trick visitors into thinking that they are dealing with a legitimate company and potentially inflict financial damage on them.
The web hosting company can replace the compromised certificate but this won’t stop an attacker from impersonating you as long as the certificate is still valid. This situation requires certificate revocation thus the certificate revocation check, or OCSP is introduced.
This way, one of the overheads of using the SSL/TLS – the task of revocation status checking – is delegated to the webserver instead of to the client. This improved the connection performance as the client doesn’t need to check the Certificate Revocation List (CRL) on the fly anymore.
CRL is a list of revoked digital certificates by a certain CA and is a deprecated method of doing this check because it was responsible for adding the overhead of up to 1 second (or even more depending on the situation) to connection establishing which obviously affected the perceived performance of the website in your visitor’s eyes. OCSP is considered a great SSL/TLS connection performance enhancement.
Encryption as the Future of the Web
Google and its HTTPS Everywhere initiative are being loud and clear about the fact that encryption and HTTPS are the future of the web. This is why their crawlers check for HTTPS pages by default. So, if you have both HTTP and HTTPS pages with no proper 301 redirections in place, the crawlers will attempt to crawl both and offer HTTPS page in search results under the following conditions:
- The page doesn’t contain insecure dependencies.
- The page isn’t blocked from crawling by robots.txt.
- The page doesn’t redirect users to or through an insecure HTTP page.
- The page doesn’t have a rel=”canonical” link to the HTTP page.
- The page doesn’t contain a noindex robots meta tag.
- The page doesn’t have internal links to HTTP URLs.
- The sitemap lists the HTTPS URL or doesn’t list the HTTP version of the URL
- The server has a valid TLS certificate.
Some might say “Well, why not just leave it up to Google to manage crawling, indexation and ranking of the pages they want?”
Google tends to automate a plethora of things and this behaviour often results in unwanted outcomes such as automatic rewriting of the page’s title and meta descriptions. This often looks confusing and is not a scenario any website owner would want, so we suggest doing whatever you can yourself and leave as little as possible for Google algorithms to do on their own.
Public Interest, Outcry & Feedback
Now, to move fully and successfully to HTTPS, you may need to work with a trusted partner and typically pay a little extra to get the necessary security. For the companies that are aware of how important the protection of customer data really is, this shouldn’t be a problem as it is only a logical step toward improving their UX. Now, even though a grand majority of companies are not willing to compromise when it comes to security, the issue of the additional costs could pose a justified concern for smaller companies that are only starting out.
To those who brought about this issue on Twitter, John Mueller (Webmaster Trends Analyst at Google) replied with this comment:
“Though perhaps not the most actionable advice to give to a startup owner worried about the costs of shifting to HTTPS, Mueller’s answer implies the value of taking this step.
Namely, security is becoming a growing concern and everyone – from end-users to website owners – needs to work on this in order to create a safer web. After all, compensating on security may turn out to be costlier than getting an SSL certificate if a major data breach occurs. Therefore, SSL represents a long-term data protection strategy and as such should be a focus for webmasters in the following years.”
Though the wider use of HTTPS has numerous (and evident) benefits for the future of the web, certain website owners still see the “imposed” transition as an unnecessary burden and extra cost. Truth be told, a large number of websites do not have data collection forms or checkout pages, so they may not see spending extra to secure web traffic as necessary. For them, getting an SSL certificate is an additional cost and potentially a technical hurdle.
With this in mind, Luanna Spinetti asked influencers for their two cents in order to discover whether there is considerable value in moving to HTTPS. Quite expectedly, the opinions varied with most respondents pointing to the general necessity for improving web security. They still emphasized the fact that it’s up to individuals to determine whether this step would be worthwhile for their own website.
Lukasz Zelezny of zelezny.uk notes:
“Do I think HTTPS is necessary? Not really unless you are asking your website’s visitors for confidential information or taking payments through your site. However, in the future it could mean the difference between a page ranking at number 1 or number 2 in search – this makes it necessary.”
Though it is clear that not all websites currently need it, SSL is a general direction in which the SEO world is moving and is certainly an important thing to consider as it has been an important ranking signal for quite some time now.
A great example of this is The Washington Post which took months to redirect all their pages to their secure versions. In a story of the magazine’s ten-month long transition to HTTPS, Will Van Vazer emphasized all the challenges of the process, in the end deducing that it was all worth it after all.
The Washington Post is a large publication, so the challenges they faced would not be present for smaller websites. In fact, as John Mueller pointed out in relation to this undertaking, this only means that the transition to the HTTPS is not just a buzz, but actually an important step in ensuring the credibility of a website.
“If it takes 10 months for a big site to move to HTTPS, you can assume they’re not just doing it to follow a fad. Moving to HTTPS is getting easier and easier, especially for smaller sites, but even then, there are details that you sometimes have to find solutions for along the way.“
The Introduction & Importance of GDPR
On April 16, 2014, EU Parliament introduced new legislation called General Data Protection Regulation (GDPR) for which the enforcement date started on 25 May 2018. The news hit the major media outlets hard and started causing businesses and management to reconsider their security approaches and procedures in order to avoid facing heavy fines (weird eyes look at Equifax and Tinder).
This relatively new law serves as a much-needed tool that should prevent some of the security breaches mentioned in this article and make the public familiar with them when they do occur among other things. The purpose of this law is to make breached companies responsible in a much stricter way than before, because every company which stores and processes EU citizen private data (pretty much all SaaS brands) is required to acquire a new management staff role, either by direct employment or by using external consultant services.
The Data Protection Officer (DPO) should act as a person in charge of evangelizing data security and privacy best practices company-wide, along with performing security audits on the company’s assets in addition to informing the authorities on issues when they do occur.
The new legislation will force companies to pay special attention to the security and privacy combo as a potentially huge problem these days because failing to disclose and triage breaches will require companies to pay fines of up to 4% of annual global turnover or €20 million (whichever is greater).
This law perfectly covers the discussed SSL/TLS/HTTPS topic, as failure to disclose a data leakage on insecure websites and applications affects the companies in the described way, which is why those companies will probably have to additionally speed up secure protocol adoption, to the ultimate benefit of every Internet user.
HTTPS is a great (despite being the only) method to secure web traffic and provide your visitors with much-needed privacy. This is extremely important now when cybercrimes (such as credit card data and identity theft) are on the rise. However, it is critical to understand that its implementation has to cover more bases than plain certificate installation. It is a multifaceted task with numerous aspects to consider, which – if left unchecked – may affect visitor UX, revenue, brand image and your business as a whole.
Even though setting up SSL on a website is a technical task, it doesn’t necessarily have to be too complex or overly expensive. CloudFlare, for instance, has been providing free certificates to its customers since 2014 in order to encourage wider adoption of HTTPS. This goes to show that all website owners who are seeking easy and inexpensive ways of moving onto HTTPS can do so with minimal research and effort.
Aside from the SEO value these certificates bring, there are numerous other benefits to SSL implementation. Needless to say, getting a certificate for SEO reasons only is not what Google actually tried to encourage, especially not from the website owner standpoint. It should be about providing an excellent user experience as the primary motivation for webmasters to secure their website traffic.
The importance of encryption has become the headline topic only after Google started using it as a ranking signal, even though encryption has had a major role in improving a business’ reputation since before it became one of the search ranking factors. This security practise helps you paint a better picture of your company/website in the eyes of your visitors, which helps in maintaining a stable online reputation.
In the end, you, as a web-services end-user, have some responsibility of your own. If you care about your privacy and security and want to be proactive rather than wait for a security breach to affect you in some terrible way, monitor your private data and their appearance on the web by using services such as Have I Been Pwned. By entering your email address you can check whether the services you’re using suffered a security breach and if your data has been stolen and published. If it has, do change your passwords, especially if you’re one of those who use the same password for multiple services.
Have you moved to HTTPS yet? As a webmaster or business owner, what do you see as the major challenge in this process?
Interested in migrating your website/app to HTTPS to rank and look better on Google?
Interested in migrating your website/app to HTTPS to rank and look better on Google?