Always-On SSL (AOSSL): What It Is and How to Enable It Properly

Always-On SSL (AOSSL) means running HTTPS on every page of your website, not just pages that handle sensitive data. Until around 2015, many sites served only their login, checkout, and account pages over HTTPS while the rest of the site ran on plain HTTP. AOSSL is the practice of eliminating all plain HTTP pages so that every URL on the site (the home page, blog posts, contact forms, static images) uses HTTPS.

AOSSL alone is necessary but not sufficient for the strongest HTTPS security. A site that uses HTTPS on all pages but does not send the HTTP Strict Transport Security (HSTS) header is still vulnerable to a specific attack called SSL stripping. A site that sends HSTS but is not on the HSTS preload list is still vulnerable on a user’s very first visit. Full implementation of AOSSL involves three distinct layers, and each layer addresses a different attack that the previous layer cannot stop.

Why a Simple HTTP-to-HTTPS Redirect Is Not Enough

The problem with relying only on an HTTP-to-HTTPS redirect is that the redirect itself happens over HTTP. Consider what happens when a user types example.com in their browser: the browser first sends an HTTP request to example.com. The server responds with a 301 redirect to https://example.com. The browser follows the redirect over HTTPS.

An attacker performing a man-in-the-middle attack can intercept that first HTTP request before it reaches the server. The attacker, positioned on the same network (a coffee shop Wi-Fi, a corporate LAN, or a maliciously operated access point), intercepts the HTTP request, makes their own HTTPS connection to example.com, and presents a stripped-down HTTP version to the victim. The victim’s browser never reaches HTTPS because the redirect happened on the attacker’s connection, not the victim’s.

This attack was demonstrated by Moxie Marlinspike at Black Hat 2009 with a tool called sslstrip. The attack remains effective against sites that rely solely on HTTP-to-HTTPS redirects without HSTS. The victim’s browser shows no padlock, their credentials and session cookies travel over plain HTTP, and they have no indication anything is wrong.

HTTP Strict Transport Security (HSTS) solves the SSL stripping problem because it moves the upgrade decision from the server to the browser. Once a browser has received the HSTS header from a server, it internally records that the domain must use HTTPS. On all subsequent visits, the browser upgrades the request to HTTPS before sending it: before any HTTP request leaves the machine, before any attacker can intercept it. The server never receives an HTTP request because the browser never sends one.

The Three Layers of Full AOSSL Implementation

Layer 1: HTTPS on Every Page With a 301 Redirect

The prerequisite for everything else: a valid SSL certificate installed, all pages accessible over HTTPS, and a server-side 301 redirect from all HTTP URLs to their HTTPS equivalents.

A 301 redirect (permanent redirect) tells browsers and search engines that the HTTP URL has moved permanently to HTTPS. Using a 302 (temporary) redirect is a common mistake that allows search engines to continue indexing the HTTP URL. Use 301.

The redirect must cover the bare domain as well as www. If https://example.com and https://www.example.com both work, both http://example.com and http://www.example.com should redirect to the canonical HTTPS version. Ensure the certificate covers both variants.

After setting up the redirect, test by typing http://example.com in a browser and confirming it redirects to https://example.com with no SSL errors. Also verify https://example.com loads without any mixed content warnings (padlock without any triangles or warnings in the address bar).

Layer 2: HSTS and the Strict-Transport-Security Header

HSTS is implemented by adding the Strict-Transport-Security response header to your HTTPS server responses. The header tells the browser how long to remember the HTTPS-only policy and whether it applies to subdomains.

The HSTS header has three components. The max-age directive specifies how many seconds the browser should remember the policy. A value of 31536000 is one year; this is the commonly recommended value. The includeSubDomains directive extends the policy to all subdomains: any subdomain of your domain will also be forced to HTTPS. The preload directive signals that the domain is willing to be added to the HSTS preload list built into browsers.

The full recommended HSTS header value when you are ready for preloading looks like: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Before adding includeSubDomains, confirm that every subdomain of your domain is accessible over HTTPS. If any subdomain (including internal ones, staging environments, or legacy subdomains) is HTTP-only, adding includeSubDomains will break it. Browsers will refuse HTTP connections to any subdomain covered by the includeSubDomains policy, and users cannot click through the error. This is a more severe failure mode than a certificate error.

