SSL Status

The guided TLS page: everything this deployment serves over TLS, on one page. Until :443 serves a trusted certificate that renews itself, the page is a seven-rung ladder — Let's Encrypt accounts, DNS credentials, a certificate profile, a proof run on staging, the real issuance, activation, and auto-renew — with the current rung open and its form right there. Once every rung is done, the same page collapses to the status of :443. The scanner ingress (:8443) is always shown below, read-only: it follows the published scanner anchor and is never changed from here.

Fields & columns

Name	Description
`Rung status`	Done (with the evidence that satisfied it — a run number and date, a certificate generation), current (open, with its action), locked (a later rung), or optional (the staging proof once these credentials have already produced a real certificate)
`Fault banner`	Shown above the ladder only when something outranks it: an operation in progress, an unverifiable TLS state, a diverging scanner ingress, a rolled-back activation, or a failing renewal. The banner links to the runbook or the page that resolves it
`:443 status line (configured mode)`	Issuer, trust, expiry and next renewal of the served certificate, the active generation, a Roll back action when a previous generation exists, and "Show steps" to reopen the ladder
`Scanner ingress (:8443)`	The anchor generation and fingerprint the ingress follows, and whether every verification leg agrees. Read-only by design
`HTTPS port`	The port the reverse proxy terminates TLS on

How to

Get a trusted certificate on :443 for the first time

Rung 1: set a contact email on both Let's Encrypt accounts. Expiry notices go there.
Rung 2: add your DNS provider's credentials and click Test. The "Hostname to test" is the host you are going to certify.
Rung 3: create the profile. The public host is filled in; pick the credential set.
Rung 4: run the staging proof. Required the first time a credential set is used; it costs nothing and proves the whole path.
Rung 5: issue for real. This promotes the profile to the production account and stages a trusted certificate — nothing is served yet.
Rung 6: activate. The change is verified on the wire and rolled back automatically if :443 does not serve the new certificate. Open a NEW browser window to see it: a tab opened earlier keeps its old connection.
Rung 7: turn on auto-renew, so you never do this again.

Issue a second certificate with credentials that already worked

Create the new profile on rung 3.
Rung 4 is now optional: "Prove on staging first" is ticked by default. Untick it to go straight to a real certificate — these credentials have already produced one.
Continue with rungs 5 to 7 as before.

Recover from a rolled-back activation

The fault banner names the generation whose activation was rolled back and the reason.
A rollback means :443 did not actually serve the new certificate, so mipo restored the previous one. The failed candidate stays in the inventory.
Common causes: the certificate does not cover the public hostname, its private key file is missing, or the reverse proxy did not reload.
Fix the cause, then activate again from rung 6 or from Certificates.
If the banner says the TLS state is unknown after a failed rollback, do not retry: check :443 by hand and follow the TLS runbook.

Gotchas

Issuing and uploading never change what is served. Every change to :443 is an explicit activation that you confirm with a re-authentication.
After activating, your current browser tab may still show the OLD certificate: it keeps the connection it opened earlier. Open a new window or restart the browser to see the new one. Nothing is wrong.
A successful real issuance retires the "test the credentials" rung on its own — a real certificate proves the credentials better than the Test button can.
The staging proof is required the first time a credential set is used and optional afterwards, on purpose: Let's Encrypt production locks an account out for an hour after a few failed validations, so an unproven credential is tried on staging first.
A Let's Encrypt staging certificate is proof only. It lands in the inventory reading Ready, but it is never activated on any binding, never a rollback target and never auto-renewed.
The scanner ingress follows the published anchor and is rotated by mipo.sh. Nothing on this page writes it — activating a certificate on :443 never changes what scanners are handed. That coupling is what took the scanner fleet down on 14 September 2026.
Dates are absolute, never "in 30 days" — a renewal window you have to compute is a renewal window you get wrong.
The other SSL pages are still there for editing one thing directly or reading the run history; this page is the guided path through all of them.

API calls (10)

Method	Path	Description
GET	`/api/admin/ssl`	Read both bindings, the derived next step, the ladder and the HTTPS port
GET	`/api/admin/ssl/acme-accounts`	The two Let's Encrypt accounts for rung 1
GET	`/api/admin/ssl/dns-credential-sets`	The credential sets for rungs 2 and 3
GET	`/api/admin/ssl/certificate-profiles`	The profiles for rungs 3 to 7
GET	`/api/admin/ssl/certificates`	The inventory the served generation and the newest production certificate are resolved against
POST	`/api/admin/ssl/certificate-profiles/:id/issue`	Rung 4: the staging proof run
POST	`/api/admin/ssl/certificate-profiles/:id/promote`	Rung 5: promote to production and issue the trusted certificate
POST	`/api/admin/ssl/bindings/ui/activate`	Rung 6: activate on :443, verified
PUT	`/api/admin/ssl/certificate-profiles/:id`	Rung 7: turn on auto-renew
POST	`/api/admin/ssl/bindings/ui/rollback`	Re-activate the previous generation, verified

Certificates — The inventory every rung 5 and 6 certificate lands in, and where an upload is staged
Certificate Profiles — Edit a profile directly, or watch a run's steps
DNS Credential Sets — Edit provider credentials directly
Issuance Runs — The full history behind the rungs: every issuance attempt, its steps and its raw provider traffic