Skip to contentNode.js on every plan · private Redis & PostgreSQLSee what's included →

Guides

Fix "your connection is not private" on your website

Why browsers show a privacy error on your domain, how free SSL issues itself here, and the three causes that account for nearly every broken padlock.

Every site here gets a free Let’s Encrypt certificate, issued automatically and renewed automatically. You never buy one, install one, or renew one. So when a browser shows “your connection is not private”, the certificate system is not broken. One of three specific things is wrong, and they are quick to tell apart.

First, see what the panel says

Open your site in the panel and go to Security. The SSL certificates table lists every domain and subdomain on the site with its status and expiry date. That table is the truth. If it says Active, the certificate exists and the problem is elsewhere. If the domain is missing or not Active, the certificate could not issue yet, and the cause is almost always DNS.

Cause 1: your domain is not pointing here yet

A certificate can only be issued for a domain that actually resolves to our servers, because Let’s Encrypt verifies control of the domain before signing anything. If you just connected a domain, the order of events is: DNS propagates, then the certificate issues, then the padlock appears. That whole sequence usually completes within the hour, and most of that hour is DNS, not us.

So if the site is brand new or the domain was just pointed, wait, then check the Security table again. If it has been more than a few hours, the domain is probably not resolving here at all. The guide to pointing your domain shows how to check where DNS actually points before you assume anything else.

Cause 2: the certificate is fine but the page loads insecure things

If the Security table says Active but the browser still refuses the padlock, the certificate is not the problem. The page is. A page served over HTTPS that loads even one image, stylesheet or script over plain http:// gets marked as insecure, and the certificate cannot fix that.

This is overwhelmingly a WordPress issue, because WordPress stores full URLs in its settings and content. Check Settings, then General: both the WordPress Address and Site Address must start with https://. Old posts and themes can still carry hardcoded http:// links after that, which a search and replace over the database fixes. The browser’s developer console names every insecure resource on the page if you want the exact list.

Cause 3: visitors can still type the insecure address

A certificate does not force anyone to use it. Someone typing your bare domain into an old browser can still land on the http:// version. On the same Security page, each domain has a Force HTTPS toggle. Turn it on once the certificate shows Active, and every plain request gets redirected to the secure version. There is no reason to leave it off on a live site.

If you use Cloudflare

Cloudflare in front of your site adds one more place SSL can be misconfigured, and one wrong setting there produces either a privacy error or an infinite redirect loop regardless of what this panel says. That case has its own guide.

What you never need to do

Buy a certificate, upload a certificate, or set a renewal reminder. Certificates here renew themselves before expiry with no action from you. The panel’s Install custom SSL button exists for the rare case where you already own a paid certificate and want to use it, not because you need one.

Keep reading

Other guides