Let's Encrypt 45-Day Certificates: A Practical VPS Migration Playbook

Let’s Encrypt 45-Day Certificates: A Practical VPS Migration Playbook

Most VPS teams are not broken by one huge outage. They are broken by small operational debts that pile up until one Tuesday night goes sideways.

Certificate renewal is one of those debts.

As the industry moves toward shorter certificate lifetimes, the old habit of “we renew every few months and hope it works” stops being safe. A 45-day world is not impossible, but it is less forgiving.

This guide is a practical playbook to make your TLS workflow boring again.

What changes in practice

Moving from longer validity windows to 45 days changes three things:

1. Renewal attempts become more frequent.
2. Detection windows become tighter.
3. Human-in-the-loop processes become riskier.

If your current process depends on someone remembering calendar reminders, that process is already outdated.

Four-phase migration plan

Think in phases, not heroics.

Phase 1: Inventory and ownership

Before automation, build a clear map:

• Which domains and subdomains terminate on which VPS
• Which ACME client each host uses (certbot, acme.sh, or integrated tooling)
• Where private keys are stored
• Who owns each certificate set (person or team, not “everyone”)

Output of this phase: one inventory file and one owner per certificate group.

Phase 2: Renewal reliability

Now make renewals predictable:

• Ensure your ACME client runs via a systemd timer or cron on each host.
• Move renew checks to daily cadence.
• Add deploy hooks to reload web services only after successful renewal.

Example for systemd-based certbot hosts:

systemctl list-timers | grep -i certbot
sudo certbot renew --dry-run

If --dry-run fails, you are not done. Fix DNS/API permissions, challenge paths, or web server routing first.

Phase 3: Monitoring and alerting

Automation without visibility is silent failure.

Minimum monitoring set:

• Alert if any certificate expires in less than 14 days.
• Alert if renew dry-run fails for two consecutive checks.
• Alert if web server reload command fails after renewal.

You can implement this with an external uptime monitor plus one local script that checks certificate dates from openssl.

Phase 4: Failure drills

Do at least one quarterly drill:

• Intentionally break ACME challenge validation in staging.
• Confirm alerts trigger.
• Confirm the runbook gets from detection to recovery in less than 30 minutes.

If the team cannot recover in drill conditions, production will be worse.

A weekly operating rhythm that actually works

You do not need a giant platform team. You need repetition.

• Monday: automated report of certificates expiring in 30 days.
• Wednesday: one host runs dry-run renew test.
• Friday: check unresolved cert warnings in incident tracker.

This rhythm keeps cert operations visible without stealing your entire week.

Common failure patterns and direct fixes

Here are the patterns we keep seeing on VPS estates:

1. DNS drift after a provider migration. Fix: codify DNS records in source-controlled IaC, not panel-only edits.

2. ACME challenge blocked by CDN or redirect rules. Fix: explicitly exempt /.well-known/acme-challenge/ from aggressive rewrites.

3. Service reload hook silently fails. Fix: make deploy hooks return non-zero on failure and emit logs to your alert pipeline.

4. One engineer owns all TLS knowledge. Fix: publish a one-page runbook and rotate ownership monthly.

Minimal runbook template

Your runbook can be short if it is clear:

1. Detect: alert shows domain and host.
2. Verify: run certbot renew --dry-run or equivalent.
3. Isolate: check DNS + challenge path + firewall.
4. Recover: complete renewal, reload service, verify handshake.
5. Record: one post-incident note with root cause and fix.

Do not optimize for perfect docs. Optimize for fast recovery by a tired engineer at 2 a.m.

Final recommendation

Treat shorter certificate lifetimes as an opportunity to mature operations:

• remove manual renewal dependencies
• add simple alerting
• rehearse recovery

When certificate management becomes routine, your VPS stack gets safer with almost no user-visible downside.