Enabling HSTS in Nginx

Add the HSTS header inside the server block that handles HTTPS (port 443). Do not add it to the HTTP server block, because HSTS headers are only meaningful over HTTPS connections. Browsers ignore HSTS headers received over HTTP. The directive in Nginx is: add_header Strict-Transport-Security ‘max-age=31536000; includeSubDomains; preload’ always; where the always parameter ensures the header is sent on all responses including error pages. Reload Nginx after making the change.

Enabling HSTS in Apache

Ensure mod_headers is loaded (a2enmod headers on Debian/Ubuntu). In the VirtualHost block for port 443, add: Header always set Strict-Transport-Security ‘max-age=31536000; includeSubDomains; preload’. Do not add this header in the HTTP virtual host. Restart Apache after adding it.

Enabling HSTS via .htaccess (shared hosting)

In the .htaccess file in your web root (for HTTPS sites where you do not have direct Apache VirtualHost access), add the HSTS header inside an IfModule condition for mod_headers. The .htaccess approach sets the header for HTTPS requests. Confirm with a browser developer tools Network tab that the Strict-Transport-Security header appears in the response headers. The shared hosting platform must have mod_headers enabled; most do by default.

Enabling HSTS in Cloudflare

Cloudflare users can enable HSTS directly in the Cloudflare dashboard without any server changes. Go to SSL/TLS, then Edge Certificates. Scroll to HTTP Strict Transport Security (HSTS) and click Enable HSTS. The wizard walks through the settings: enable, set max-age (one year is recommended), optionally enable includeSubDomains and preload. Cloudflare applies the setting to all requests through its edge.

For sites running applications behind Cloudflare (including WordPress), managing HSTS at the Cloudflare edge rather than in the application is recommended. Setting HSTS in the application (via a plugin or application framework’s HSTS middleware) when TLS terminates at Cloudflare can create redirect loops because the application sees HTTP internally.

HSTS Risks: What Can Go Wrong

HSTS is a commitment. Once deployed with a long max-age, browsers remember it for the duration. Misconfiguring HSTS or removing it at the wrong time creates failure modes more severe than a missing SSL certificate.

Certificate expiry while HSTS is active

If your SSL certificate expires while HSTS is active with a long max-age, browsers that have cached the HSTS policy cannot access the site at all. A normal expired certificate allows users to click through (accepting the risk). An expired certificate on an HSTS domain shows an error with no click-through option: the HSTS policy prevents any access until the certificate is valid again. The site is completely inaccessible to browsers that have cached the HSTS policy.

This is why automated certificate renewal is not optional for HSTS-enabled sites. Set up external certificate expiry monitoring in addition to automated renewal. The combination of HSTS and manual-renewal-only is a high-risk configuration.

Removing HSTS or removing HTTPS

If you need to move a site from HTTPS back to HTTP (for any reason), you cannot simply remove the certificate. Browsers that have cached the HSTS policy will continue trying HTTPS even after the server stops responding to it. The only safe way to remove HTTPS while HSTS is active is to first set the max-age to 0 (which instructs browsers to delete the HSTS policy), wait for the current max-age period to expire for all users, and only then remove HTTPS. The Cloudflare dashboard requires setting max-age to 0 before removing HSTS; other servers require adding an interim header with max-age=0.

Testing before setting a long max-age

Start with a short max-age for testing: Strict-Transport-Security: max-age=300 (five minutes). Verify everything works correctly. Check all pages load over HTTPS without errors. Verify subdomains (if using includeSubDomains). Test the HTTP-to-HTTPS redirect. Once verified, increase to max-age=86400 (one day), then max-age=604800 (one week), and finally max-age=31536000 (one year). This graduated approach limits the blast radius if something goes wrong.

Layer 3: HSTS Preloading

The HSTS preload list is a list of domains maintained by Google (at hstspreload.org) and distributed to browser vendors. Chrome, Firefox, Edge, Safari, and others ship with this list embedded. When a browser that has never visited your site before opens it, it checks the preload list and enforces HTTPS from the very first request without waiting to receive an HSTS header.

