Certbot renewal fails: missing timer or manual-auth-hook

A certificate was issued successfully once but is not renewing automatically. An expected systemd timer may be missing, or a test may demand --manual-auth-hook. A documented case combined both problems: a separately installed Certbot and a manual challenge that had not been automated. Scheduling and unattended authentication are two independent requirements. Q1

“Not due” does not establish renewability

A message saying that no certificate is due only describes the current renewal decision. It does not prove that the next challenge can complete without input. Certbot documents both scheduled execution and authentication hooks for manual methods. Q2 Investigate the complete sequence before assuming a scheduler alone will prevent expiry.

Follow the actual execution path

1. Identify the installation. Record the executable path and version. Compare your interactive shell with the scheduled job and any container involved. Distribution packages, Snap and a custom Python environment may expose different executables. Avoid installing another client merely because a familiar service name is absent.
2. Identify the certificate. Record its name, domains and associated renewal configuration. Inspect the saved authenticator. If it is manual, identify the action a person performed during initial issuance and whether it now has an approved automated equivalent.
3. Test authentication deliberately. Use the dry-run procedure appropriate to that installation. Review existing hooks first: a test may execute hooks with external effects. If it stops for input or a missing authentication hook, solve that stage before treating scheduling as complete.
4. Inspect the scheduler. Review existing systemd timers or cron entries and their recent results. Check executable path, service user, credentials and logs. The absence of one expected unit name is not sufficient evidence that no scheduled job exists.
5. Verify certificate deployment. A renewed file must also be loaded by the intended service. Compare the certificate served to a client with the new file and inspect any reload hook needed by that service.

Make the corrected process observable

Where appropriate, use a supported automatic authenticator or a reviewed hook with narrowly scoped permissions. Then configure the intended schedule and inspect its outcome. External expiry monitoring and accessible failure logs make later failures easier to detect, but they do not replace a successful representative renewal test.

For support, prepare the installation method, sanitised renewal configuration, scheduler details and exact test error. Do not include private keys or API tokens. Keep the previous working configuration available until the new sequence is demonstrably reliable.

Frequently asked questions

Is enabling a timer enough?

Only if the command it runs can already succeed without interaction in that timer's execution environment.

Should I edit renewal files by hand?

Prefer the documented configuration procedure for your Certbot version and preserve the previous state. A mistaken stored value may remain unnoticed until the next renewal attempt.

Describe your case