TLS renewal is finished only when clients receive the right certificate

Begin at the serving endpoint, not the renewal log

A certificate maintenance job can report success while a customer still receives yesterday's certificate. The new file may belong to another hostname, another container or the unused origin of a recently migrated site. A proxy may retain its loaded certificate until an activation step succeeds. One member of a serving pool may have missed the change. These are different failures with the same misleading summary: renewal worked. Begin the investigation with the exact hostname, port and route used by an affected client. Record the observation time and the certificate actually returned there before changing the renewal configuration or requesting another certificate.

Use four separate receipts: the attempted issuance, the saved public certificate, the server's activation result and an external client observation. Their timestamps help locate the broken transition. A new expiration date in a local directory establishes something about that file, not every process that might reference it. An HTTP success establishes application reachability through the tested path, while a certificate inspection establishes identity through that connection. Keep both observations. The operational goal is a trusted, correctly named certificate on the intended serving endpoint, followed by a representative application response. Repeated issuance requests do little for a process that keeps loading the wrong path.

Inventory the names and the two ends of each connection

Write down the names customers use, including an apex domain, its www variant, API names and any separate administrative endpoint. Record their authoritative routing and intended TLS termination point. A browser may connect to a CDN, which then connects to an origin using a separate TLS session. An internal load balancer can add another boundary. These connections need their own expected identities and owners. Avoid a single spreadsheet cell called certificate when it hides several unrelated credentials. A migration checklist should identify which edge, load balancer or process must change and which team can inspect each destination without granting unnecessary access to private material.

Keep address families and serving pool members explicit. A correct IPv4 response does not establish the state of IPv6, and a successful request to one origin does not verify every backend. Resolve the public name from a relevant network, compare it with authoritative records and retain the selected remote address with the result. Where a provider terminates TLS, distinguish its managed public certificate from the certificate installed on your server. The expected values may legitimately differ. Plan observations around that architecture rather than requiring identical fingerprints everywhere. A useful inventory lets the next operator choose the right comparison before a green checkmark conceals an unchecked path.

Inspect public certificate metadata without copying private keys

Find the configured certificate reference for the process that actually owns the TLS listener. A host directory can contain several old lineages, and a container can mount a different directory at the same apparent path. Compare the process configuration, mount source and public certificate metadata together. Record names, validity dates, issuer and a SHA-256 fingerprint of the leaf certificate. Resolve any symlink deliberately and identify whether the process sees a maintained lineage or a copied snapshot. A recent file timestamp is a weak substitute for this evidence because copying an old certificate changes its timestamp without extending its validity or correcting its names.

The Nginx HTTPS guide distinguishes the public certificate from the private key and explains name-based TLS selection and certificate chains. Share public metadata in an incident record; keep private keys and DNS API credentials within their existing protected locations. A public certificate inspection does not require printing a key, exporting an entire certificate directory or attaching secret configuration to a support ticket. If a configuration reference is wrong, prepare a narrow correction and retain the previous configuration for recovery. Treat certificate material as part of the serving configuration with an identifiable owner, rather than a directory that any deployment script may replace.

# CERT_NAME is the actual installed lineage name, not an assumed hostname.
CERT_NAME=monitor.example.com
openssl x509 \
  -in "/etc/letsencrypt/live/$CERT_NAME/fullchain.pem" \
  -noout -subject -issuer -dates -fingerprint -sha256
# Inspect the path used by the serving process, including its mount.

Make challenge routing survive an application migration

An application move can leave certificate validation behind. The new server receives production traffic, but the renewal client still writes challenge material into a directory on the old machine. A blanket authentication rule can intercept the challenge path. A redirect can send validation to another hostname with a different serving policy. For HTTP-01, Let's Encrypt documents port 80 and the challenge path; changing a local client's listen port does not change the authority's public destination. Identify which system answers that path for every requested name. Test routing with a harmless, uniquely named file through the intended webroot before attempting a planned renewal.

Keep the exception precise. Serving a challenge file is not a reason to expose an administrative application or disable protection for an entire site. With several origins, arrange consistent challenge delivery through the chosen architecture instead of hoping validation selects the machine running the client. DNS-01 moves validation to DNS and can be appropriate when public HTTP validation does not fit the design. That choice introduces credential scope, propagation and cleanup responsibilities of its own. Document the DNS owner and the selected plugin rather than copying a broad account token to every origin. The aim is a repeatable ownership proof that remains correct when application placement changes.

