Certificates: what we issue, what you must do yourself, and what HTTPS does not hide
We issue and renew TLS for your hostname automatically, on every plan. What that covers, what it does not, and the things a padlock says nothing about.
Certificates: what we issue, what you do yourself, what HTTPS hides
HTTPS is the least interesting security property a site can have and the one most often used to imply the others. This page separates them.
What we issue
A certificate for your apex and www hostnames, issued automatically as part of provisioning and renewed automatically thereafter. It is free, and it is on every plan, including the free one — a padlock is not an upsell here.
Requests for the plain-HTTP version of a page are served over HTTPS instead. You do not configure any of this, and there is no renewal date for you to remember. See also: getting started, where certificate issuance is one step of the provisioning pipeline.
Two adjacent things ship with every domain and are frequently confused with it: DNSSEC, which lets a resolver detect tampered DNS answers, and anycast DNS, which answers queries from wherever is nearest. Neither is TLS. DNSSEC protects the answer to "where is this site"; the certificate protects the conversation once you get there.
What you have to do yourself
- Keep the domain's DNS where we can manage it. Issuing and renewing a
certificate requires us to answer a challenge in your zone. Point the nameservers somewhere else and that path is gone; whatever now serves the site is responsible for its own certificate.
- A hostname that resolves somewhere else is not covered. A subdomain you
delegate to another provider is served by that provider, and it presents that provider's certificate.
- If you put another CDN or proxy in front of us, there are two encrypted
hops and the certificate visitors see is theirs. Ours still protects the hop to us, which is not the same promise.
- Your content has to be HTTPS-clean. One image, script, or iframe loaded
over plain HTTP drops the padlock in every browser. That is a content fix — a link in your own markup — not something a certificate can compensate for.
- Mail is a separate protocol with a separate problem. A certificate for
your website does nothing for your email. Mail authentication is SPF, DKIM and DMARC, which provisioning publishes for you; see also: Email Hosting.
- Keep your own dependencies current. On App Hosting, automatic core and
plugin updates are a separate mechanism from the certificate and a separate promise. Turning them off does not affect your padlock and does affect your exposure.
What it does do, stated plainly
Encrypting the transport is worth having, and it is not nothing. It stops anything on the path between a visitor and us from reading or altering what is sent — a form submission, a session cookie, the page itself. It is also the precondition for a growing list of browser features that simply refuse to run on a plain-HTTP origin. That is the claim. It is about the pipe, and it is a real one, which is exactly why it should not be asked to carry the rest.
What HTTPS does not hide
| The assumption | What is actually true |
|---|---|
| "The connection is encrypted, so the visit is private." | The content of the request is protected. The hostname being asked for and the fact that a connection happened are not. |
| "The padlock means the site is trustworthy." | It means the connection to this hostname is encrypted. It says nothing about who runs it. |
| "We have SSL, so we are secure." | It protects the transport — not the server's honesty, your dependencies, or a compromised CMS plugin. |
| "DNSSEC covers it." | DNSSEC protects DNS answers from tampering. It is not a substitute for TLS and it does not validate content. |
The third row is the one that does damage. A valid certificate on a lookalike domain renders the same padlock as yours, which is why phishing sites have one too. And on your own site, a certificate does nothing about the things that actually go wrong: an abandoned WordPress plugin with a known vulnerability, an outdated dependency, an API key committed to a repository, an admin password that is the name of the business. All of those live above the transport layer, and all of them survive an encrypted connection intact.
Checking it yourself
Open the padlock menu in your browser and look at the certificate. Three things are worth confirming, and none require a tool:
- It is issued to your hostname — not to a hostname that resembles it.
- It is in date. Ours renew automatically, so a stale one means something
is no longer being managed by us.
- The browser reports the connection as encrypted with **no mixed-content
warning**, which is the one on this page that is usually your own content.
If all three hold, the transport is doing its job. That is the whole of what it promises, and it is worth having — it is just not the same as the site being safe, maintained, or honest.