Your website says "Not secure"? How to put it right, usually for free

Run this for the bare domain and again for www; with SNI the server can present a different certificate for each.

echo | openssl s_client -connect example.co.uk:443 -servername example.co.uk 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

notAfter= is the expiry. The Subject Alternative Name list must include every address people use. A wildcard such as *.example.co.uk covers www but not the bare domain. For monitoring, -checkend 1209600 in place of the last line's options exits non-zero if expiry is within 14 days.

echo | openssl s_client -connect example.co.uk:443 -servername example.co.uk -showcerts 2>&1 \
  | grep -E "Verify return code|^ *[0-9] s:"

An expired certificate gives Verify return code: 10 (certificate has expired). An incomplete chain gives 21 (unable to verify the first certificate) with only one certificate listed: install the full chain the certificate authority supplies. Names are only compared if you add -verify_hostname example.co.uk, which reports 62 (hostname mismatch) on a wrong one.

curl -vI https://example.co.uk/ 2>&1 | grep -E "subject:|issuer:|expire date|subjectAltName|SSL certificate (verify|problem)"

A healthy site ends SSL certificate verify ok.; an expired one stops with curl: (60) SSL certificate problem: certificate has expired.

CERT_AUTHORITY_INVALID also covers self-signed certificates, and Chrome's help ties it to work proxies such as ZScaler, Palo Alto Networks or Fortinet. If issuance keeps failing, check DNS for CAA records limiting which authorities may issue; Shopify needs letsencrypt.org, pki.goog and ssl.com allowed where they exist.

Chrome's adoption guide says any redirect step without HTTPS triggers the warning, tracking redirects and domain forwarding services included. A user's decision lasts 15 days and renews on each revisit. Localhost, local IPs and single-label or other non-unique hostnames are exempt. Certificate error warnings are separate and unchanged.

The guide's warning case is a bare domain with no HTTPS of its own, so first check that curl -sSI https://example.co.uk/ answers without a certificate error. A working one starts with a status line such as HTTP/2 301 or HTTP/2 200; a certificate fault prints a curl: (60) error instead. Then follow the redirects from http.

curl -sSI https://example.co.uk/ | head -n 1

curl -sI http://example.co.uk/ | grep -iE "^HTTP|^location"
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' http://example.co.uk/
curl -sIL -o /dev/null -w '%{http_code} %{url_effective}\n' http://example.co.uk/

The first hop should be a 301 or 308 whose Location already starts with https (for example HTTP/1.1 301 Moved Permanently, Location: https://example.co.uk/), and the chain should end on a 200 at the final https address. A first hop to http://www.example.co.uk/ is worth fixing too, but on its own it isn't what Chrome warns about. Repeat from http://www.example.co.uk/.

To see what visitors will, turn on Always Use Secure Connections at chrome://settings/security and browse the site, old campaign links and forwarding domains. HSTS, where set, takes precedence over these warnings.

Browsers auto-upgrade image, video and audio requests, CSS background images included, and block the rest, including scripts, stylesheets, iframes, fetch, web fonts, and images via srcset or <picture>. An otherwise upgradable request is blocked if its host is an IP address. Plain <a> links to http pages aren't mixed content.

In DevTools, the Privacy and security panel's Non-secure origins section has View requests in Network panel.

As a stopgap while the sources are fixed, this header or meta tag makes the browser upgrade insecure URLs before requesting them. Anything with no https version then fails to load, so it isn't a fix in itself.

Content-Security-Policy: upgrade-insecure-requests

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

Mixed forms (on an https page, submitting over http) have shown warning text, a full-page "submit anyway" warning and no autofill since Chrome 87. Search templates and plugin output for action="http:.

The Strict-Transport-Security header tells browsers to use only HTTPS for the host for max-age seconds. Browsers ignore it over http, and it shouldn't be on the http to https redirect response.

curl -sI https://example.co.uk/ | grep -i strict-transport-security

Two risks matter for a small business. Once a browser holds it, visitors can't click through a certificate error, so a lapsed certificate locks out everyone returning. And includeSubDomains blocks any subdomain that only works over http, such as an old test site or a booking page. Withdrawing it takes max-age=0 sent over HTTPS, and Squarespace warns that switching off "HSTS Secure" can keep returning visitors out for up to 48 hours.

Add it only once the redirect works and every subdomain runs on HTTPS, ramping max-age in stages (300, 604800, then 2592000 with includeSubDomains) and checking for breakage each time.

Strict-Transport-Security: max-age=300

Don't add preload to a small business site. hstspreload.org says inclusion can't easily be undone and removal takes months to reach users through Chrome updates.