What "this site can't provide a secure connection" means

You typed in your own address — the one you have been proudly sending to people — and the browser gave you a grey page instead of your app. Underneath, in smaller letters, there may be a code like ERR_SSL_PROTOCOL_ERROR.

What is the browser actually telling me?

Before a browser shows you a page, it has a quick, silent negotiation with the computer holding your site. They agree on how to scramble the traffic so nobody in between can read it, and the site proves it is who it says it is by presenting a small file — the thing that makes the padlock appear. Only after that does anything load.

This message means that negotiation failed. As the guide writers at DreamHost describe it, the browser and the server did not get through the opening exchange — agreeing on the encryption, checking the file, swapping keys — all of which happens before a single pixel of your app is sent.¹

So the browser stops. It does not show a broken version of your site, and it does not show a warning you can click past. It shuts the door, because the alternative is sending your users' passwords over a connection it cannot vouch for.

That is genuinely the whole meaning. Not "your database is down". Not "your code is broken". Which is oddly good news, because the usual causes are boring and most of them live on the address side, not the app side.

How do I work out whether it's my site or my computer?

Do these four checks in order before you change anything. They take about two minutes and they will stop you breaking something that was not broken.

1. 1
   Open the address your building tool gave you

   Every one of these tools hands you a default web address before you attach your own — something ending in .lovable.app, .replit.app, .vercel.app or .netlify.app. If that loads perfectly and your own domain shows the grey page, the app is running and this is a domain problem.
2. 2
   Try it on your phone, off wi-fi

   Turn wi-fi off, switch to mobile data, open the site. If it works there and not on your laptop, the fault is on your laptop — a browser extension, antivirus software that inspects secure traffic, or an office or café network doing the same thing.
3. 3
   Check your computer's clock

   This feels absurd and it is real. Those proof-of-identity files are only valid between two dates, so if your machine thinks it is a different year, secure sites break one after another. It appears on every fix list for this error, including Hostinger's.
4. 4
   Try it in a private window

   If the private window works, something stored in your normal browser is stale. Clear it and move on. If the site fails everywhere, on every device, on mobile data — then it is your site, and the next section is for you.

What usually causes this on an app built with an AI tool?

Four things account for almost all of it, and three of them happen on the day you connect your own domain. None of them require touching your code.

The padlock file hasn't been issued yet

This is by far the most common cause. You point the domain at your app, everything looks right, and for a while your site answers with no proof of identity at all — so the browser refuses it. The platform issues that file automatically, but only once it can see your domain pointing at it.

Lovable's own domains FAQ says the secure certificate is issued automatically, and that domain changes can take up to 72 hours to spread across the internet, though it is usually faster. If you connected a domain in the last day, the fix is to wait. Do not keep editing records — every change restarts the clock.

Cloudflare is sitting in the middle

If your domain is managed by Cloudflare and you left the little orange cloud switched on, Cloudflare intercepts the traffic before your platform ever sees it — and your platform then cannot prove ownership or install anything.

Lovable's custom domain documentation says exactly this: set the records to DNS only, the grey cloud, rather than Proxied, wait a few minutes and try again. If you use Cloudflare and you are seeing this error, check that first.

www works and the bare domain doesn't

As far as a server is concerned, yoursite.com and www.yoursite.com are two different names, and a padlock issued for one does not cover the other. Trustico's write-up is blunt about it: they are technically different hostnames. If one of yours loads and one doesn't, add the missing one in your platform's domain settings.

The address record is wrong or was deleted

Lovable's FAQ notes that a domain showing "Offline" usually means the record pointing at it is wrong or gone. The same principle applies everywhere else. Re-check the record against the exact value your platform shows you, character for character.

How do I find out before a customer tells me?

Here is what actually stings about this error. Your app was up. Your code was fine. Your users hit a grey wall, most of them left, and you found out when the one kind enough to say something sent you a screenshot. You have no idea how long it had been like that.

These faults are especially cruel because they arrive on their own schedule. A renewal that silently fails. A record a registrar rewrites during a transfer. You will not catch that by checking manually, because you will check on the days it works. So it is worth having something outside your app looking at it.

Be honest with yourself about which column you are in. The engineering tools are mature and capable, several will warn you ahead of an expiry, and they reach you through many more channels. If a phone alarm at 3am is what you need, they will serve you better — Fomio tells you by email, and does not send text or chat messages today.

Fomio's free plan watches one app from outside, checks it every five minutes, emails you when it breaks and keeps seven days of history, with no card needed. Builder watches three apps, checks every minute, includes the fix prompts and thirty days of history. Pro watches fifteen, keeps a year, and gives you a status page your own users can look at. Current prices are on fomio.ai/pricing.

What should I do right now?

Open the default address your building tool gave you. If it loads, breathe — the app is running and this is the domain, which is the smaller problem.

If you connected that domain today, wait a few hours before touching anything. If you use Cloudflare, switch the record to DNS only. If only the www version works, add the other one. If it has been more than three days with correct records, that is the point to contact your platform's support — and now you can tell them precisely what you checked.

Then set something to watch it, so the next time this happens you hear it from a machine at 4am rather than a customer at noon.