What Is HTTPS? A Full Definition

HTTPS stands for HyperText Transfer Protocol Secure. It is the encrypted version of HTTP — the foundational protocol that governs how data is transferred between a web browser and a web server. When a URL begins with https://, it means the connection between your visitor's browser and your server is protected by a cryptographic layer that prevents outsiders from reading, modifying, or injecting data into the communication.

The security layer is provided by TLS (Transport Layer Security), which is the modern successor to the now-deprecated SSL (Secure Sockets Layer) protocol. Although SSL is technically obsolete, the term "SSL certificate" is still used colloquially throughout the industry to refer to the certificate that enables TLS. So when someone says "SSL certificate," they almost always mean a TLS certificate. For the purposes of this guide, the terms SSL and TLS are used interchangeably where common usage demands it, but it is worth knowing that TLS 1.2 and TLS 1.3 are the only versions considered secure today.

Put simply: HTTP transfers data in plain text. HTTPS encrypts that data. Anyone on the same network — a coffee shop Wi-Fi, a corporate router, an Internet Service Provider, or a malicious actor running a man-in-the-middle attack — can read plain HTTP traffic. With HTTPS, they see only scrambled ciphertext that is computationally infeasible to decrypt without the session's private key.

What Is an SSL Certificate?

An SSL certificate (more accurately a TLS certificate) is a digital document issued by a trusted third party called a Certificate Authority (CA). The certificate performs two jobs:

• Authentication — it proves to visiting browsers that your server really is who it claims to be, not an impersonator.
• Key exchange — it carries the public key that the browser uses to begin the encrypted session.

The certificate contains the domain name it was issued to, the name of the CA that issued it, its validity period (usually 90 days to 2 years), and a cryptographic signature that browsers can verify against a pre-installed list of trusted root CAs. Modern operating systems and browsers ship with a built-in trust store containing hundreds of trusted root certificates. If your SSL certificate chains back to one of those roots, visitors get the padlock. If not, they get a frightening browser warning instead.

What Is TLS and How Does the TLS Handshake Work?

TLS (Transport Layer Security) is the cryptographic protocol that actually provides the encryption in HTTPS. Understanding roughly how it works helps you understand why HTTPS is secure and why configuration choices — such as which TLS version you support — matter for both security and performance.

When a browser connects to an HTTPS server, it does not jump straight into sending data. First, it performs a TLS handshake — a short negotiation that agrees on the encryption rules and verifies the server's identity. Here is how that process works in TLS 1.3 (the current standard):

1. ClientHello — The browser sends a message to the server listing the TLS versions it supports, the cipher suites it can use, and a random value called a "client random."
2. ServerHello — The server replies with its chosen TLS version and cipher suite, its own random value ("server random"), and its SSL certificate (containing the public key).
3. Certificate verification — The browser checks the certificate against its trust store. It verifies the CA's signature, confirms the domain name matches, and checks that the certificate has not expired or been revoked.
4. Key exchange — Using the public key in the certificate (and an algorithm such as ECDHE), both sides independently derive the same shared secret without ever transmitting it over the network. This is the magic of asymmetric cryptography.
5. Session keys derived — Both sides use the shared secret and the two random values to derive symmetric session keys.
6. Finished messages — Both sides send an encrypted "Finished" message to confirm the handshake succeeded. All subsequent data is encrypted with the symmetric session keys.

TLS 1.3 (released 2018) reduced the handshake to a single round trip (1-RTT), and in some configurations zero round trips for sessions that are being resumed (0-RTT). This is measurably faster than the 2-RTT handshake in TLS 1.2. It also removed several weak cipher suites and legacy features that contributed to past vulnerabilities like POODLE, BEAST, and FREAK. If your server still supports TLS 1.0 or TLS 1.1, those versions should be disabled immediately — they are deprecated by all major browsers and considered insecure.

HTTPS vs HTTP: Full Comparison

The differences between HTTP and HTTPS extend well beyond security. The table below covers every dimension that matters to a website owner or SEO professional.

One point worth expanding: the referral data issue. When a user clicks a link on an HTTPS page and lands on an HTTP page, the Referer header is stripped by browsers for security reasons. In Google Analytics, that traffic appears as "direct" rather than as a referral. This means HTTP site owners consistently undercount referral traffic, making their data unreliable. HTTPS-to-HTTPS referral data passes through correctly.

Why HTTPS Matters for SEO

