Certificates across your fleet

There are two administrator screens for certificates and they answer two different questions. Servers → the server → Certificates shows every certificate on one machine. Servers → Certificates shows what expires soon or cannot be issued, across every machine you may see.

What a customer sees of their own website is separate; that is SSL and certificates. Both screens here are for server administrators without exception, and that is deliberate: a certificate list at machine height is every tenant on that machine at once.

The machine's own certificate is in there too

The server page carries not only the websites but also the machine's hostname certificate — the one Postfix, Dovecot and the FTPS daemon present to the outside world. It used to appear nowhere, because the old view was a loop over websites and a hostname is not a website. That is precisely the certificate mail breaks on when it expires.

The order is severity, not the name

Every row is graded on the server into one word: insecure, expired, failing, expiring, incomplete, or ok. The same grade feeds the server page, the fleet page and the server advisor, so those three cannot come to different conclusions about the same certificate.

Both lists are sorted by that grade, worst first. A list sorted by name is a list somebody has to read all of. Above the list you can filter (all, expiring, problem, insecure) and set how far ahead to look; the fleet screen says plainly when there are more rows than it is showing.

A row opens, and says what happens on its own

Click a row and a panel slides open, ordered around one decision: press the button, or leave it alone. At the top is the state and one sentence about what is going to happen without you — that the authority does not open the renewal window for another week, say, or that this server has tried four times in vain and will try again.

Under that are the attempts the server wrote down, with the text the authority itself returned. Keys and tokens are taken out; the rest is literally what was said, because a polished summary of an ACME failure helps nobody.

What the buttons do

On a failing row you can retry: that asks for that one name again. On the server page you can have everything that is due picked up in one go — the same round that runs by itself overnight, only now. Both answer with a task, because an order at a certificate authority is a minute of somebody else's work; you follow it in the task centre.

What you do not do here is bulk-order across the whole fleet. The authority's rate limits are real, and they hit all your customers at once when you run through them.

How old is what you are looking at?

The lists come from the panel's stored copy rather than from a sweep of every machine — two hundred servers in series is not a page, and in parallel it is a thundering herd every time somebody presses refresh. So the top of the list says when it was last read, and the server page has a button to re-read that machine now.

# What is wrong on one machine, with the counts
curl -sS -H "Authorization: Bearer corecp_<prefix>_<secret>" \
  "https://panel.example.com/api/v1/nodes/srv1.example.com/ssl?filter=problem"

# The whole fleet, fourteen days ahead — every row names its server
curl -sS -H "Authorization: Bearer corecp_<prefix>_<secret>" \
  "https://panel.example.com/api/v1/ssl?days=14"

See also

• SSL and certificates — what your customer sees of their own website, and can do themselves.
• Reading the server advisor — where a machine's certificate row points.
• The fleet at a glance — the "certificates expiring soon" counter and where it comes from.
• Following background tasks — where a renewal round ends up.