Automated renewals
Renew certificates before expiry — and verify the replacement actually works.
Renewal is scheduled from the certificate’s notAfter, not from a 90-day habit. Default lead time is 30 days. A replacement is not done until validation, issuance, optional deploy and verification succeed — or Action Required says they did not.
Scheduling
renew_before_days defaults to 30 (CERT_RENEW_BEFORE_DAYS). Issuance stores next_renewal_at = notAfter − that many days. The hourly job selects rows where auto_renew is true, status is active, and next_renewal_at <= now(), marks them renewing, and dispatches RenewCertificate.
CA/Browser Forum Baseline Requirements cap public subscriber certificates at 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. Validation data reuse shrinks on the same dates (to 10 days in 2029). Certificates already issued keep their original notAfter. This page does not tell you that you are already on 47-day leaves.
Attempts, retry, validation, issuance
Renewal creates a new order for the same identifiers and validation method. Challenges are presented again — Cloudflare can rewrite TXT; otherwise the order shows the records. Failures store error_code on the order, set the certificate to renewal_failed, and emit certificate.renewal_failed. Force a new attempt with POST /api/v1/certificates/{id}/renew.
Deployment and endpoint verification
certificate.renewed means the CA (or sandbox) produced a replacement. A connected deploy target still uploads, binds and reloads. Supported SSH deploys inspect the live TLS fingerprint and keep .prev for rollback. If you skip that path, inventory will not invent a green “verified” state.
Failure escalation and history
Action Required is the queue. Webhook deliveries retry up to eight times. Daily certificates:notify-expiring can mail courtesy notices. Orders and audit events are the history — not a screenshot of a CA portal.
| Hostname | Status | Not after | Renewal | Attention |
|---|---|---|---|---|
| shop.demo-merchant.test | Active | 2026-10-20 | Scheduled · 30 days before | Expiring · 30 days |
| api.demo-merchant.test | Renewal failed | 2026-09-28 | Attempt 2 · dns_record_not_found | Action Required |
| pay.demo-merchant.test | Active | 2027-02-02 | next_renewal_at 2027-01-03 | Verified handshake |
| legacy.demo-internal.test | Imported | 2026-10-12 | Unmanaged | No connector |
Related Solutions and Integrations
Solutions this product surface is built for:
Customer-facing integrations to open next:
Questions people actually ask
How many days before expiry do you renew?
Default 30 days, stored as renew_before_days / next_renewal_at. Configure CERT_RENEW_BEFORE_DAYS. This is not hard-coded to a 90-day Let’s Encrypt habit.
Do you assume 90-day certificates?
No. Public maxima are 200 / 100 / 47 days on 15 March 2026 / 2027 / 2029. Let’s Encrypt may still issue ~90-day leaves. The scheduler uses your notAfter and renew_before_days.
What if DNS changed since issuance?
Validation fails, status becomes renewal_failed, and certificate.renewal_failed is delivered. Re-open the DNS checklist. Do not pretend the old CNAME still exists.
Does renewal deploy the new leaf?
Only if a deploy target is connected and you run that path. The webhook means issuance succeeded. Verify the handshake before you tell a customer HTTPS is updated.
Can I force a renewal?
Yes. POST /api/v1/certificates/{id}/renew or use the dashboard. Useful in test and after a failed attempt you have since fixed.
Where do I see attempts?
Orders store status and error_code. Webhook deliveries store attempt and http_status. Audit records the mutation.
What about short-lived certificates?
CA/Browser Forum defines short-lived subscriber certificates separately (at most 7 days from 15 March 2026). This scheduler is built around renew_before_days, not around a 7-day product. Do not tell auditors you are on 47-day certificates unless you chose that lifetime.
Are expiring certificates emailed?
A daily certificates:notify-expiring command exists. Treat webhooks and Action Required as the control; email is a courtesy.
Schedule the next leaf before browsers do.
Turn auto-renew on, subscribe to renewal_failed, and verify the handshake after deploy.