Start with a public-hostname inventory
Do not start with certificate files, invoices, or a calendar reminder. Start with the hostnames that users, clients, integrations, crawlers, and payment flows actually reach. A certificate can renew successfully on one server while a CDN, load balancer, stale DNS record, or forgotten client domain keeps serving the old certificate.
- Prioritize app, API, checkout, identity, docs, status, CDN, webhook, and client-facing hostnames.
- Separate production from staging, old campaign domains, and parked names so urgent alerts stay meaningful.
- Tag each hostname by client, system, renewal owner, environment, or vendor before the list grows.
For agencies and small SaaS teams, the first useful inventory is often a spreadsheet of public hostnames plus owner tags. It does not need to be perfect before monitoring starts.
| Step | What to confirm |
|---|---|
| Inventory | List app, API, checkout, identity, docs, status, CDN, webhook, and client-facing hostnames. |
| External check | Verify the certificate served by the public endpoint with SNI, not only local files. |
| Alert windows | Use early and urgent thresholds such as 30, 14, 7, 3, and 1 days. |
| Incident check | Keep a one-off command or checker available for renewal reviews and customer reports. |
| Closeout | Close renewal work only after the public hostname serves the expected certificate and monitoring sees it. |
Check the certificate that is actually served
A useful monitor connects to the public endpoint with the correct SNI name and records the certificate returned by that handshake. The renewal date alone is not enough because the public endpoint might still serve an old certificate, miss a SAN, present an incomplete chain, or use a different issuer than the team expected.
| Field | Why it matters | What to do when it changes |
|---|---|---|
| Not After | Shows the expiry deadline. | Escalate when it crosses the 30, 14, 7, 3, or 1-day window. |
| Issuer | Confirms which CA or platform issued the served certificate. | Review after CA, CDN, hosting, or ACME changes. |
| SANs | Proves the hostname customers use is covered. | Reissue or change the binding if the hostname is missing. |
| Serial and fingerprint | Identifies whether the public certificate actually changed. | Compare before and after renewal or deployment. |
| Chain depth and trust state | Shows whether clients can build a trusted path. | Install the correct intermediate bundle or fix platform chain settings. |
| Validation failure class | Separates certificate problems from reachability problems. | Send to the team that owns DNS, networking, TLS, or renewal work. |
Use alert windows that match the certificate lifetime
Alert thresholds should leave enough time to fix automation failures, DNS validation problems, missing SANs, and vendor handoffs. A 30-day reminder is comfortable for a 90-day or 200-day certificate. It is much less comfortable for a 45-day certificate if nobody sees it until a few days later.
| Window | Purpose | Best channel |
|---|---|---|
| 30 days | Normal renewal planning and ownership checks. | Shared email or ticket queue. |
| 14 days | Confirm auto-renewal has started or schedule manual renewal. | Shared email plus a watched operations channel. |
| 7 days | Treat failed automation as an active operational risk. | Slack or signed webhook to ticketing. |
| 3 days | Escalate to the team that can deploy, reload, or call the vendor. | Watched Slack channel or incident workflow. |
| 1 day or expired | Customer-facing warning is imminent or active. | Critical operational route with delivery evidence. |
Keep a manual check for incident response
Automated monitoring should be the source of routine alerts, but operators still need a quick command for renewal reviews and incident triage. Use SNI when checking a hostname because many CDNs, load balancers, and shared hosts choose the certificate from the server name in the TLS handshake.
HOST=api.example.com
openssl s_client -connect $HOST:443 -servername $HOST -showcerts </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject -dates -fingerprint -sha256- Run the command before renewal to capture the old issuer, dates, and fingerprint.
- Run it after renewal from outside the hosting environment.
- If the command and browser disagree, check DNS, CDN proxying, load balancer backends, and SNI.
Close the renewal only after public verification passes
A renewal is not done when a CA issues the certificate. It is done when the public hostname serves the expected certificate, the SAN list covers the name, the validity dates moved forward, the trust chain validates, and the alert state changed as expected.
- Verify the public hostname, not only the server where the renewal command ran.
- Check every CDN, edge, load balancer, ingress, and origin that can terminate TLS for the hostname.
- Record the new fingerprint and expiry date in the inventory so the next renewal has a baseline.
- Confirm the monitoring system detected the new certificate; if it did not, the monitor may not be reading the same endpoint users reach.
Where Domain Trust Watch fits
Domain Trust Watch is built for the recurring part of this workflow: public-hostname checks, expiry windows, certificate snapshots, change detection, and alert delivery to email, Slack, or signed webhooks. It does not issue certificates or replace ACME automation; it verifies what the public endpoint serves and warns the team before certificate risk becomes a browser warning.
- Use the free SSL checker for a one-time read before or after renewal.
- Create monitors for hostnames that still matter after the immediate check is finished.
- Use delivery attempts when the team needs proof that a warning reached the configured channel.