Preloading is the only way to protect the very first visit. Without preloading, the first time a user visits your site, their browser has no cached HSTS policy and must make an HTTP connection first (which then redirects to HTTPS). An attacker can SSL-strip that first request.

Requirements for HSTS preloading

• Valid SSL certificate with no errors
• All HTTP traffic redirected to HTTPS
• HSTS header present with max-age of at least 31536000 (one year)
• includeSubDomains directive present in the HSTS header
• preload directive present in the HSTS header
• All subdomains accessible over HTTPS (required by includeSubDomains)

How to submit for preloading

Visit hstspreload.org, enter your domain, and the site checks whether your current HSTS configuration meets the requirements. If it does, submit. The typical processing time is a few weeks. Updates to the Chrome list are deployed with Chrome releases; other browsers update their copies on their own schedules. Most major browser preload lists update within a few weeks to months after hstspreload.org accepts the submission.

HSTS preloading is difficult to undo. Once your domain is on the preload list and distributed in browser releases, all browsers with that release enforce HTTPS for your domain regardless of what your server sends. Removal requests are accepted at hstspreload.org but take months to propagate as browser releases update. Only submit for preloading if you are confident your site will permanently run on HTTPS. The preload commitment is effectively permanent on a human operational timescale.

Verifying Your AOSSL Implementation

After implementing all three layers, verify the configuration from an external perspective:

• SSL Labs test (ssllabs.com/ssltest): Shows the certificate validity, HSTS header presence and configuration, and preload status in the Protocol Details section. A correct HSTS header shows as present with the max-age value. Preload readiness is indicated.
• Security Headers (securityheaders.com): Scans your site for HTTP security headers including HSTS. Gives a letter grade and shows the exact header values received.
• Browser developer tools: Press F12, go to the Network tab, reload the page, click the first request (your domain), and look in the Response Headers section for Strict-Transport-Security. Confirm the value matches what you configured.
• HTTP URL test: Type http://yourdomain.com in the browser address bar. It should redirect to https://yourdomain.com with no errors. The browser address bar should show https:// after the redirect completes.
• org: Enter your domain to check whether it is on the preload list and whether your current configuration meets preload requirements.

Frequently Asked Questions

What is Always-On SSL (AOSSL)?

Always-On SSL means implementing HTTPS on every page of a website rather than only on sensitive pages like login or checkout. Full AOSSL implementation involves three layers: HTTPS for all pages with HTTP-to-HTTPS redirects, an HTTP Strict Transport Security (HSTS) header that instructs browsers to always use HTTPS without sending HTTP requests, and ideally HSTS preloading so browsers enforce HTTPS even on the first visit before any header is received. Each layer addresses a different attack that the previous layer cannot stop.

What is HSTS and why is it needed if I already redirect HTTP to HTTPS?

HTTP to HTTPS redirects happen server-side, which means the browser must first send an HTTP request that the server then redirects. An attacker performing SSL stripping can intercept that initial HTTP request before it reaches the server and serve the user a downgraded HTTP version of the site. HSTS prevents this by making the browser remember that the domain must use HTTPS. After the browser receives the HSTS header once, it upgrades all future requests to HTTPS internally, before sending any HTTP request. The attacker never sees the HTTP request because the browser never sends one.

What happens if my certificate expires while HSTS is active?

Browsers that have cached the HSTS policy for your domain cannot access the site at all while the certificate is expired. Normal certificate errors allow users to click through; HSTS prevents click-through because the HSTS policy requires a valid certificate. The site is inaccessible to those browsers until the certificate is renewed and valid again. This is why automated certificate renewal is essential for HSTS-enabled sites. A lapsed certificate on an HSTS site is more disruptive than a lapsed certificate on a non-HSTS site.

Does AOSSL and HSTS affect SEO?

Yes, positively. Google has used HTTPS as a ranking signal since 2014. Sites that run fully on HTTPS with proper 301 redirects from HTTP URLs pass link equity and ranking signals correctly from the HTTP to HTTPS version. HSTS itself has a minor indirect SEO benefit: it eliminates the HTTP request and redirect on repeat visits, slightly improving page load time for users who have previously visited. For indexing purposes, ensure Google Search Console has the HTTPS version of your site as the primary property.