Check AAAA records before chasing intermittent failures

A forgotten AAAA record is particularly effective at confusing an otherwise careful migration. Browsers and validation systems can reach an older IPv6 destination while an operator repeatedly tests a healthy IPv4 server. Let's Encrypt's IPv6 documentation, updated 4 August 2026, states that initial validation connections prefer IPv6 when both address families exist. Its IPv4 retry is limited to connection timeouts, and HTTP-01 fallback applies only to the first request. An incorrect HTTP response from a reachable IPv6 server therefore does not trigger a rescue through IPv4. Fix an unintended AAAA record or the IPv6 serving path; do not depend on fallback behavior.

During diagnosis, compare an explicit IPv4 request, an explicit IPv6 request and an ordinary client request from networks that support them. Failure on a machine without IPv6 connectivity establishes only that machine's limitation. Preserve the selected remote address and error so it cannot be mistaken for an origin rejection. Check redirects as separate hops because the first successful response may send the client elsewhere. If IPv6 is intentionally supported, verify the same hostname and application there. If it is intentionally absent, remove obsolete authoritative routing through the normal DNS ownership process and account for existing cache lifetimes before retiring the old listener.

Interpret a dry run as one bounded test

Certbot's user guide describes renew --dry-run as a test that normally uses staging and does not save the test certificate. Deploy hooks are excluded unless --run-deploy-hooks is selected; pre and post hooks can still run. With that extra flag, applicable deploy hooks use the current active certificate after a successful test. A configured custom ACME server changes the staging assumption. Read the installed client's configuration and hook effects before treating the command as harmless observation. Select the intended certificate explicitly when rehearsing one service, and run the rehearsal as a planned maintenance operation with a recorded result.

Separate the questions that a rehearsal can answer. It can exercise the selected validation route and expose a broken credential or unreachable challenge destination. It does not establish that a future scheduled invocation has the same environment, that a production certificate was replaced, or that every public listener has activated the intended material. Record the test scope beside the success message. If the renewal path works but the public fingerprint is stale, investigate activation and placement before requesting more certificates. This keeps a useful diagnostic from becoming an endless loop of issuance attempts that obscures the actual fault and consumes the operator's remaining recovery time.

Activate the intended configuration and preserve a recovery path

Identify how the actual TLS server loads certificates. A conventional Nginx setup using static certificate paths normally needs a successful configuration reload to adopt changed files; other software and dynamic certificate configurations behave differently. The Nginx control documentation explains its reload behavior. Test configuration before a planned reload, retain a working administrative session and inspect the reload result. Do not substitute a broad host reboot for understanding which process owns the listener. A failed activation should leave a clear diagnostic and a recoverable configuration, especially when the same proxy serves several unrelated applications whose traffic is currently healthy.

For containers, verify the certificate mount and the process's actual configuration after activation. Recreating a container with a copied certificate may temporarily fix service while leaving the next renewal broken in exactly the same way. Conversely, a maintained shared mount still needs the appropriate reload mechanism when the server does not reload automatically. Record that mechanism in the service's operating guide. Include permissions, the expected owner and a recovery command reviewed for that installation. Keep certificate activation separate from an application image release so a routine credential change cannot silently publish unfinished software or restart unrelated components on the same server.

Verify trust, hostname and application response from a client

Use a normal validating HTTPS client for the public test. Supply the real hostname, retain certificate verification and set a short connection timeout plus a total operation deadline. The curl manual documents --resolve for directing a hostname and port to a chosen address while preserving the URL identity. That is useful for an authorized direct-origin check when the architecture permits it. Do not add -k to make a failed trust check disappear. An expected authentication response can still establish a completed TLS connection; it does not prove a signed-in workflow works. Record transport verification and application outcome as separate fields.

For certificate identity, inspect the served public leaf with an SNI-aware TLS connection and compare it with the expected certificate for that leg. The OpenSSL s_client reference documents the connection and server-name options. A pipeline that extracts a certificate and prints its dates is an inspection tool, not sufficient proof of trust or hostname validation. Pair it with the validating client check. Sample the serving destinations that matter rather than repeatedly reaching one convenient backend. After TLS passes, exercise a low-impact representative application request, because a correct certificate can still front the wrong virtual host or an unhealthy upstream.

