Chrome Now Asks Before Opening HTTP. Your Site Has HTTPS. The Domain That Redirects to It Might Not.

Chrome 154 went stable on September 22, and one line in its release notes is "Ask before HTTP on by default". On October 21 Google's security blog confirmed it's now on for all users, not just people in Enhanced Safe Browsing. Chrome tries HTTPS first for every public site. If HTTPS doesn't work on that host, Chrome stops and shows a full-page warning before it will load the plain HTTP version.

Most indie sites are fine. Google says early rollout data shows nearly 95% of desktop Chrome users don't see a single one of these warnings in a given week. But the warning isn't only about your homepage. It fires on any hop in a redirect chain, and indie hackers have a lot of hosts sitting in front of their site that nobody has looked at in a while.

What actually triggers it

The detail that matters is in Chromium's own guide to adapting your site for the Ask-before-HTTP warning:

• An http:// link is not a problem by itself. Chrome rewrites it to https:// first. If the host answers on HTTPS, the user never sees anything.
• The warning shows when Chrome "was unable to connect to a site via HTTPS". No HTTPS listener, or a certificate that doesn't cover that exact hostname.
• Redirects count. If any step in the chain doesn't support HTTPS, the user gets the warning, even if the last page is HTTPS. Two bad hops can mean two warnings.
• Chrome remembers "continue" for 15 days per site. So you, the owner who clicks your own links daily, may never see it again after the first time. A new visitor sees it on their first click.
• If a site sends HSTS, Chrome doesn't fall back to HTTP at all.

Their example is the classic one: you serve https://www.example.com, but example.com (the apex) only redirects on port 80 and has no certificate. Everyone who types the bare domain now gets a warning.

Where indie hackers usually have these hosts

My guess at the usual suspects, from the docs below. None of them show up if you only test your main URL.

1. The spare domain you forward at the registrar. The .io you also bought, the old product name, the typo domain. Registrar forwarding works differently at each one:

• Namecheap's URL Redirect record help page says a redirect from http:// on your domain to an https:// site "functions as simple domain forwarding", and that redirecting from https://domain1 to https://domain2 needs SSL certificates installed on both. The redirect record alone doesn't give your spare domain a certificate.
• GoDaddy says forwarding over HTTPS is now available for all forwarded domains, and that it's applied automatically when you set up a new forward or edit an existing one. Their own wording says the first connection to forwarded domains used to be unprotected. If you set the forward up years ago and never touched it, check it.
• Porkbun's product page says its free URL forwarding supports HTTPS requests and works for HSTS-only TLDs like .app.

2. The click-tracking host in your emails. Link branding puts a subdomain like email.yourapp.com or url1234.yourapp.com in every link, CNAMEd to the email provider. The provider needs a cert for your subdomain, which is a separate setting:

• Mailgun's help center says the tracking protocol is a switch from HTTP to HTTPS in domain settings. One-click HTTPS (Let's Encrypt) is on the Foundation, Scale, Contract and Enterprise plans. Otherwise you set it up yourself with a CDN in front.
• SendGrid now has Auto SSL for link branding. Its docs say that for an existing branded link you have to re-run the setup with "Auto provision SSL Certificate" turned on. Old branded links don't get it for free.

So the link in your welcome email can hit a warning page before your HTTPS site even loads. Your provider will still count the click.

If you left that email provider and the CNAME is still in your DNS, that's a different and worse problem. I wrote about what one forgotten CNAME let spammers do on an msn.com subdomain.

3. Apex vs www. If your host gave you a cert for one name and you added the other later as a DNS-level redirect, one of them may have no cert. That's the exact case in Chromium's example.

4. Printed and pasted stuff. QR codes on stickers, links in old PDFs, a short-link domain you set up once for a conference. You can't reprint those, but you can put HTTPS on the host they point at.

A 20-line check that does what Chrome does