HTTPS has been an explicit Google ranking signal since August 2014, when Google announced it in a post on the Webmaster Central Blog. At launch it was described as a "lightweight" signal affecting fewer than 1% of queries. Over subsequent years Google gradually increased its weighting, and in 2018 Chrome began actively marking all HTTP pages as "Not Secure" in the address bar rather than just flagging pages with forms. Understanding the full SEO impact of HTTPS requires looking at several distinct mechanisms.

Direct Ranking Signal

HTTPS is a confirmed direct ranking factor. In genuinely close competitive situations — where content quality, backlink profiles, and other signals are roughly equal — HTTPS can be the tiebreaker. For most sites, the direct ranking benefit is modest, but it is real and costs nothing to capture given the availability of free certificates.

User Trust and Bounce Rate

Chrome, Firefox, Edge, and Safari all display "Not Secure" warnings on HTTP pages. Users have become increasingly aware of what this means. Studies consistently show that a significant portion of users abandon a page or form when they see the "Not Secure" label — with e-commerce checkout pages seeing especially sharp drop-offs. Higher bounce rates are a negative quality signal, and lower conversion rates are a direct business cost that dwarfs any certificate cost. If your site relies on any form submission, account registration, or purchase flow, remaining on HTTP is commercially unjustifiable.

Browser Warnings and Crawl Impact

Google's crawler (Googlebot) can and does crawl both HTTP and HTTPS. However, Google has stated its preference for HTTPS URLs in its own index. When Google encounters both HTTP and HTTPS versions of the same page without a proper redirect, it must decide which version to index. Without a clear signal — such as a canonical tag pointing to HTTPS, or a 301 redirect — Google may index the wrong version, split your link equity between the two versions, or flag the discrepancy as a coverage issue in Search Console.

Referral Data Accuracy

As described in the comparison table, clicking from an HTTPS page to an HTTP page strips the Referer header. If your site is on HTTP, any link from an HTTPS site — which is the vast majority of the web today — arrives in your analytics as "direct" traffic. This corrupts your attribution data, making it impossible to accurately measure which channels are performing. Once you migrate to HTTPS, you will often see "direct" traffic decrease and referral traffic increase as the data corrects itself. This is not traffic loss — it is attribution accuracy finally returning.

Page Speed and HTTP/2

Page speed is a ranking factor, and HTTPS is a prerequisite for HTTP/2 in all major browsers. HTTP/2 allows a single connection to carry multiple requests simultaneously (multiplexing), compresses HTTP headers, and supports server push. These features can substantially reduce page load times, particularly for pages that load many small resources. HTTP/3 (built on QUIC) takes this further with improved performance on lossy networks. Both HTTP/2 and HTTP/3 require HTTPS to function in browsers. So migrating to HTTPS is not just a security upgrade — it is also the gateway to the performance improvements that improve Core Web Vitals scores and, by extension, rankings.

Types of SSL Certificates

Not all SSL certificates are equal. They differ in three dimensions: the level of validation performed by the CA before issuing, what the certificate covers in terms of domains, and how they are trusted by browsers. Here is what you need to know.

By Validation Level

Domain Validation (DV) certificates are the most common. The CA simply verifies that you control the domain — usually by you placing a file on the server or adding a DNS record. No information about your organisation is verified. For SEO and security purposes, a DV certificate is sufficient for the vast majority of websites. Let's Encrypt issues only DV certificates, and they are trusted by all major browsers.

Organisation Validation (OV) certificates require the CA to verify your organisation's legal identity, address, and phone number. This information is embedded in the certificate and can be inspected by users, though it is not prominently displayed in most browsers. OV offers a modest additional trust signal for business sites.

Extended Validation (EV) certificates historically displayed a green address bar with the organisation's legal name in Chrome and other browsers. However, Chrome removed the green EV indicator in 2019, arguing that research showed users did not meaningfully understand or use it. Today, EV certificates still receive thorough vetting and may be appropriate for high-assurance contexts like banking, but they provide no visible SEO or browser-display advantage over DV certificates in Chrome.

By Coverage Scope

• Single-domain certificate — covers one specific domain (e.g. www.example.com). Does not cover the apex (example.com) or any subdomain unless explicitly included.
• Multi-domain (SAN) certificate — covers multiple distinct domains listed in the Subject Alternative Name (SAN) field. Useful for businesses that run several domains on the same server.
• Wildcard certificate — covers a domain and all its first-level subdomains (e.g. *.example.com covers blog.example.com, shop.example.com, etc.). It does not cover the apex domain or second-level subdomains without combining with a SAN.

