Certificates

A certificate in aethercert is the definition of an identity plus everything needed to keep it valid: which names it covers, which authority signs it, where it is installed, and when it should be renewed. The control plane owns that definition; the agent owns the key.

Managed and external certificates

Manage > Certificates holds two kinds of record, and they behave very differently.

Everything below applies to managed certificates unless it says otherwise. External certificates have their own section further down.

Identity: common name and SANs

A certificate carries one common name and any number of subject alternative names. Modern clients validate against the SAN list, so a certificate covering example.com and www.example.com needs both - the common name alone is not enough.

With a verified domain selected on the certificate job, you enter only the label (app) and the domain is appended. That is not only convenience: it makes it impossible to produce a hostname the selected domain's DNS-01 credentials could not cover, which is one of the more common ways an issuance fails.

Wildcards (*.example.com) require DNS-01 validation, which requires a DNS provider connected to the domain. See Domains and DNS validation.

Key types

The key is generated fresh on the agent for every issuance, including every renewal.

The Free plan is limited to EC-256. An AD CS template can enforce a minimum RSA size of its own; the certificate job form filters the RSA options it knows are too small for the selected template.

Statuses

There is no separate "renewing" status. A renewal in flight leaves the certificate at its current status while a renew job runs; the existing certificate stays in place and keeps serving until the new one is deployed. Look at Manage > Jobs to see a renewal in progress.

A job retries automatically up to three attempts in total before the certificate is marked failed. See Jobs.

Renewal

Auto-renew is on by default. The control plane queues the renewal job a configurable number of days before the not-after date - 30 by default, and anywhere from 1 to 90 - and the agent then does exactly what it did at first issuance: new key, new CSR, validation, deployment.

Two things follow from that:

• Renewal is a reissue, not an extension. The new certificate has a new key and a new serial. Anything that pinned the old fingerprint has to stop doing that.
• The renewal window is your safety margin. With 30 days, a failing renewal has 30 days of retries and 30 days of your attention before anything breaks. Shortening it saves nothing and removes the margin.

Renew now on a certificate queues a renewal immediately, regardless of the schedule. Use it after fixing whatever made the last attempt fail, rather than waiting for the next scheduled attempt.

Editing and reissuing

Editing a certificate - changing its SANs, its authority, its deploy target - reissues it with the new configuration. There is no way to change the names on a certificate already signed; a different set of names is a different certificate.

Moving a certificate to a different agent is the same story: delete it and create it against the other agent. If several servers need the same certificate, that is what agent groups are for.

Revoking, deleting and hiding

Three different actions with three different consequences.

Neither revoke nor delete reaches onto the host to remove a deployed file or a store entry. Nothing aethercert does retracts a certificate a server is already serving.

Hiding is for external certificates you have decided you do not care about - a long-expired test certificate somebody left in a store - so the list keeps showing the ones that matter. It is stored server-side, so a hidden certificate stays hidden across sessions and for every member.

External certificates

Agents also inventory certificates that were already installed on their host, whoever put them there, and report them. They appear under Manage > Certificates with the source External, next to the ones aethercert issued.

The point is coverage. A certificate imported by hand two years ago, one issued by a tool that has since been retired, one inherited with the server: all of them get an expiry date and a warning before they lapse.

What is scanned

The operating system's own trust store is deliberately skipped - /etc/ssl/certs, /usr/share/ca-certificates and /etc/pki/ca-trust on Linux. Those are hundreds of root CAs nobody installed for that host to serve with, and listing them would bury the certificates that matter. The Windows CA and Root stores are enumerated, but only so a locally installed issuing CA shows up; the trust anchors themselves are filtered out.

What you get

Everything inside the certificate: subject and issuer broken out attribute by attribute, every SAN by kind (DNS, IP, email, URI), validity, serial, SHA-256 and SHA-1 fingerprints, public key and signature algorithms, key usage and extended key usage, basic constraints, key identifiers, policy OIDs, OCSP/CRL/AIA endpoints, and the certificate's own PEM. Plus every store and file the agent found it in, whether the host holds a private key for it, and when it was last seen.

Limits and tuning

External certificates are read-only. aethercert has neither their private key nor their issuance configuration, so there is nothing to renew, revoke or edit. Remove one from the host and it disappears from the list at the next scan. To take one over, use Create job on its row, which opens a certificate job pre-filled with its names.

A scan runs at most once every 6 hours and uploads only when the result differs from what was last uploaded, or when 24 hours have passed since the last upload - so it adds essentially nothing to an agent's traffic. Two settings in the agent's config.json tune it:

Both are documented in Agent configuration. "Sync now" in the Windows tray forces a scan without waiting out the 6-hour interval.