Automatic TLS certificate renewal: spot common failures

Identify the system responsible for renewal

For each service, record its hostnames, the system managing its certificates and an owner. Websites, webmail and mail servers may use different certificates. In Plesk with SSL It!, open Websites & Domains, select the domain and inspect SSL/TLS Certificates. Check the covered names and services. Automatic renewal of a Let's Encrypt certificate does not mean that a manually uploaded certificate follows the same process.

NUXOA web hosting supports automating Let's Encrypt certificate issuance and renewal through the control panel. On self-administered servers, the process must match your installation. For managed systems, agree in the quotation who handles certificates, DNS access and failure notifications.

Keep domain validation working

Let's Encrypt can validate domain control using HTTP-01 or DNS-01, among other methods. HTTP-01 retrieves proof from /.well-known/acme-challenge/ through port 80. DNS-01 uses a TXT record under _acme-challenge and also supports wildcard certificates. Automated DNS validation requires a suitable DNS API and valid credentials with narrowly scoped permissions.

After changing firewall rules, redirects or access controls, verify that your chosen validation method still works. For DNS-01, the current TXT value must be available on the authoritative DNS servers before validation starts. Successfully loading the normal homepage is not a substitute for this check.

Include IPv6 and CAA in troubleshooting

If A and AAAA records point to different systems, the site may work over IPv4 while certificate validation fails. When both address families are available, Let's Encrypt initially prefers IPv6. An incorrect HTTP response from that server does not simply trigger another attempt over IPv4. Check both address families and correct outdated DNS destinations.

CAA records determine which certificate authorities may issue certificates for a name. When an error points to CAA, check the effective policy, including parent domains and any CNAME destinations. Wildcards can have additional rules. Instead of deleting CAA policies indiscriminately, align the permitted authority with the one you actually use.

Verify deployment after issuance

A new certificate on disk is not enough if the web server or an upstream proxy still serves the old one. With Certbot, a deploy hook can trigger the required steps after successful renewal. A successful certbot renew command alone does not confirm renewal: it can also succeed when no certificate is due.

Then check the service externally using its actual hostname: does the served certificate cover the name and show the expected validity period? If several systems handle incoming connections, are they all reachable and updated? A Certbot --dry-run tests renewal against a test environment; deploy hooks do not run by default. Verify installation and adoption by the service separately.

Detect failures early and respond

Let's Encrypt ended its certificate expiration warning emails on 4 June 2025. Set up your own expiry monitoring with an owner and backup contact. Base warning thresholds on the actual certificate lifetime and the time needed to respond. Monitor the externally reachable service as well as renewal logs.

When renewal fails, first identify the affected hostname, timestamp and exact error. Address the cause before repeatedly requesting certificates. Let's Encrypt recommends controlled retries with increasing delays. Use test environments for planned checks; their certificates must not be deployed to the public service.

• After a DNS change or server move, recheck validation and certificate assignment.
• After renewal, inspect the certificate actually served to clients.
• Document ownership, alert delivery and recovery steps for the next failure.