HTTPS for your sites

Turning on HTTPS — the padlock in the address bar — is a single setting in your control panel. You don't buy a certificate, you don't upload anything, and you don't run any commands. You switch Encryption on for a site, save, wait about a minute, and your site is live over https:// with a real, browser-trusted certificate. After that it renews itself, for free, for as long as the site exists.

The certificates come from Let's Encrypt. Your account handles the whole lifecycle: it requests the certificate the moment you enable encryption, keeps it covering every domain your site answers on, and renews it well before it expires. Your only real job is one bit of DNS homework, described below — get that right and everything else is automatic.

Turn HTTPS on

The setting lives on a site's Edit tab, not on the form where you first create the site. So create the site first, then:

  1. Open the site in your control panel and click the Edit tab.
  2. Open the SSL Settings section.
  3. For Encryption, choose one of:
    • Enabled — your site answers on both HTTP and HTTPS. Visitors can use either address, and you can steer them to the secure version for the pages that need it.
    • Required — your site answers on HTTPS, and any plain-HTTP visitor is redirected to HTTPS automatically. This is what most people want.
    • (Disabled is the off position — no HTTPS.)
  4. Leave Encryption key on Generate a new encryption key (the default). You don't need to pick anything here; your account creates and manages the certificate for you.
  5. Click Save.

Saving queues a Verify task on the site. That task is what actually requests the certificate from Let's Encrypt and switches the site over to HTTPS, so wait for it to finish (you'll see it turn green in the task list). When it's done, load your site over https:// and look for the padlock.

Get your DNS right first — this is the one that trips people up

Let's Encrypt will only issue a certificate for a domain that actually points at your server, and it checks every domain the certificate has to cover — not just your main one, but each alias you've added to the site as well. The www. version of a domain counts as a separate name here: if you've added www.example.com as an alias so both the bare and www. addresses work (a very common setup), then www.example.com has to resolve to the server too. If even one name on the site has no DNS record, or points somewhere else, the whole certificate request fails and the site stays on plain HTTP.

So before you switch Encryption on:

  • Make sure your site's main domain resolves, in public DNS, to your server's address.
  • Make sure every alias you've added resolves there too — the www. companion very much included.

This is by far the most common reason a first HTTPS attempt doesn't complete: one of the site's names (often the www. alias) isn't pointed at the server yet, so the certificate can't be issued. Point every name at the server first, then enable encryption. Which aliases your site has, and how to point them at your server in DNS, are covered under Site aliases and redirects.

Adding or changing aliases later

Every domain your site answers on is listed together on one certificate. Whenever you add, remove, or change the aliases on a site — or change its redirect target — your account re-issues the certificate on the next Verify so it keeps covering all of them. The same DNS rule applies: a newly added alias only makes it onto the certificate once its DNS resolves to the server. If you add an alias and visitors to it see a security warning, the fix is almost always "point that alias's DNS at the server, then run Verify on the site."

Renewal happens by itself

You never have to remember an expiry date. Let's Encrypt certificates are short-lived on purpose, and your account renews them for you automatically, well ahead of time. There's nothing to schedule and nothing to click. Running a Verify on a site also refreshes its certificate check, but you rarely need to — the automatic renewal has it covered.

If you get a "renewal failed" email

The only time renewal needs your attention is when something outside HTTPS has broken — almost always DNS. If a scheduled renewal can't complete, the system emails you a notice with the subject "Action needed: HTTPS certificate renewal failed for one or more of your sites", listing the affected site(s) and, for each, the reason it couldn't renew. It goes to your account's contact email, and (so a broken site doesn't mail you every night) it's repeated at most about once a week per site until the situation is resolved.

When you get one, pick whichever of these fits:

  • The site is still in use. A domain or one of its aliases has stopped pointing at the server — check its DNS (the A / AAAA records) and point it back at your server. Once DNS is correct again, the certificate renews on its own; you don't have to do anything else.
  • The site or alias is no longer used. If it's a leftover you don't need — say a dead domain, or an old clone you've finished with — turn Encryption back to Disabled on that site, or remove the obsolete alias. That stops the nightly check from failing, and stops the emails.

The message is purely informational — you act on it entirely from the control panel and your DNS provider. There's nothing on the server for you to touch.

After a clone or a rename

A certificate is tied to a site's exact domain name, so it can never be reused under a different name. Your account knows this, so it protects you automatically:

  • When you clone a site, the new copy always starts with Encryption disabled — it must never borrow the original site's certificate.
  • When you rename a site (a Migrate that changes the main domain), your account turns Encryption off on the renamed site for you before it re-verifies, for the same reason.

In both cases the steps are the same afterwards:

  1. Finish the clone or the rename.
  2. Make sure the new site's domain — and all of its aliases — resolve in DNS to your server (same rule as a first-time setup).
  3. Open the new site's Edit tab, set Encryption back to Enabled or Required, and Save.
  4. Wait for the Verify task to finish; it issues a fresh certificate under the new name.

You don't have to disable encryption by hand first — that part is done for you. You just re-enable it on the new site once DNS is ready. The control panel itself (the Aegir control panel and Adminer) is a special case that's already served to you over HTTPS by your host; don't try to switch encryption on for it from inside the control panel.

Using your own purchased certificate

If you've bought a commercial certificate (for example an EV or wildcard certificate) and want to use it instead of Let's Encrypt, that's the one HTTPS job you can't do yourself on hosted BOA: it means placing files on the server, and you don't have access to where those files live. This one is your host's job — open a support request and send them the certificate, its private key, and any intermediate/chain files, and they'll install it for you.

The same goes for the rare case where a certificate simply won't issue even though every domain and alias correctly resolves to the server. That usually points at something only your host can see — such as a Let's Encrypt rate limit on your domain — so it's worth a short support request rather than more retrying on your side.

Where to go next

  • The aliases a certificate needs to cover, and how to point them at your server in DNS, are in Site aliases and redirects.
  • If HTTPS looks wrong only from your own machine (a warning nobody else sees, or a site that won't load at all), start with When you can't connect.
  • The exact task and setting names used here are collected in the shared Reference.