curl -L doesn't help here, because curl happily follows http:// and never tries HTTPS first. So I wrote a small script that walks the chain one hop at a time. For every http:// hop it tries https:// on the same host. If that works, it continues on HTTPS (that's what Chrome does). If it doesn't, that hop is a warning.

#!/usr/bin/env bash
# ask-before-http.sh: walk a redirect chain the way Chrome 154 does.
# For every http:// hop, try https:// on the same host first.
# If HTTPS answers, Chrome upgrades quietly. If not, Chrome asks first.
url="$1"; asks=0
for hop in $(seq 1 10); do
  if [[ "$url" == http://* ]]; then
    if curl -s -o /dev/null -m 8 "https://${url#http://}"; then
      echo "$hop  upgraded  $url"; url="https://${url#http://}"
    else
      echo "$hop  ASKS      $url"; asks=$((asks+1))
    fi
  else
    echo "$hop  ok        $url"
  fi
  next=$(curl -s -o /dev/null -m 8 -w '%{redirect_url}' "$url")
  [[ -z "$next" ]] && break
  url="$next"
done
echo "warnings: $asks"

Real output from this morning. neverssl.com exists on purpose to never have HTTPS, so it's a handy "bad" case:

$ ./ask-before-http.sh http://neverssl.com/
1  ASKS      http://neverssl.com/
warnings: 1

$ ./ask-before-http.sh http://github.com/
1  upgraded  http://github.com/
warnings: 0

$ ./ask-before-http.sh http://www.uno.directory/
1  upgraded  http://www.uno.directory/
2  ok        https://uno.directory/
warnings: 0

I also ran it on the apex and www of the 9 domains I run. All 18 came back upgraded, zero warnings. That's a good result, but it's also the boring part. The hosts most likely to fail are the ones in the list above, and you have to feed them in yourself.

A few honest limits. curl treats a bad or mismatched cert as a failure, which is close to Chrome's "unable to connect via HTTPS", but it's not a browser: it doesn't know about HSTS preload or meta refresh, and it doesn't care whether the server answers 200 or 500 on HTTPS. Treat it as a quick filter, then confirm in Chrome.

If you'd rather not run a script, paste the URL into a redirect checker that lists every hop and flags the http ones. For any hop that still starts with http://, open the same host with https:// in a browser. If that fails, that's where your visitors are seeing the warning.

Finding the hosts in the first place

For your own pages, this lists every external http:// host your homepage links to:

curl -sL https://yoursite.com/ | grep -oE 'href="http://[^"/]+' | sort -u

On our 7 main homepages it printed nothing, which is what you want. Run the same grep over your email templates and your docs folder. For tracking hosts, the quickest way is to send yourself the real email and copy the link from the inbox, not from the template, because the provider rewrites it after you hit send.

To see it the way a visitor does, Chromium's guide suggests turning on "Always use secure connections" at chrome://settings/security yourself and using your site normally for a day.

The fixes, roughly in order of how often they'll matter

1. Tracking domain: turn on HTTPS in your email provider (Mailgun tracking protocol, SendGrid Auto SSL re-run), then send a test and click it.
2. Spare domains: move forwarding to something that issues a cert (Porkbun, GoDaddy after editing the forward, a Cloudflare redirect rule on a proxied record), or point the domain at your host and redirect there.
3. Apex/www: make sure both names are on the cert, and redirect HTTPS to HTTPS.
4. Old subdomains you don't use: delete the DNS record. No host, no warning, no takeover.
5. Once everything answers on HTTPS, add HSTS on hosts you control so Chrome never tries HTTP there.

If you're adding certs to a pile of small hosts, mind the renewal side too. Let's Encrypt lifetimes are getting shorter, and I covered what to grep for before the 64-day certificates arrive.

Question for anyone who sends product email: is your click-tracking subdomain on HTTPS right now, and if you checked after October 21, did your provider already have it on, or did you have to go switch it yourself?