Let's Encrypt certificates

Wondering how free SSL certificates get from Let's Encrypt onto your domains?

This article explains the three objects involved — certificate manager, certificate, domain router — and how they fit together.

For paid (commercial) SSL certificates, see Paid SSL certificates.

The three pieces

Three objects in Core together produce a working HTTPS endpoint:

1. Certificate manager — issues certificates from a provider (Let's Encrypt). You give it a list of domains to cover.
2. Certificate — the actual PEM cert + chain + key. Produced by the manager for the domains you listed.
3. Domain router — the per-domain object that decides what's served. It has a slot for one certificate. The router presents that certificate to visitors over TLS.

In short: manager → certificate → router. The manager owns the lifecycle (issuance, renewal); the certificate is what gets attached; the router is where it's presented.

Certificate manager

A certificate manager has two fields:

• 'Provider' — for free certificates, this is 'Let's Encrypt'.
• 'Common Names' — the list of domains the certificate should cover. You pick from existing domain-router domains on the cluster.

One manager can cover multiple domains. They'll all be on a single SAN certificate. Re-use a single manager for a project's primary domain plus its www. alias plus any other aliases — that's one certificate, one renewal, one attachment per router.

A domain can only be part of one certificate manager at a time. Domains already covered by an existing manager don't appear in the dropdown when you create a new one.

Certificate

The certificate is the actual PEM bundle. For a Let's Encrypt manager, you don't create it directly. The manager produces it the first time it runs against the provider, and again whenever it renews.

The manager's detail page shows a 'Request certificate' action that triggers issuance on demand — useful if you've just added a new domain to the manager and don't want to wait for the next scheduled run.

The same 'Certificates' object model also covers paid certificates, where you paste in your own PEMs. For Let's Encrypt, ignore that path.

Attaching to the domain router

Each domain router has a 'Certificate' tile. Once the manager has produced a certificate, that certificate is attached to the domain routers whose domains are in the manager's 'Common Names'.

You usually don't touch the 'Certificate' tile on the domain router yourself — the manager handles it. The tile is mainly relevant when:

• You're attaching a paid certificate (no manager involved).
• You're switching between two certificates that cover the same domain (e.g. migrating from a paid cert to Let's Encrypt).

Renewal

Let's Encrypt certificates have a short lifetime (currently 90 days). Cyberfusion renews them automatically — the certificate manager re-runs against the provider well before expiry and the new certificate replaces the old one with no downtime and no action on your side.

You don't need a cron, an external script, or any manual step. As long as the manager exists and its 'Common Names' still resolve to domain routers on the cluster, renewal happens on its own.

What goes wrong, and how to spot it

The most common reason a Let's Encrypt issuance fails is that the domain doesn't yet resolve to the cluster. Let's Encrypt validates ownership via HTTP-01 (a file served at /.well-known/acme-challenge/...) — if the domain's A/AAAA records don't point at the cluster's nodes yet, the validation can't reach the file and the request fails.

If a manager shows 'No Certificate' for a domain you've just pointed at the cluster:

1. Confirm DNS is pointing at the cluster (the domain router has the relevant node assignment).
2. Click 'Request certificate' on the manager to trigger a fresh attempt.
3. If it still fails, the 'View Request Detail' link on the manager's last run shows the task collection with the underlying error.

Use cases by target group