What is HTTPS and why does Chrome say 'Not secure'?

What it actually is

HTTPS is HTTP, the protocol your browser and a server use to trade pages and data, run inside an encrypted tunnel called TLS (Transport Layer Security). The lock icon in your address bar stands for two separate promises: nobody sitting in between can read what passes through the tunnel, and a certificate proves your browser is really talking to the server you typed in, not an impostor.

The certificate does the proving. A certificate authority checks that whoever asked for it actually controls the domain, then signs a small file saying “this public key belongs to yoursite.com.” Your browser already trusts a short list of these authorities, the way you’d trust a passport because you trust the government that stamped it. HTTPS also defaults to a different port, 443, than plain HTTP’s 80.

You’ll still see “SSL” everywhere: SSL certificate, SSL settings. SSL was the original protocol, retired years ago for being insecure. TLS replaced it and is what actually encrypts your connection today, but the old name stuck, so “SSL” and “TLS” now mean the same thing in everyday use.

Why your AI just did this

Your agent doesn’t write any encryption code to get you HTTPS. Hosting platforms like Vercel and Netlify request a free certificate from Let’s Encrypt the instant you add a domain to a project, using an automated process that proves domain control and issues the certificate without a human approving anything. That’s why a brand-new yourproject.vercel.app address is already HTTPS before you’ve touched a setting.

The manual part is connecting your own domain. Vercel can’t request a certificate for yoursite.com until it can prove to Let’s Encrypt that you control that domain, and that proof depends on your DNS records already pointing at Vercel. So your agent can tell you the deploy worked while the domain still shows a warning. That gap is normal, not something your agent broke.

When you’ll run into it

Chrome writes “Not secure” next to a domain in the address bar the instant it loads over plain HTTP instead of HTTPS. That’s the mild version.

The scarier one is a full red page reading “Your connection is not private,” often paired with a code like NET::ERR_CERT_AUTHORITY_INVALID (the browser doesn’t recognize who issued the certificate) or NET::ERR_CERT_COMMON_NAME_INVALID (the certificate was issued for a different domain than the one you’re visiting). Right after connecting a custom domain, this usually just means the certificate hasn’t been issued yet because the DNS check hasn’t cleared, not that anything is compromised.

A quieter version shows up in your browser console as a mixed content warning: your page loaded over HTTPS but tries to pull in a script, stylesheet, or API call over plain http://. Chrome blocks the risky ones, with a message like: Mixed Content: The page at 'https://yoursite.com' was loaded over HTTPS, but requested an insecure script 'http://...'. This request has been blocked; the content must be served over HTTPS. The exact wording swaps in “script,” “stylesheet,” or whatever type got blocked. Images and video get more leeway, quietly upgraded to HTTPS instead, but a blocked script or stylesheet can leave part of your app silently broken.

What to check

• If you just added a custom domain, give it time. DNS and certificate issuance can take minutes to a few hours; a warning right after setup usually isn’t broken, it’s still catching up.
• Confirm the DNS records at your registrar match exactly what your host asked for. A mistyped value is what actually stalls issuance past the normal wait.
• Open your browser console and search for “Mixed Content.” It names the exact blocked URL, so you know precisely which asset to switch from http:// to https://.
• Search your own code for hardcoded http:// links, especially anything pointing at an external API, image host, or embed.
• Click the padlock or warning icon and check which domain the certificate covers. A certificate for the wrong domain and an expired one throw different, specific errors worth reading instead of guessing.
• Skip any browser flag or extension that silences certificate warnings just to make the message disappear. It hides a real signal instead of fixing what triggered it.

Say it like a dev

Instead of: “the site says Not secure, is it broken?” Say: “Chrome shows Not secure in the address bar, is this page actually being served over HTTP instead of HTTPS?”

Instead of: “I connected my domain and now there’s a scary red warning” Say: “I’m getting a certificate error right after adding my custom domain, has the DNS verified on the host’s side yet, or is the certificate still being issued?”

Instead of: “some stuff on the page isn’t loading and there’s a warning in the console” Say: “the console shows a mixed content warning, something is loading over http on an https page, can you find it and switch it to https?”