SSL and Certificate Expiration Checklist for IT Teams

Why expired certificates hurt

What to put in your certificate inventory

Before you can track certificate expiration, you need a living inventory. Aim for one row per cert (or per hostname where that is clearer), with enough context that a teammate can renew without archaeology. If you are still building a first inventory for other date-bound obligations, start with how to track expiration and renewal dates without missing one.

Include at least:

• Public SSL/TLS for customer-facing domains and APIs
• Wildcard certificates and which names they actually cover
• Internal or private CA certs used by apps, VPN, or service mesh
• Certificates terminating on load balancers or reverse proxies (not only on the origin)
• CDN / edge custom hostnames and any “bring your own cert” attachments
• Client certificates and mTLS material where partners or devices authenticate to you
• Adjacent date-bound material worth a light line item: code-signing certs, S/MIME, and other TLS client certs that share the same “expires and then breaks something” risk

For each item, capture: hostname or alias, environment (prod/staging/dev), issuer/CA, not-before / not-after dates, where it is installed, renewal method (manual, ACME, vendor console), and a named owner plus backup. Certificate expiration tracking fails when the spreadsheet lists domains but not the person who can rotate them. If those columns keep drifting, clean the columns before you treat the sheet as source of truth.

Checklist: inventory

• Export or crawl all public hostnames that serve HTTPS (apex, www, APIs, admin panels, partner portals).
• List wildcards and map which services depend on each wildcard.
• Document load balancer and CDN terminations separately from origin certs.
• Add internal TLS endpoints that users or jobs actually hit.
• Note client/mTLS and other date-bound certs with a short purpose note.
• Store issuer, serial or thumbprint, and file/secret location (vault path, LB listener, CDN hostname).
• Mark last verified date so stale inventory is visible.

Checklist: ownership

• Assign a primary owner per cert (person or on-call rotation, not “IT” as a blob).
• Assign a backup who can renew if the primary is out.
• Record the CA or vendor account that issues the renewal (and who has access).
• Clarify who approves DNS or change windows when validation or cutover needs them.
• Link related tickets or runbooks so renewal is not tribal knowledge.

Ownership is the difference between a calm TLS cert renewal and a domain SSL expiry that nobody claims until browsers scream.

Checklist: renewal lead times

• Set a default lead time by cert class (for example public DV vs EV vs internal CA vs vendor-managed).
• Account for DNS validation delays, change freezes, and multi-region cutovers.
• For wildcards and shared certs, plan extra time for every dependent service.
• Confirm ACME or auto-renew is actually succeeding — do not assume “set and forget.”
• Document rollback: previous cert retention, LB dual-cert windows, CDN propagation checks.

Lead time is process, not panic. Teams that renew only when monitoring turns red inherit every CA and change-control delay at once.

Checklist: monitoring vs calendar

• Prefer automated expiry probes on public endpoints where possible.
• Keep a calendar or reminder sequence as a backstop for internal certs and non-HTTP TLS.
• Alert more than one person; single-inbox alerts get ignored on vacation.
• Treat “cert renewed in CA portal” and “cert live on the terminating hop” as different events.
• Review false negatives: monitoring the wrong hostname, SNI, or CDN edge.

Monitoring catches what is exposed; calendars catch what probes cannot see. Use both for a complete IT certificate inventory program.

Checklist: staging / prod parity

• Confirm staging renewals do not silently use different CAs, wildcards, or shorter lifetimes.
• Mirror termination points (LB vs origin vs CDN) between environments where feasible.
• Test client trust stores and pinned certs in staging before prod cutover.
• After prod renewal, verify staging still matches the intended pattern so the next cycle stays predictable.

Parity gaps are a classic source of “worked in staging” TLS failures.

Checklist: vendor / CA process

• Know the renewal path: ACME, console reissue, CSR + ticket, or managed cert product.
• Store validation requirements (DNS TXT, HTTP-01, email) and who can fulfill them.
• Track rate limits, approval SLAs, and business-hours-only CA support if relevant.
• Keep emergency contacts for the CA or CDN support path.
• Retire unused certs so inventory noise does not hide real expiry risk.

Software and vendor renewals follow the same ownership and notice logic. If that lane is also noisy, use the software renewal review checklist.

Checklist: post-renewal verification

• Confirm the new not-after date on the actual terminating hop (LB, CDN, proxy), not only in the CA UI.
• Hit key hostnames from outside your network; check chain and intermediate completeness.
• Exercise critical API and partner callbacks that enforce TLS strictly.
• Update inventory dates, owner notes, and next reminder sequence.
• Close the loop: remove old certs only after traffic and rollback windows are clear.

Verification is how you prevent expired certificates from recurring under a false sense of completion.

Suggested reminder cadence

As practical advice for IT/ops generalists — not a product feature list — many teams use escalating reminders such as 90 / 60 / 30 / 14 / 7 days before expiry:

90 days

Confirm inventory row, owner, and renewal method; fix gaps while there is slack.

60 days

Start renewal or validate that auto-renew still works; book change windows if needed.

30 days

Complete issuance and stage the new cert where dual-running is supported.

14 days

Cut over production paths; verify chains and dependent services.

7 days

Final check that every hostname in scope shows the new expiry; escalate if anything still shows the old date.

Adjust cadence for short-lived ACME certs (often 60–90 day lifetimes) versus longer internal or code-signing certs. The goal is sequenced human attention, not a single calendar ping the morning of expiry.

Frequently asked questions