NAME=monitor.example.com  # replace with your own hostname
curl --connect-timeout 5 --max-time 15 --silent --show-error \
  --output /dev/null --write-out 'HTTP=%{http_code} peer=%{remote_ip} TLS=%{ssl_verify_result}\n' \
  "https://$NAME/"

# Inspection only: this pipeline is NOT a trust or hostname assertion.
openssl s_client -connect "$NAME:443" -servername "$NAME" </dev/null \
  | openssl x509 -noout -subject -issuer -dates -fingerprint -sha256
# Compare with the expected leaf for this TLS leg; retain curl's result.

Compare edge and origin against their own expectations

A CDN can present a provider-managed public certificate while the origin serves a different certificate accepted under the configured origin policy. Matching those two fingerprints is usually the wrong success criterion. Verify the browser-to-edge connection using its public hostname and trust requirements. Verify the edge-to-origin connection using the expected origin name, trust configuration and permitted network path. Record which side a probe actually reaches. A direct request from a workstation may be intentionally denied by an origin allowlist, so a denial is not automatically a failed renewal. Use the appropriate authorized vantage point rather than temporarily opening the origin to the whole Internet.

Keep server certificates separate from client authentication credentials. For example, a proxy's origin-authentication client certificate establishes something about the connecting proxy; it does not replace the origin's server certificate or the customer's public trust check. During a migration, retain a small connection map with the terminating service and validation policy for each leg. This map also prevents the inverse mistake: declaring the origin healthy because a cached page loads successfully at the edge. Follow a representative uncached request through the intended application path when that is part of the verification plan, and distinguish cached availability from a successful new origin connection.

Observe scheduled maintenance without inventing a universal timer

Find the scheduler installed by the actual certificate client package. A distribution package, a Snap installation, cron and a managed hosting platform can expose different controls. The Certbot guide explains checking the installation's timer or scheduled command rather than assuming one universal unit name. Inspect its last execution, result, next planned run and the remaining lifetime observed at the public endpoint. An inactive one-shot service can simply have finished successfully; inactivity alone is not a failure verdict. Preserve the relevant exit status and timestamp, and check whether the scheduler has access to the credentials, paths and network route used in the successful rehearsal.

Choose alert timing from the time needed to diagnose and recover, with margin for absence and provider problems. A certificate expiring soon with repeated failed attempts needs a different response from a recently issued certificate awaiting an activation fix. Record who receives the alert and how they reach the management path if the public site fails. Test that route during ordinary operations. Scheduled certificate maintenance is compatible with an explicit manual software-release policy: renewing an expiring credential is a defined maintenance task, while publishing a new application image remains a separate operator decision. Describe both responsibilities clearly so neither is silently abandoned.

Close with evidence the next operator can reproduce

The handoff should identify the hostname, serving destinations, selected certificate lineage, activation mechanism and observations from each relevant TLS leg. Include the observed public expiration, leaf fingerprint, validation result and representative application outcome, with times and vantage points. Record any unverified pool member or unsupported address family as an open item. Keep secret material out of the evidence bundle. A second operator should be able to repeat a narrow check without reconstructing the server from old shell history. When recovery is complete, remove temporary diagnostic files and document the precise routing or activation correction that prevented the renewed certificate from reaching clients.

Hostwatch can place certificate observations beside the configured service and server evidence that an operator has actually collected. That context helps connect a stale endpoint to an old placement, but it does not establish the state of an unprobed CDN connection or every remote client. Keep configured observation, inference and verified result distinct. Apply any software correction through its explicit supported update operation, then repeat the public check. The final receipt should say what now serves the intended identity and which path was tested. A renewal receipt becomes useful operational evidence when it connects all the way to the certificate and application response a real client receives.

• Map the hostname, address families and every TLS termination leg.
• Identify the maintained lineage and the serving process configuration.
• Record issuance or rehearsal scope and activation evidence separately.
• Verify public trust, hostname, leaf identity and an application response.
• Confirm maintenance ownership, scheduler evidence and recovery access.