Map the certificate path
A browser showing a secure connection confirms a certificate is being served now. It says little about the next issuance, installation, or reload. Start by listing every public hostname that customers use, including the bare domain, www address, booking subdomain, payment return page, and any API endpoint used by an app. For each hostname, record where TLS terminates: a hosted platform, content delivery network, load balancer, reverse proxy, or the application server. The owner of that termination point is usually the person or service that must install the replacement certificate. A domain registrar may be unrelated. Do not infer ownership from the DNS provider name alone.
Ask the hosting provider which certificate is served on the public edge, who requests renewals, and how a failed renewal is reported. For a self-managed system, record the ACME client, scheduled job, challenge method, configuration location, and the reload action that makes newly written certificate files active. These are operational notes, not secrets: keep account keys and DNS API tokens out of a shared checklist. If a service presents different certificates by hostname or region, test each path customers can reach. An internal file with a future expiry date is not evidence that every edge presents that file.
Check the renewal dependency
For Let’s Encrypt HTTP-01 validation, its server must reach the challenge response through port 80 at the named host. A redirect can be followed under its documented limits, but a blocked port, unexpected proxy rule, or one server in a pool missing the challenge response can break renewal. HTTP-01 also cannot issue a wildcard certificate. Those are reasons to inspect routing and firewall changes whenever the web stack changes. They are not reasons to turn off HTTPS redirection throughout the site. Verify the actual challenge path your client uses and follow its supported configuration rather than guessing that a homepage request proves validation will work.
DNS-01 instead proves control through a TXT record under the challenge name and can support a wildcard. It introduces a different dependency: the automation must be able to update the correct DNS zone, and the new record must be visible when the certificate authority checks it. Let’s Encrypt warns that placing broad DNS API credentials on a web server increases the impact of a compromise. Use a narrowly scoped method supported by your provider or separate validation host where practical, and have the operator check propagation and delegation when DNS changes. A manual DNS edit for one successful issuance is not proof that unattended renewal will work months later.
Test issuance, deployment and service
A useful rehearsal has three observations. First, the supported client or platform reports that its renewal operation can complete under the current routing and credentials. Second, the replacement reaches the configured service and the service loads it. Third, an external connection to every named public host reports the expected hostname coverage, certificate chain and expiry. The first observation alone misses a deployment script that copies to the wrong directory; the second alone misses a load balancer that still serves an older certificate. If the provider offers a safe dry-run or staging method, use that method for rehearsal and read its limitations: a simulated or staging certificate may not be the live certificate seen by customers.
Consider a shop whose main site is managed by a hosting platform while bookings.example.com points to a separate appointment service. A renewal email about the main site is irrelevant to the booking host unless that provider manages both. The owner lists the two termination points, obtains a renewal contact for each, and tests both from outside the office. If a booking flow embeds an API on another host, include it too. This simple map prevents the common mistake of treating a green browser indicator on one page as coverage for the whole customer journey. It also makes escalation faster when a failed certificate is discovered at night.
Make failure observable and actionable
Set an alert on the certificate actually served to the public, with enough lead time to diagnose the issue and with a named recipient who can act. Monitor each important hostname rather than a single dashboard tile. The alert should show the host, observed expiry, observation time, and where it was checked. Route it to a maintained team address or on-call channel; a departing employee’s mailbox is a weak dependency. Separately review the renewal job’s failure messages. Those messages can reveal validation trouble before the external expiry check becomes urgent, while the external check catches a successful issuance that never reached the public edge.
Write a response that starts with identifying the affected hostname and provider, not repeatedly pressing a renew button. Check whether the challenge is failing, whether the new certificate was issued but not deployed, or whether one edge has stale configuration. Preserve the old working setup until the replacement is confirmed; do not paste private keys into a ticket or chat. If renewal fails, use the provider’s supported recovery path and test externally again. Keep a record of what failed, what was changed, and which public paths were checked. That record helps distinguish a one-off outage from a recurring scheduling or ownership gap.
A practical acceptance decision
The owner can accept the renewal arrangement when each hostname has a named operator, an identified challenge and deployment path, evidence of a recent supported rehearsal, an external check of the currently served certificate, and a failure alert that reaches someone able to respond. This is a stronger decision than trusting a certificate expiry date copied from an internal screen. It also avoids promising that renewal is guaranteed: providers change APIs, DNS routing changes, and certificates have different terms. Repeat the exercise after a hosting migration, DNS change, proxy change, or ownership handover, because any of those can invalidate an earlier successful test.
If the business buys a managed website service, ask it to demonstrate those outcomes rather than request a particular ACME command. If it operates its own server, give the operator a small change record and a clear escalation contact. The commercial decision is whether staff time should cover these operational checks or whether a service agreement should explicitly include them. Either route still needs evidence from the public site. A renewal mechanism is useful only when the replacement certificate reaches the customer before the old one expires, and the business can notice and repair the exceptions.
Keep the handover current
A small business should make the renewal record usable by a substitute operator. Include the hostname inventory, provider support channel, monitoring recipient, certificate installation owner, and the last successful external observation. Record who can change DNS and who can change the serving edge, because these may be separate vendors. When a contractor leaves, transfer those responsibilities through the provider’s normal access controls rather than sharing an old login. A practical tabletop exercise asks a colleague to locate the failing hostname, name the next diagnostic step, and find the person authorised to make a change. If they cannot do so from the record, the process depends on memory. The record should be reviewed after every infrastructure change and at an agreed regular interval, since a forgotten subdomain can silently fall outside the main site’s maintenance routine.
When reviewing alerts, distinguish certificate expiry from other HTTPS failures. A hostname mismatch, missing intermediate certificate, stale edge, or DNS change can affect visitors even while a certificate file has many days left. The response should name the observed symptom instead of telling staff that every browser warning means renewal failed. Keep screenshots or connection observations with their date, host, and test location, but do not claim a single test represents all networks. If the business changes its domain or adds a new landing page, require the project handover to add that host to both the renewal owner map and the external check. This turns certificate care into a small repeatable control instead of an emergency triggered only by a customer complaint.
Release checks
- Does every customer-facing hostname have an owner and a public certificate check?
- Can the present challenge and deployment path complete a supported rehearsal?
- Will a failure alert reach someone who can repair the affected host?
