HTTPS in website builders, and the certificate errors that still happen

Somebody connects a custom domain to their builder, the builder's own marketing page says "free SSL, included, automatic," and twenty minutes later the browser shows a red warning anyway. That gap — a security feature described as automatic, followed by a warning that says it plainly isn't — is where most of the confusion in this topic lives. The instinct is to assume the certificate failed. It almost never has. What actually broke is something upstream or downstream of the certificate: the DNS record hasn't settled, a leftover CAA rule from a previous host is quietly refusing the new certificate authority, one image on the page is still loading over the old plain-http address, or the certificate only covers one of yourdomain.com and www.yourdomain.com while the visitor landed on the other. Four different problems, one identical browser warning, and the warning gives you no hint which of the four you're looking at.

The subdomain is instant. The custom domain never is.

Worth separating early, because the two paths behave completely differently and builders rarely explain why. If you publish to the free address your builder gives you — a *.wixsite.com, a *.typedream.app, a *.wstd.io — the certificate is already issued for that shared domain before you ever touch it. There's nothing to wait for. reach is the cleanest example of this: publishing to a free yourname.joinreach.app subdomain is a file copy plus a status flip, live in seconds, HTTPS included from the first request.

A custom domain is a different transaction entirely, on every builder, because the certificate authority has to independently verify that you actually control the domain before it will issue anything — and that verification depends on DNS, which is out of the builder's hands. On reach specifically, connecting a custom domain requires Premium, and the honest number is minutes to hours after payment, not seconds — the same registrar-DNS-then-certificate sequence that governs every other builder in this piece, stated plainly rather than folded into the same "instant" language as the subdomain. That's also the moment to name reach's real limitation here: you cannot connect a domain you already own. The only path to a custom domain on reach is buying one through them, so if your name is already sitting at a registrar from years ago, that registration doesn't transfer in — a genuine blocker worth knowing before you commit to the platform for that reason alone. Domains and hosting, explained without the registrar sales pitch covers why that registrar-versus-builder split matters beyond this one certificate question.

How the certificate actually gets issued

Nearly every consumer builder now runs on the same underlying mechanism: an automated certificate authority, most commonly Let's Encrypt or a managed equivalent, that issues a certificate the moment it can confirm two things — that the domain resolves to the builder's servers, and that nothing in DNS is blocking that specific authority from issuing for you. The first condition is the one everyone thinks about; the second is the one that produces the confusing failures.

Confirmation of the first condition depends entirely on DNS propagation, which is not instant no matter what a checkout page implies. Connecting a domain to your website builder walks through the actual record types involved, but the timing point stands on its own: a DNS change can take anywhere from a few minutes to, in the worst case, around 48 hours to fully propagate across every resolver a visitor might hit. The certificate cannot issue until the builder's validation system sees the record it's checking for, and it keeps checking on its own schedule rather than the moment you save the DNS change. So the first and most common cause of "no padlock" is simply: not enough time has passed. Wait, refresh, check again in an hour before assuming anything is broken.

The CAA record nobody remembers exists

The second condition — nothing blocking that specific authority — is where things get genuinely confusing, because the failure is silent by design. A CAA record is a DNS entry that names which certificate authorities are permitted to issue for a domain; its entire purpose is to stop unauthorized issuance, which is a real security feature. The problem shows up when a domain has changed hands between hosts. If a previous host set a CAA record authorising only its own certificate authority — a security-conscious decision at the time — and nobody removed it during the migration, the new builder's certificate authority is refused every single time it tries to issue, and neither side surfaces an error that says "CAA record." The browser just keeps showing "Not Secure," the builder's dashboard just keeps saying "pending" or silently fails to progress, and there is no obvious next step unless you know to look. DNS records for non-technical people is worth reading before you go looking for this one, since CAA records don't behave like the A and CNAME records most people are used to checking. The fix, once you've found it, is usually one line: either delete the restrictive CAA record so any authority can issue, or add an entry that explicitly permits the one your builder uses.

Mixed content: the padlock that disappears after it appeared

A fourth failure mode shows up after the certificate is clearly working — the address bar says secure, then a specific page doesn't. That's mixed content: the page itself loads over https://, but at least one resource on it — an embedded image pulled from an old http:// URL, a script tag pointing at a plain-http source, an iframe embed that was never updated when the surrounding site moved to HTTPS — loads insecurely. Browsers treat that as a partial failure and downgrade the whole page's security indicator, sometimes to a warning icon and sometimes to blocking the resource outright, depending on whether it's passive content like an image or active content like a script. This is the one failure mode that has nothing to do with DNS or the certificate at all; the certificate is fine, and the fix is finding and updating the specific http:// reference, usually inside an embed code, a hardcoded image URL from a page builder's early days, or a widget that was copy-pasted from another site years before HTTPS was universal.

Root and www need the same coverage, and often don't get it

The last recurring cause is a coverage gap rather than a validation failure. A certificate issued for yourdomain.com does not automatically cover www.yourdomain.com, and the reverse is also true — they're treated as distinct hostnames unless the certificate explicitly lists both, or unless the builder issues one and redirects the other before a browser ever requests a certificate for it. Most builders now do this correctly by default, generating what's called a multi-domain or wildcard-adjacent certificate that covers both forms and redirecting whichever one you didn't set as primary. But it's not universal, and when it's missing, the symptom is oddly specific: the site works perfectly at one address and throws a certificate mismatch error at the other, which sends people down the DNS-and-CAA troubleshooting path for a problem that's actually just a missing hostname on the certificate itself.

The order to check things in

Given four causes that produce the same warning, checking in the wrong order wastes the most time. DNS propagation first — confirm the record actually resolves to where it should, from a tool outside your own network, since your own device may have cached the old answer. Then the certificate's actual coverage — most browsers let you click the padlock or the warning icon and see exactly which hostnames a certificate lists and when it was issued, which immediately rules in or out the root/www gap. Then CAA, which requires a DNS lookup tool rather than the browser, since it's the one cause a browser interface won't ever show you directly. Mixed content last, because it only matters once you've confirmed the certificate itself is valid — checking for it earlier just adds noise to a DNS problem that hasn't been ruled out yet.

Four causes, one warning message, and a fifteen-minute check in the right order that tells you which one you're actually looking at.