Automated certificate renewal
Every certificate gets a renewal date the moment it is issued. When the date arrives, aethercert queues the renewal, the agent generates a new key, the certificate authority signs it, and the deploy target installs it - without anyone opening a ticket.
Automatic renewal is included in every plan. Community renews from Let's Encrypt; other authorities require Standard or higher. See plans and limits
What it does
Renewal is scheduled per certificate, a configurable number of days before it expires: 30 by default, anywhere from 1 to 90. The control plane queues a renew job for the agent that owns the certificate. The agent generates a fresh key pair locally, requests the certificate from the authority the certificate is configured for, and runs its deploy target.
The same flow works for publicly trusted ACME authorities, for an internal CA - Active Directory Certificate Services through the CA connector, an internal ACME server or a REST signing endpoint - and for PSW Group orders placed by the certificate connector.
How it works
- 01
Scheduled
The scheduler finds certificates inside their renewal window and queues one renew job each.
- 02
Picked up
The agent sees the queued job on its next check-in. Work that is waiting shortens the check-in to seconds.
- 03
Issued
New key and CSR on the agent; ACME challenge, CA connector request or commercial order, depending on the authority.
- 04
Installed and recorded
The deploy target runs, the new serial, fingerprint and expiry are recorded, and the next renewal date is set.
Key capabilities
Renewal window per certificate
From 1 to 90 days before expiry. Shorter-lived certificates can renew later, longer-lived ones earlier.
Retries with classification
A job is retried up to three times. Rate limits and network errors are treated differently from a misconfiguration that will never succeed.
Leases
A job claimed by an agent that then disappears is released again after its lease expires, so a crashed host does not hold a renewal hostage.
Key types
EC P-256 by default; EC P-384, RSA 2048 and RSA 4096 when a system needs them. Community uses EC P-256.
Reissue and revoke
Reissue a certificate on demand - after a key compromise or a SAN change - or revoke it through the same job queue.
Public and private authorities
Let's Encrypt, Google Trust Services, ZeroSSL, SSL.com, Actalis, any ACME server, AD CS, a REST CA and PSW Group.
Compared with renewing by hand
| By hand | With aethercert |
|---|---|
| Expiry dates live in a spreadsheet or a calendar reminder. | Each certificate carries its own renewal date and is queued automatically. |
| A new CSR is created on whichever machine was nearest. | The agent on the target host generates a fresh key for every renewal. |
| Renewing and installing are two separate tasks, often by different people. | Issue and deploy run as one job; the next renewal is scheduled when it succeeds. |
| A failed renewal is discovered when users report a browser warning. | Failures are retried, logged and, on Pro plans, pushed to your monitoring. |
Authorities and validation methods
Renewal works with every certificate authority aethercert connects to and every challenge type the agent supports.
Security considerations
Fresh key every time
Each renewal creates a new key pair on the agent. Key files are written with owner-only permissions.
Single-use signing tokens for AD CS
The CA connector accepts a request only with a short-lived token minted for that job and checks the requested names against it.
Hardened challenge handling
HTTP-01 tokens from the CA are validated before they become file names, so a hostile CA response cannot write outside the webroot.
Example: renewal of app.example.com
A Let's Encrypt certificate with a 30-day renewal window, deployed to nginx.
day 60Renewal window opens; a renew job is queued for agent web-01.keyweb-01 generates a new EC P-256 key and CSR.dns-01The TXT record is published through your DNS provider and validated.deploynginx package writes the files, reloads nginx and checks the served certificate.recordedNew expiry stored; next renewal scheduled 30 days before it.
Frequently asked questions
Automated renewal
When does a certificate renew?
A configurable number of days before expiry, 30 by default and anywhere from 1 to 90. The window is set per certificate or per certificate policy.
What happens if a renewal fails?
The job is retried up to three times. If it still fails, it is marked failed, an event is written to the log and - on plans with monitoring integrations - an alert is sent. The old certificate stays in place.
Does renewal reuse the old key?
No. The agent generates a new key pair for every renewal.
Will this cope with shorter certificate lifetimes?
Renewal is driven by each certificate's own expiry date and renewal window, so shorter lifetimes mean more frequent, but equally unattended, renewals.
Stop tracking expiry dates
Issue your first certificate and its renewal is already scheduled.
Community plan, no card required. Open registration - your account is ready in a few minutes.