How to Get an SSL Certificate

The barrier to obtaining an SSL certificate has fallen to essentially zero for most websites. Here are the main routes.

Let's Encrypt (Free, Automated)

Let's Encrypt is a non-profit CA operated by the Internet Security Research Group (ISRG) and backed by organisations including Mozilla, Google, Cisco, and the EFF. It issues free, automated DV certificates that are trusted by all major browsers and operating systems. Certificates are valid for 90 days and are typically renewed automatically by an ACME client (the most common being Certbot). The short validity period is intentional — it limits the damage from a compromised private key and encourages full automation of the renewal process. For most websites, Let's Encrypt is the right choice. It is free, widely supported, and has issued billions of certificates since its launch in 2015.

Hosting Provider Integration

Most modern hosting providers (cPanel hosts, managed WordPress hosts, cloud platforms) offer one-click SSL installation, often powered by Let's Encrypt or their own CA. Providers like Cloudflare also offer SSL/TLS as part of their proxy service, which can be configured with flexible, full, or full-strict modes. If you are on a managed platform, check your hosting control panel first — there may be no manual steps required at all.

Commercial Certificate Authorities

Commercial CAs such as DigiCert, Sectigo (formerly Comodo), GlobalSign, and Entrust issue certificates ranging from basic DV to EV. These are typically purchased when you need OV or EV validation, wildcard coverage across many subdomains, extended warranty coverage, or dedicated support. For straight SEO and website security purposes, commercial certificates offer no ranking advantage over a free Let's Encrypt certificate.

How to Migrate from HTTP to HTTPS: Step-by-Step

A migration from HTTP to HTTPS is one of the highest-impact technical SEO tasks you can complete. Done correctly, it is seamless. Done carelessly, it can temporarily disrupt rankings, fragment your link equity, and introduce mixed content errors. Follow these steps to do it right.

Step 1: Back Up Your Website

Before making any changes, take a full backup of your site files and database. If anything goes wrong, you need a reliable restore point.

Step 2: Obtain and Install Your SSL Certificate

Follow your hosting provider's instructions to install a certificate. Most cPanel-based hosts have an "SSL/TLS" section with automatic installation via Let's Encrypt. Verify the installation is complete before making any changes to redirects or links. You can use the HTTPS checker to confirm the certificate is live and valid.

Step 3: Update Internal Links and Resources

Before enabling redirects, update your CMS settings, internal links, image sources, script sources, and stylesheet references to use HTTPS URLs where possible. In WordPress, update the Site URL and Home URL in Settings to https://. This prevents mixed content errors (see below) from appearing after the migration.

Step 4: Update Your Canonical Tags

Every page on your site should have a canonical tag pointing to the HTTPS version of that page. If your CMS generates canonicals dynamically, updating the site URL setting is usually sufficient. If canonicals are hard-coded, you will need to update them individually.

Step 5: Implement 301 Redirects from HTTP to HTTPS

Set up server-level 301 (permanent) redirects from every HTTP URL to its HTTPS equivalent. The most common approach is an .htaccess rule for Apache servers:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

For Nginx, a typical redirect looks like this:

