Deutsch
A certificate can renew successfully on disk and still expire in front of users. The renewal client may write new files while a reverse proxy continues serving the old certificate, a DNS challenge may fail after an account handover, or an alert may go to someone who no longer owns the service. Preventing those failures requires more than an expiry date: it requires an inventory, named owners, observable automation, a tested reload path, and an emergency procedure.
This checklist is for customer-managed websites, APIs, dashboards, and reverse proxies on a VPS. Virtarix supplies self-managed infrastructure and server access; the customer remains responsible for installing, configuring, securing, updating, and operating the certificate tooling and the software that serves each certificate.
The useful way to frame the problem
Treat certificate renewal as a chain with four separate outcomes:
- Validation succeeds. The certificate authority can verify control through the configured HTTP, DNS, or other supported challenge.
- Issuance succeeds. A new certificate and its chain are written to the expected location.
- Deployment succeeds. The correct service loads the new certificate without breaking its configuration.
- External verification succeeds. A client connecting to every public hostname receives the intended certificate, chain, and validity dates.
An expiry monitor proves only part of that chain. A green renewal timer does not prove that DNS credentials still work, the renewed files are readable by the service, the reload completed, or the public endpoint changed. Record evidence for each step and make the final external check the definition of a completed renewal.
Name the certificate owner
Assign ownership by role, not by an informal statement that “the server handles it.” One person may hold several roles in a small team, but every role still needs a primary owner, a backup, and a recoverable access path.
| Role | Accountable for | Evidence to retain |
|---|---|---|
| Service owner | Business impact, maintenance window, and escalation priority | Current contact and service criticality |
| Renewal owner | Renewal client, schedule, challenge method, logs, and remediation | Last successful test and last successful renewal |
| DNS-account owner | Zone access and DNS API credential recovery for DNS validation | Account owner, backup administrator, and recovery route |
| Incident owner | Coordinating response before expiry or after a failed deployment | Paging route, backup contact, and escalation deadline |
Use team-controlled accounts for DNS and certificate-authority access where the provider supports them. Remove stale personal accounts after ownership is transferred and tested. Store recovery codes or equivalent recovery material in the team's approved secret system; do not place credentials or private keys in the certificate inventory.
Ownership must also survive absence. The backup owner should be able to locate the inventory, read the renewal logs, access the required DNS or hosting account, run the documented test, and contact the incident owner without relying on the primary owner's device or memory.
Map every certificate
Build the inventory from both directions: enumerate configured certificate files and renewal-client records on the server, then enumerate public hostnames and listeners from DNS, proxy, load-balancer, and application configuration. Reconcile the two lists. This catches unused certificates as well as endpoints that are missing from automation.
Keep the issuance and expiry fields together:
| Domain/SAN | Service | Issuer | Renewal method | Expiry |
|---|---|---|---|---|
app.example.com
|
Public reverse proxy | Certificate authority name | ACME HTTP-01, DNS-01, or documented manual method | UTC date and remaining days |
Link that row to its operational ownership and deployment fields:
| Domain/SAN | Owner | DNS owner | Reload target | Last test |
|---|---|---|---|---|
app.example.com
|
Primary and backup renewal owners | Team account or Not required
|
Exact service and listener | UTC date, result, and evidence link |
For a multi-domain certificate, record every Subject Alternative Name rather than only the common name. If the same certificate is installed on several endpoints, list every reload target and test every endpoint. Also record whether a service terminates TLS locally or receives traffic through another proxy; otherwise a team may renew the wrong layer.
Review the inventory after adding or removing a domain, changing DNS providers, moving a listener, replacing the renewal client, changing a service account, or handing the system to another team. A scheduled inventory review is useful, but configuration changes are the events most likely to make renewal data stale.
Confirm renewal visibility
Use two independent signals:
- External expiry monitoring connects to each public hostname with the correct Server Name Indication and measures the certificate actually served to clients.
- Renewal-job monitoring records whether the scheduled job ran, whether it attempted a renewal, its result, the certificate name, a safe error summary, and where its detailed logs can be found.
Send expiry alerts early enough for the team to investigate access, validation, and rate-limit problems before the certificate becomes urgent. Use more than one threshold, route the later threshold with higher urgency, and alert separately when the renewal job has not run within its expected interval. The inventory should identify who receives each alert and who is paged if the first owner does not acknowledge it.
Do not infer renewal success only from a zero process exit or the presence of new files. Some clients exit successfully when no certificate is due, and a renewed file can remain undeployed. Store the old and new certificate serial number or SHA-256 fingerprint, validity window, deployment result, and external observation. Do not put private-key material in logs.
Monitor the prerequisites as well: DNS API authentication, filesystem permissions, free space, time synchronisation, challenge reachability, renewal-client scheduling, and access to the certificate authority. A failure in any one of them can surface first as an expiry alert.
Certbot example: inspect and test renewal
The commands in this example are specific to Certbot and should be run only on a host where Certbot is the documented renewal client. Confirm the installed version and read the Certbot renewal documentation before changing options.
sudo certbot certificates
sudo certbot renew --dry-runCertbot documents renew --dry-run as a test against the Let's Encrypt staging service by default. It can run pre- and post-hooks and may temporarily change and roll back web-server configuration; deploy hooks do not run during a dry run unless explicitly enabled. Run it in a controlled window, inspect the complete result, and test the real service reload path separately. Do not add --force-renewal to a routine test: it requests live renewals regardless of certificate age and can consume certificate-authority limits.
Test the reload path
Issuance and deployment should be separate observable steps. After a new certificate is issued:
- Confirm that the new certificate covers the intended hostname set and that its chain, validity dates, serial number, and fingerprint differ as expected.
- Confirm the service account can read the certificate and private key without broadening permissions.
- Run the service's native configuration test before a reload.
- Reload the exact web server, application gateway, or reverse proxy that terminates TLS. Use a restart only when the software requires it and the maintenance plan permits the interruption.
- Connect to every public hostname and relevant port from outside the service, using the correct SNI value.
- Compare the served certificate's names, issuer, serial or fingerprint, validity dates, and chain with the certificate that was issued.
- Run an application smoke test through TLS and record the result.
The following OpenSSL command is a generic inspection example for an HTTPS endpoint. Replace both instances of app.example.com; do not treat the output as proof until it has been compared with the intended certificate record.
openssl s_client -connect app.example.com:443 -servername app.example.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates -serial -fingerprint -sha256Test every terminating endpoint. Round-robin DNS, multiple proxies, containers, or copied certificate files can leave one node serving an old certificate while another is current. If the renewal client supports a deploy hook, make the hook run only after successful issuance and have it fail visibly when the configuration test, reload, or post-deployment verification fails.
Keep DNS and account access aligned
DNS validation depends on more than a valid API token. Record the authoritative DNS provider, account owner, zone, credential location, token scope, renewal client or plugin that consumes it, and the recovery route if the primary owner is unavailable. Verify that the credential can update only the required zone or records where the provider supports scoped access.
When transferring ownership, create and test the replacement access before removing the old credential. Then revoke the old token, confirm that renewal uses the replacement, and update the inventory. Do not leave a personal DNS credential in a root-owned configuration file simply because automation still works.
Account recovery must be tested without exposing secrets. Confirm that the team controls the account email or identity-provider group, backup administrators exist, multi-factor recovery is documented, and the incident owner knows how to reach the DNS provider. A certificate problem close to expiry is the wrong time to discover that the only recovery code is on a former employee's device.
Emergency procedure for a failed renewal
Use a dated incident record and keep the old, currently served certificate in place while it remains valid and the service is healthy. Do not replace working files with an unverified manual result.
- Confirm impact and time remaining. Inspect the certificate served externally, note the UTC expiry time, affected hostnames, service owner, and incident owner.
- Identify the failed stage. Separate validation, issuance, file deployment, service reload, and external verification. Preserve the exact safe error and relevant log location.
- Protect service continuity. Pause repeated automated attempts if they are causing a retry storm or certificate-authority limits. Do not delete the certificate files, keys, or renewal configuration already serving the endpoint.
- Repair the narrow dependency. Restore challenge reachability, DNS access, filesystem permission, disk capacity, renewal configuration, or service configuration as appropriate. Test the repair before issuing a live certificate.
- Perform a temporary manual renewal only when supported. Follow the current renewal-client and certificate-authority documentation, use the existing certificate identity where appropriate, and record every changed option. Avoid creating an unrelated duplicate certificate as an undocumented workaround.
- Validate before deployment. Check hostname coverage, chain, validity dates, serial or fingerprint, file ownership, and the service's native configuration test.
- Reload and verify. Reload the exact TLS-terminating service, inspect the externally served certificate for every hostname and endpoint, and complete an application smoke test.
- Escalate while time remains. If the failure is not resolved by the documented internal deadline, contact the incident owner, DNS or certificate-authority account owner, and the relevant software vendor or provider. Virtarix does not manage the customer's certificate software or renewal incident.
If deployment breaks the service, revert only the deployment change: restore the last-known-good service configuration or certificate reference, run the native configuration test, reload, and verify externally. A rollback to an already expired certificate does not restore trustworthy service, so continue the incident and escalation path until a valid certificate is served. After recovery, remove temporary credentials, restore automation, run a safe renewal test, and document the root cause and prevention action.
SSL renewal ownership checklist
- [ ] Every Domain and SAN appears in the certificate inventory.
- [ ] Each row names the service, issuer, renewal method, expiry, primary owner, backup owner, DNS owner, reload target, and last successful test.
- [ ] Public endpoints have external expiry monitoring with staged alert thresholds and an escalation owner.
- [ ] Renewal jobs expose last-run time, result, attempted certificate, safe failure reason, and detailed log location.
- [ ] DNS and certificate-authority access uses recoverable team ownership; stale personal credentials are revoked.
- [ ] The renewal method has a controlled test that covers its current challenge and account access.
- [ ] The service configuration test, reload command, and externally observed verification are documented and exercised.
- [ ] Multi-endpoint services verify every TLS terminator rather than one convenient hostname.
- [ ] The emergency procedure preserves the working certificate, isolates the failed stage, and defines escalation deadlines.
- [ ] Post-incident work removes temporary access, restores automation, and updates the inventory.
When a VPS is the right fit
A VPS is appropriate when a team needs direct control of a customer-managed TLS terminator, renewal client, service configuration, file permissions, and monitoring. Full root access makes those controls possible, but it also leaves the customer responsible for operating them correctly. Virtarix does not provide managed certificate issuance, renewal, monitoring, service reloads, incident response, or software-vendor support.
One VPS is still one failure domain. A valid certificate does not make the application, proxy, storage, or network redundant. If a service requires independent availability during host maintenance or failure, design and test separate capacity, certificate deployment, DNS or traffic steering, and recovery rather than assuming certificate automation supplies redundancy.
FAQs
Is an expiry monitor enough?
No. An external monitor should prove what clients are served, while renewal-job monitoring proves whether automation ran and why it failed. You also need evidence that the correct service loaded the new certificate and that an application smoke test passed.
Who should own renewal when DNS and the server belong to different teams?
Name separate renewal, DNS-account, service, and incident owners. The renewal owner coordinates the end-to-end test; the DNS owner maintains recoverable validation access; the service owner approves impact-sensitive reloads; and the incident owner escalates when the normal path misses its deadline.
Should certificates renew directly on the production server?
That depends on the renewal client, validation method, and service architecture. Whatever design you choose, document where issuance occurs, how certificate files reach each TLS terminator, who can access the private key, and how deployment and external verification fail visibly.
What proves that a renewal succeeded?
The public endpoint must serve the intended hostname coverage, chain, validity window, and serial number or fingerprint after the correct service reloads. A new file timestamp, a successful scheduled job, or a calendar reminder is not sufficient proof by itself.
Can a snapshot replace the certificate recovery procedure?
No. Every Virtarix VPS and VDS includes one backup and one snapshot, but those do not replace customer-owned copies or an independent recovery plan. Restoring an old server state can also restore stale certificates, credentials, DNS settings, and renewal configuration, so certificate recovery needs its own current evidence and procedure.
What should be reviewed after a team handover?
Reconfirm every owner and backup, DNS and certificate-authority account recovery, secret location, renewal schedule, challenge method, alert routing, service configuration test, reload target, external verification command, and emergency escalation deadline. Test the replacement access before revoking the former owner's credential.
