How to Make HTTPS the First Request Through a VPN

A browser that types http:// first and lands on https:// after a redirect has already sent one request in the clear, and a VPN does not change that. The tunnel protects the leg from the client to the exit node; it does not encrypt anything above the transport layer, so an observer between the exit and the origin still sees the plaintext hop. Making HTTPS the first request is a client-side change with three parts: a real HTTPS address, the browser's upgrade mode, and the site's own policy. The steps below are the order I use, each with the check that tells you whether it took.

Step 1: confirm what the first request actually is

Before changing anything, look at what the browser sends. Open the network panel with the page reloaded from a cold cache and read the first row: if the scheme is http and the status is 301 or 308, everything after that row is a second request. curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' http://example.com reproduces the same sequence outside the browser and prints the URL you ended up on.

Two outcomes are possible and they need different fixes. If the site serves HTTPS on the same host, the fix is to stop publishing the HTTP form: update the bookmark, the wiki link, the desktop shortcut and the email template people click. If the site does not serve HTTPS at all, no browser setting will create it, and the honest answer is that the destination is the problem. Do not paper over the second case with an exception, because a certificate exception on an account page converts a transport problem into a credential problem. Write down which case you are in before you touch a setting.

Step 2: turn on the browser's HTTPS-only mode

The upgrade mode is the second part, and the modes are not interchangeable. Check what yours does before you enable it: upgrade silently, upgrade with a warning, or refuse to load.

In Firefox the controls live behind about:config and in the privacy settings page, with dom.security.https_only_mode as the switch and per-site exceptions managed from the padlock menu. In Chrome and Edge the same idea sits under Settings, Privacy and security, Security, labelled Always use secure connections. Whatever the label, verify the behaviour against a host that only answers on port 80, because a mode that upgrades and then silently falls back is not the protection you think you enabled. The Firefox HTTPS-Only documentation spells out the upgrade, warning and exception behaviour for that browser.

Step 3: fix the resources, not just the address bar

When an upgrade fails, read the exact error instead of the address bar. A host with no HTTPS listener, a hostname that does not match the certificate and an expired chain produce different messages and belong to different owners. Only the first is a server-side gap; the second is usually a bookmark that was never updated; the third is a renewal problem that the VPN connection is irrelevant to.

Do not add a certificate exception to an account site because the VPN is on. The exception disables the check that would have caught exactly the interception a VPN is meant to prevent.

The third part is inside the page, and it is the one people miss. A page that loads over HTTPS can still pull images, fonts or scripts from an http URL, and the browser will either block them or downgrade the security indicator for the whole page. Inspect the failed requests in the network panel and fix the resource references at their owner rather than assuming the address bar describes every request. On a site you run, that means correcting the stored URLs in the CMS or the template instead of rewriting them in the browser. If you cannot change the source, record the mixed content as a known gap, because a padlock over a page that pulls plaintext resources is a false signal.

Step 4: what HSTS adds, and what it does not

HSTS is a site policy rather than a browser preference, and it is the only mechanism here that survives a typed http:// on a fresh profile. Once a browser has seen a Strict-Transport-Security header for a host, it rewrites later requests to https before sending them, which is exactly the property you want. It does nothing for a host the browser has never visited, and nothing for a different hostname that serves the same application.

Check what the origin sends with curl -sSI https://example.com | grep -i strict-transport-security. A missing header is a server change and not something a client can install. If it is present, read max-age and whether includeSubDomains is set, because a short max-age expires between visits and a missing includeSubDomains leaves every subdomain unprotected. RFC 6797 defines how a user agent applies the policy and what it may ignore. Preload is a separate commitment, so check status through the hstspreload.org API before promising anyone that a domain is on the list.

Verification and rollback

Rollback is cheap for the client settings and expensive for HSTS. Turning off HTTPS-only mode restores the previous behaviour immediately; a long max-age does not, and visitors who already received it keep upgrading until it expires.

So verify in order before calling it done. Reload from a cold cache and confirm the first request in the network panel is https with no preceding redirect. Then check a subdomain, because includeSubDomains is where these policies usually turn out to be narrower than assumed. Then check one page that pulls third-party assets, since mixed content is the failure that survives every other fix.

If the first request is still http after all of that, the client is no longer the variable: the link people click is. Search the places you control for the http form of the hostname, update them, and re-test with the same cold-cache reload. Keep the VPN question separate throughout, because the tunnel changes who can see the request and never changes whether the request is encrypted. The line to put in the ticket is that the first request is the one that matters, and a redirect is only a receipt for a request already sent.