Certificate deployment verification compares the certificate intended for a service with the certificate observed at that service's public TLS endpoint. It is one part of renewal assurance, not proof that the entire ACME workflow or every termination point succeeded.
The 64-day and 45-day certificate timeline
Let's Encrypt's 7 October announcement sets 14 October 2026 for 64-day staging issuance and 10 February 2027 for the production default. These are issuance changes, not an instruction to replace every existing certificate on the same day.
The default classic profile is scheduled to move to 45 days on 16 February 2028. Existing valid certificates are not being revoked as part of the 64-day transition. Teams using other profiles should check the lifetime that actually applies to their client.
| Date | Change | Preparation |
|---|---|---|
| 14 October 2026 | 64-day staging issuance | Rehearse the end-to-end process in an isolated test environment |
| 10 February 2027 | Default 64-day production issuance | Confirm client scheduling and deployment verification |
| 16 February 2028 | Default classic profile moves to 45 days | Keep automation lifetime-aware rather than tied to 90 days |
Audit renewal timing before changing certificates
Check whether your ACME client supports ACME Renewal Information (ARI), and follow its documented scheduling behavior. If it does not, Let's Encrypt recommends renewal around two thirds of the current certificate lifetime, rather than assuming a fixed 90-day cycle.
Review timers, wrapper scripts and operational runbooks together. The important question is not whether a job runs, but whether its decision about when to renew still fits the certificate it receives. Keep retries and failure reporting visible to the responsible operator.
Use staging for ACME renewal testing, not production trust
Let's Encrypt recommends testing in staging first. Its staging roots are not included in ordinary client trust stores. Keep test trust configuration isolated; do not add staging roots to the trust store used for normal browsing or production activity.
A rehearsal should exercise your actual deployment path where safely possible. A test issuance alone does not establish that a load balancer, mail service or other TLS terminator loaded the resulting certificate. Document which steps the rehearsal covered and which still require production-safe observation.
Checklist: separate issuance from deployment
- 1. Record the intended certificate
Keep the expected leaf certificate's SHA-256 fingerprint, validity interval and intended hostname/service. A fingerprint is public certificate metadata; never upload a private key or ACME credential.
- 2. Confirm the deployment hook
Check its result and destination. Issuance logs and installation logs answer different questions; preserve both without copying secrets into an inventory.
- 3. Check the service reload
Confirm the TLS termination service loaded its updated configuration. If the hook failed or a process retained an old certificate, a successful renewal job can still leave the old certificate exposed.
- 4. Observe the public endpoint
Inspect the exact authorized hostname, selected service and port. Compare the presented leaf fingerprint with the intended certificate, then review validity and the presented chain. Use the intended SNI hostname, not an unrelated direct-IP connection.
- 5. Record the result and gaps
Retain observation time, scanner method, inspected addresses, errors and exclusions. Repeat approved checks for separately selected termination points; one result is not proof that every replica or internal service changed.
What independent TLS certificate monitoring adds
Renewal-job monitoring tells you whether automation reported a result. External certificate observation tells you what a selected service presented from the scanner's vantage at a particular time. Treat those as complementary evidence, and investigate disagreement rather than turning either into a universal success flag.
A changed fingerprint is not automatically the expected certificate. It may reflect a different chain or deployment path. Compare the intended leaf explicitly and keep observation age visible; a historical successful scan does not establish current presentation.
What Cipher Discovery supports today
The public scanner provides one-off TLS/X.509 inspection for an explicitly selected authorized public service. Use its observed certificate metadata for manual comparison with your expected fingerprint. Supported service profiles include HTTPS, SMTP STARTTLS, IMAPS, POP3S and LDAPS; a scan never selects all of those implicitly.
The private workspace supports opt-in daily or weekly discovery, drift, and in-workspace expiry warnings for last observed leaf certificates. Record the intended public leaf DER SHA-256 fingerprint; a strictly newer same-scope scan compares every observed leaf with it. Partial coverage and stale or failed observations remain visible and cannot establish full deployment. Fingerprint matching is separate from PQC migration verification.
Alerts are recalculated when the workspace is loaded or refreshed, with observation age and 14/7/1-day thresholds. The product does not automate ACME issuance, deploy certificates, or currently deliver certificate-expiry email/webhook alerts. A match confirms only the observed scan scope, not every replica, trust validation or the success of the renewal job.
Frequently asked questions
When do Let's Encrypt 64-day certificates become the default?
The announced production default date is 10 February 2027. The staging switch is scheduled for 14 October 2026. Check the controlling announcement and the profile your client uses.
Does a successful ACME dry-run verify the deployed certificate?
Not by itself. Check which deployment and reload steps your test actually ran, then independently inspect the certificate served by the intended endpoint.
Does a new fingerprint prove renewal succeeded?
No. Compare the observed leaf fingerprint with the intended certificate and retain exact scope, coverage and time. A change alone is not proof of the expected deployment.
Does Cipher Discovery renew certificates or send expiry emails?
No. It observes public TLS properties and supports scoped scheduled discovery and drift in the private workspace. It is not an ACME client or an expiry email-alert service.
Can I upload a private key for verification?
No. Use public certificate metadata such as the leaf fingerprint. Never submit private keys, ACME tokens, credentials or plaintext secrets.