Certificate Expiry Runbook

A small date can stop a large workflow

A July certificate replacement notice from the GWDG status service required affected server certificates to be replaced by a fixed deadline. On July 22, the University of Freiburg reported certificate-issuance delays, including timeouts in an automated finalization step. Together they show why a renewal plan needs time for both normal automation and a controlled fallback.

The NIST TLS certificate management guidance treats inventory, monitoring, renewal, replacement, and incident response as a lifecycle. For operators, that lifecycle can touch ordering pages, payment endpoints, APIs, dashboards, digital displays, remote support tools, and vendor integrations.

Keep ownership and escalation visible through the ServingIntel support path.

Day 30: build the dependency inventory

Record hostname, certificate authority, serial or fingerprint, expiration, renewal method, private-key location, deployment targets, business owner, technical owner, monitoring rule, and rollback. Include endpoints reached by devices and integrations even when guests never see them.

Use the POS Digital Display replacement scorecard to identify screens and players that may trust a separate certificate store or have a different update path.

Day 21: prove renewal outside production

Renew or issue a test certificate through the real process. Confirm the full chain, subject names, key algorithm, validity dates, permissions, automated deployment, and reload behavior. Test from a representative client rather than only from the server. Map device ownership through ServingIntel hardware planning.

Day 14: stage the smallest safe change

Define the maintenance window, endpoints, change owner, validation owner, known-good certificate, backup location, rollback trigger, and communications route. Never copy private keys into a ticket, chat, or article record. Keep secrets in the approved scoped store and limit access to the deployment identity.

When the certificate protects an online journey, pair the runbook with the POS Websites reservation-flow exit test so the team verifies completion, not merely a green server response.

Day 7: rehearse failure and rollback

Simulate or review an expired, untrusted, and hostname-mismatched certificate.
Confirm monitoring identifies the exact endpoint and owner.
Deploy the staged certificate to a bounded target.
Run ordering, payment, reporting, display, and integration checks.
Restore the known-good state and confirm recovery.

Track related operating changes through ServingIntel News & Insights.

Change day: verify from the outside in

After deployment, verify DNS resolution, TLS negotiation, chain trust, hostname coverage, expiry, redirects, API calls, background jobs, device reconnects, and the full user journey. Check more than one network and retain timestamps, response evidence, deployed fingerprint, exceptions, and the next watch owner.

Keep the operating record connected in the ServingIntel Genesis platform.

Closeout checklist

Every known endpoint is inventoried and monitored.
The new certificate and chain match the approved package.
Guest, staff, device, and integration journeys pass.
The old certificate and key are retired according to policy.
Automation failure and rollback evidence are retained.
The next renewal owner and alert dates are assigned.

The bottom line: a certificate renewal is complete only when the exact endpoints, clients, and business journeys have been verified—not when a file was copied to a server.