server { listen 80; server_name example.com www.example.com; return 301 https://$host$request_uri; }

Use the redirect checker to verify that every HTTP URL correctly redirects to the HTTPS version with a 301 status code, and that there are no redirect chains (e.g. HTTP → HTTPS → www.HTTPS, which adds an unnecessary hop).

Step 6: Update Your XML Sitemap

Regenerate or manually update your XML sitemap so that all URLs use the https:// scheme. Submit the updated sitemap to Google Search Console. This signals to Google which URLs you want indexed and helps accelerate re-crawling of the HTTPS versions.

Step 7: Update Google Search Console and Analytics

HTTPS is treated as a separate property from HTTP in Google Search Console. Add and verify your HTTPS property, then set it as the primary. Update your Google Analytics property's default URL to HTTPS. If using Universal Analytics cross-domain linking or referral exclusions, update those settings too.

Step 8: Update External Links Where Possible

While 301 redirects will pass most of the link equity from HTTP to HTTPS, a direct HTTPS link is cleaner. Update any links you control — social profiles, directory listings, Google Business Profile, partner sites — to point directly to the HTTPS URL. This avoids a redirect hop and ensures link equity transfer is as efficient as possible.

Step 9: Monitor and Audit After Launch

In the days and weeks after migration, monitor Google Search Console for coverage errors, indexing issues, and any drop in impressions or clicks that might indicate a configuration problem. Run a full site audit to catch any remaining HTTP references, mixed content issues, or broken redirects.

Mixed Content Issues

Mixed content is one of the most common problems encountered after migrating to HTTPS. It occurs when an HTTPS page loads some resources — images, scripts, stylesheets, iframes, fonts, or media files — over HTTP rather than HTTPS. This partially undermines the security of the page and triggers warnings in browsers.

There are two categories of mixed content:

• Passive mixed content — HTTP images, audio, or video embedded in an HTTPS page. Browsers may load these with a warning but will not block them by default in most configurations. They result in a "mixed content" warning in the browser console.
• Active mixed content — HTTP scripts, stylesheets, iframes, or XHR requests on an HTTPS page. Browsers block these entirely because a malicious script loaded over HTTP could compromise the entire page. This can break page functionality visibly.

To find and fix mixed content issues:

1. Open Chrome DevTools (F12), go to the Console tab, and look for mixed content warnings on your pages.
2. Use a crawler or the RankNibbler site audit to scan for HTTP resource references across all pages at once.
3. Update all internal resource URLs to use HTTPS or protocol-relative URLs (//example.com/resource.js).
4. For third-party resources that do not offer HTTPS, consider self-hosting the asset or replacing the provider.
5. After fixing, add a Content-Security-Policy header or a upgrade-insecure-requests directive as a safety net to force any remaining HTTP requests to upgrade automatically.

In WordPress, the "Better Search Replace" plugin or the built-in Site Health tool can help bulk-update HTTP references stored in the database. In other CMSes, a database search-and-replace on the HTTP URL is usually the most efficient approach.

HSTS: HTTP Strict Transport Security

Once your site is fully on HTTPS with all mixed content resolved, you should consider enabling HSTS (HTTP Strict Transport Security). HSTS is an HTTP response header that instructs browsers to only connect to your site over HTTPS — never plain HTTP — for a specified duration. Even if a user types http://example.com into the address bar, the browser automatically upgrades the request to HTTPS without making a network connection on port 80 at all.

A basic HSTS header looks like this:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• max-age=31536000 — instructs the browser to enforce HTTPS for 31,536,000 seconds (one year).
• includeSubDomains — applies the policy to all subdomains as well.
• preload — opts the domain into the HSTS preload list (see below).

The HSTS preload list is a hardcoded list of domains shipped directly in browsers (Chrome, Firefox, Safari, Edge) that will only ever be contacted over HTTPS, even on the very first visit — before the browser has ever received an HSTS header from the server. To submit your domain, visit hstspreload.org. Prerequisites are: HTTPS must be enabled on the root domain, an HSTS header must be served with a max-age of at least 31,536,000 seconds, includeSubDomains must be set, and all subdomains must be functional over HTTPS.

Warning: HSTS is very difficult to undo. If you set a long max-age and then need to move back to HTTP for any reason, browsers that have cached the HSTS policy will refuse to connect. Start with a short max-age (e.g. 300 seconds) during testing, and only increase it once you are confident everything works correctly.

HTTPS, HTTP/2, and Page Speed

One of the most compelling practical reasons to migrate to HTTPS beyond security and SEO is that it is the gateway to HTTP/2, and subsequently HTTP/3. Browsers only implement HTTP/2 over TLS, meaning plain HTTP connections are permanently capped at HTTP/1.1 performance.

HTTP/1.1 has a fundamental limitation: each request-response cycle blocks the connection until the previous one completes (head-of-line blocking). Browsers work around this by opening multiple parallel connections (typically 6 per hostname), but this is wasteful and has limits. HTTP/2 addresses this with:

• Multiplexing — multiple requests and responses are interleaved over a single connection, eliminating head-of-line blocking at the HTTP layer.
• Header compression (HPACK) — HTTP headers, which can be repetitive across requests, are compressed, reducing overhead.
• Server push — the server can proactively send resources the client will need before it has asked for them, though this feature is now largely superseded by preload hints.
• Stream prioritisation — critical resources can be assigned higher priority for delivery.

HTTP/3 (based on QUIC, which runs over UDP rather than TCP) takes performance further with improved handling of packet loss and faster connection establishment. It is supported by modern servers and browsers and again requires HTTPS. Check whether your server or CDN supports HTTP/3 and enable it once you have HTTPS in place.

Page speed is a direct ranking factor through Google's Core Web Vitals (Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint). HTTP/2 improvements to loading performance can measurably improve LCP in particular. The compounding effect of HTTPS (direct ranking signal) + HTTP/2 (faster loading) + trust signals (lower bounce rate) makes the migration ROI significant even for sites that already have good content.

Common HTTPS Mistakes to Avoid

Even experienced developers make mistakes during HTTPS migrations. Here are the most common errors and how to avoid them.

1. Redirect Chains

A redirect chain occurs when a URL redirects through multiple steps before reaching the final destination — for example, http://example.com → http://www.example.com → https://www.example.com. Each hop adds latency and dilutes link equity. The goal is a single 301 from any HTTP variant to the canonical HTTPS URL. Use the redirect checker to map every hop in your redirect paths.

2. Mixed Canonical and Redirect Signals

A frequent mistake is having 301 redirects from HTTP to HTTPS but still serving canonical tags pointing to http://. Google will encounter conflicting signals: the redirect says "use HTTPS," but the canonical says "the canonical URL is HTTP." Always ensure your canonical tags, redirects, and sitemap all point to the same HTTPS URL.

3. Certificate Covering the Wrong Domain

A certificate issued to www.example.com does not automatically cover example.com. Ensure your certificate covers both the apex domain and the www subdomain, either with a SAN entry or a wildcard. Use the HTTPS checker to confirm the certificate is valid for the exact domain you are testing.

4. Expired Certificates

An expired SSL certificate results in a full-page browser warning that is more alarming than the "Not Secure" label — users see a red warning screen and must actively choose to proceed. Automate certificate renewal with Certbot or your hosting provider's renewal system, and set up monitoring to alert you if a certificate is approaching expiry.

5. Leaving HTTP Resources in the Codebase

Hardcoded HTTP URLs in templates, stylesheets, scripts, and database content are a common source of mixed content errors after migration. Do a thorough search-and-replace across your codebase and database before going live. Tools like RankNibbler's site audit can help identify remaining HTTP references post-migration.

6. Not Updating Disavow Files and Third-Party Profiles

If you have an active disavow file in Search Console, the HTTP and HTTPS URLs are treated as different properties. Review your disavow file to ensure it does not inadvertently include HTTPS URLs you want to be credited. Also update your Google Business Profile, social media bios, and any structured data markup to use HTTPS URLs.

7. Forgetting Subdomains

If your main domain migrates to HTTPS but subdomains like blog.example.com, shop.example.com, or m.example.com remain on HTTP, they will show "Not Secure" warnings and may have mixed content issues when they embed resources from the main domain. Plan the migration to cover all subdomains, not just the root.

How to Test Your HTTPS Configuration

After completing your migration, use these tools and methods to verify that everything is working correctly.

• RankNibbler HTTPS checker — verifies that a given URL resolves over HTTPS and returns the correct status code.
• RankNibbler redirect checker — traces the full redirect path from HTTP to HTTPS, showing every status code and URL along the way.
• RankNibbler site audit — crawls your site and flags HTTP resources, mixed content issues, and misconfigured canonicals.
• SSL Labs (ssllabs.com/ssltest) — the industry-standard free tool for grading your SSL/TLS configuration. It checks certificate validity, supported TLS versions, cipher suites, HSTS configuration, and a host of other parameters. Aim for an A or A+ grade.
• Chrome DevTools Console — open any page, press F12, and review the Console for mixed content warnings. The Security tab shows the certificate details and any security issues for the current page.
• Google Search Console — monitor the Coverage report for indexing errors after migration, and the URL Inspection tool to see how Google last crawled specific pages.

HTTPS and the SEO Glossary

HTTPS intersects with several other core technical SEO concepts. The RankNibbler SEO glossary covers all of these in depth, but here is a quick summary of the connections:

• Canonical tags — must point to HTTPS URLs; a mismatch between canonical and redirect signals confuses Google's canonicalisation logic.
• 301 redirects — the mechanism used to move authority and traffic from HTTP to HTTPS; a 301 redirect passes approximately 99% of link equity according to current Google guidance.
• XML sitemaps — should contain only HTTPS URLs once the migration is complete.
• Structured data — schema markup that references http:// URLs after migration may cause mismatches with the crawled page URL; update all url and @id fields.
• Robots.txt — the robots.txt file at https://example.com/robots.txt is a separate resource from http://example.com/robots.txt; ensure the HTTPS version is properly configured.

Frequently Asked Questions About HTTPS and SSL

Does HTTPS directly improve my Google rankings?

Yes, but modestly on its own. Google confirmed HTTPS as a ranking signal in 2014. Its direct effect is relatively small compared to content quality, E-E-A-T signals, and backlinks. However, the indirect effects — lower bounce rates due to reduced "Not Secure" warnings, faster load times via HTTP/2, and preserved referral data — can have a meaningful cumulative impact on performance.

Is SSL the same as TLS?

Not technically. SSL (Secure Sockets Layer) is the older protocol; TLS (Transport Layer Security) is its modern replacement. SSL 2.0, SSL 3.0, and TLS 1.0 are all deprecated and insecure. Modern HTTPS uses TLS 1.2 or TLS 1.3. The term "SSL certificate" persists in common usage because SSL was the original name, but every certificate installed today uses TLS for the actual encryption.

Does a free Let's Encrypt certificate affect SEO compared to a paid one?

No. Google and other search engines do not differentiate between free and paid certificates, or between DV, OV, and EV certificates, for ranking purposes. A Let's Encrypt DV certificate provides the same HTTPS ranking signal and the same padlock as a $500 EV certificate from DigiCert.

Will migrating to HTTPS cause a rankings drop?

A well-executed migration with proper 301 redirects, updated canonicals, and a resubmitted sitemap should not cause a lasting rankings drop. Some sites see a brief dip in the days immediately after migration as Google re-crawls and re-indexes pages, but this typically resolves within days to a few weeks. A poorly executed migration — missing redirects, duplicate content between HTTP and HTTPS, mixed canonical signals — can cause longer disruption.

My site already has HTTPS. Do I need to do anything else?

Check the following: (1) Are all HTTP URLs properly redirecting to HTTPS with a 301? Use the redirect checker to verify. (2) Are your canonical tags pointing to HTTPS? (3) Is there any mixed content? Check in Chrome DevTools. (4) Is HSTS configured? (5) Is your TLS configuration up to date — TLS 1.0 and 1.1 should be disabled. (6) Are your certificates set to auto-renew?

What is a wildcard SSL certificate?

A wildcard certificate covers a domain and all of its first-level subdomains. For example, a wildcard certificate for *.example.com covers blog.example.com, shop.example.com, api.example.com, and any other first-level subdomain, but not example.com itself (unless it is also listed as a SAN) or second-level subdomains like dev.blog.example.com.

Does HTTPS slow down my website?

The TLS handshake adds a small amount of latency on the initial connection — typically 1 round trip in TLS 1.3 (compared to 2 in TLS 1.2). However, this overhead is more than compensated for by the ability to use HTTP/2, which dramatically reduces the number of round trips required to load a full page. In practice, HTTPS sites with HTTP/2 enabled are typically faster than equivalent HTTP/1.1 sites, not slower.

What happens if my SSL certificate expires?

If your certificate expires, visitors see a full-page browser error warning (typically "Your connection is not private" in Chrome with error code NET::ERR_CERT_DATE_INVALID). Most browsers block access by default until the user explicitly overrides the warning. This will immediately impact traffic, conversions, and user trust. Set up automated renewal and expiry monitoring to ensure this never happens.

Can HTTP/2 work without HTTPS?

Technically, the HTTP/2 specification (RFC 7540) does not require TLS. However, all major browsers have decided to only implement HTTP/2 over TLS in practice. So for any real-world website, HTTP/2 requires HTTPS.

Does HTTPS protect against all cyber threats?

No. HTTPS protects data in transit between the browser and server. It does not protect against attacks on the server itself (e.g. SQL injection, XSS), weak passwords, insecure server configurations, or data breaches from within the organisation. It also does not hide which domain you are connecting to (that information is visible in the SNI field of the TLS handshake). HTTPS is a critical baseline security measure, not a comprehensive security strategy.

What is certificate transparency?

Certificate Transparency (CT) is a public logging system that requires all publicly trusted CAs to log every certificate they issue to public, append-only logs. This allows anyone to monitor which certificates have been issued for a domain, making it possible to detect certificates that were mis-issued fraudulently. Chrome requires CT compliance for all publicly trusted certificates. You can monitor certificates issued for your domains using tools like crt.sh.

What is SNI (Server Name Indication)?

SNI is a TLS extension that allows a server to host SSL certificates for multiple domains on the same IP address. Before SNI, each domain required a dedicated IP address to have its own certificate. SNI solves this by including the domain name in the initial TLS ClientHello message, so the server knows which certificate to present before the connection is established. All modern browsers and servers support SNI.

Last updated: April 2026