SSL is one of those topics buried under acronyms — SSL, TLS, HTTPS, CA, cert — that sound technical enough to make you assume it's someone else's job. The good news is the idea underneath is simple, and on CloudPerch the whole thing sets itself up without you touching a single one of those acronyms.
Still, it's worth understanding what's actually happening, because it explains why we don't charge for it, why the padlock means what it means, and why a brand-new domain takes a few minutes to go green while a .cloudperch.io subdomain is secure right away.
The padlock, in plain words
When you visit a site over https://, two things are being handled at once.
The first is encryption. Without it, the data between your visitor's browser and your server travels in the open — readable by anything sitting between them, like a coffee-shop network or an internet provider. HTTPS scrambles that conversation so it's just noise to anyone in the middle. The login they typed, the form they filled, the page they read: private.
The second is identity. Encryption alone isn't enough if you can't be sure who you're talking to. A certificate is the thing that vouches for it — a small file, issued by a trusted authority, that says "yes, this server really is the one for yoursite.com." The browser checks that certificate before it trusts the connection.
The padlock in the address bar is the browser's shorthand for "both of those checks passed." Not "this site is honest," not "this business is legitimate" — just "the connection is encrypted and the certificate is valid." That's a narrower promise than people assume, but it's an important one, and visitors have learned to look for it. A missing padlock, or a "Not Secure" warning, is enough to send a lot of them straight back.
The padlock isn't a trust badge for the business behind the site. It's a guarantee about the connection — that it's private, and that you're really talking to who you think you are.
If you want the underlying mechanics in more depth, Cloudflare's explainer on TLS is a clear, vendor-neutral read. For the practical CloudPerch how-to, how SSL works on your site is the doc to keep handy.
Where the certificate comes from
For years, getting a certificate meant paying a vendor, proving who you were by email, downloading files, and pasting them into your server by hand — then doing it again every year before they expired. It was tedious enough that "we'll set up your SSL" was a service people charged for.
That whole world changed with automated certificate authorities — the best-known being Let's Encrypt, a free, nonprofit authority — which turned the issuing process into a quick, automatic handshake instead of a paperwork errand. Here's the shape of it:
- The server asks the authority for a certificate covering your domain.
- The authority needs proof you actually control that domain, so it sets a small challenge — typically "place this specific token where I can fetch it" or "answer at this address."
- The server passes the challenge, and the authority issues a certificate, valid for a set window.
- Well before that window closes, the whole dance repeats on its own. The certificate renews quietly, with nothing for you to remember.
That last step is the one that used to bite people. A forgotten renewal meant a site suddenly throwing scary browser warnings on a random Tuesday. Automation took that failure mode off the table entirely.
Why charging for it is outdated
Because issuing a certificate is now free and automatic, treating SSL as a paid add-on is a bit like charging extra for the locks on a house you're already selling. The cost that used to justify the fee — the manual labor, the per-certificate vendor pricing — mostly evaporated.
So we don't charge for it, on any plan. Free SSL is auto-provisioned and auto-renewing, full stop. It's not a checkbox on the expensive tier, not an "upgrade to secure your site" nudge in the dashboard, not a line on the invoice. A personal blog on Roost is encrypted exactly the same way a busy store on Flock is. Security that's an upsell isn't really a baseline, and we wanted it to be the baseline.
How it provisions on CloudPerch
Here's what you actually experience, which is mostly: nothing.
- On your instant subdomain, the moment your site exists, it's already served over HTTPS. Your
your-site.cloudperch.ioaddress is ours, we control its DNS, so the certificate is ready immediately — no waiting, no propagation. - On a custom domain, there's a short, normal delay. The certificate authority has to confirm the domain points at your site before it'll issue anything, and that confirmation depends on DNS resolving first. So on a brand-new domain, give it a few minutes after you connect it. The padlock appears once the proof goes through — no buttons to press on your end.
That ordering — DNS first, certificate second — is the one piece worth remembering, because it explains the only "wait" you'll ever notice. If your new domain hasn't gone secure after a little while, it's almost always DNS still settling rather than SSL itself. Our plain-words guide to DNS untangles that side of things, and when a domain is registered through us, the DNS is handled automatically, so the certificate usually follows without any fuss at all.
Under the hood there's a renewal process watching every certificate and refreshing it ahead of expiry, the same automated handshake described above, running on a schedule you never have to think about. The first issue is quiet. Every renewal after it is quieter.
Settle in secure
The short version: SSL is encryption plus a vouched-for identity, the padlock means the connection passed both checks, certificates issue and renew themselves automatically now, and charging for that is a holdover from a slower era. On CloudPerch it's on by default, free, and self-maintaining — secure the moment your site exists on its subdomain, and a few minutes behind DNS on a custom domain.
When you're ready to go live, launch your first site and watch the padlock arrive on its own, or see the plans — every one of them comes secured, because that's where the floor should be.