Keep HTTPS working through the whole certificate lifecycle

Map where the secure connection ends

List the hostnames users actually visit, including the main domain, any www name, application subdomains and important API endpoints. Then identify where TLS terminates for each: a web server, reverse proxy, load balancer or another managed service. A certificate installed on the origin does not prove that a separate public proxy serves the same one. Keep this inventory with the people responsible for domains and hosting access.

A certificate must cover the hostname requested by the client and chain to a trust anchor that client accepts. The service also needs to present the relevant certificate and intermediate chain correctly. Check more than one convenient URL when applications use several names. A successful connection to the bare domain says little about an API subdomain or a separate mail service, which may have its own certificate process.

HTTPS protects the connection under the applicable protocol and configuration; it is not evidence that the application has no vulnerabilities or that a merchant is trustworthy. Keep access control, updates and backups in their own operating plan. HM Bastion’s web-hosting feature list includes automated SSL renewal, while a VPS administrator must confirm and manage the certificate tooling used in their own stack. Do not assume those responsibilities are identical.

Choose validation around the environment you run

ACME automates interactions involved in obtaining certificates, including proving control of the requested domain names. Different challenge methods fit different environments. HTTP-based validation depends on the required validation path being reachable as specified by the certificate authority. DNS-based validation depends on control of the relevant DNS records. Read the authority and client documentation before selecting a method, especially when a proxy or multiple application instances sit in front of the origin.

DNS automation can require credentials with significant power over a domain. Store them outside public directories and give them only the permissions the chosen integration needs when that is supported. Separate documentation of the process from the actual secret values. Manual validation can be appropriate for a particular setup, but it creates a recurring human dependency; write down who will complete it and how an approaching renewal will be noticed.

Use the certificate authority’s staging environment when testing an integration where available. It allows you to exercise the process without treating repeated production issuance as a debugging method. A staging certificate is not trusted for normal public service, so keep the test’s purpose clear. Avoid hard-coding assumptions about certificate lifetimes or renewal schedules when the authority and client provide guidance or renewal information that may change.

Renewal, deployment and reload are separate results

Check that the scheduled renewal mechanism actually runs under the intended account and environment. A command that works in an interactive terminal may rely on a path, permission or credential absent from its scheduled execution. Review the relevant logs and use the client’s supported renewal test procedure. For Certbot, the documentation describes dry-run testing and renewal hooks; follow the instructions appropriate to the installed version and chosen authenticator.

A newly written certificate file does not automatically change what a running service presents. The service may need a reload, a deployment hook, or distribution to several termination points. Validate configuration before reloading, retain a rollback path, and check the public connection afterwards. In a multi-node setup, a single successful request can reach only one node. Plan a check that covers the actual deployment rather than assuming every instance changed together.

Monitor the certificate served externally, its covered names and the time remaining before expiry. This catches a different failure from monitoring whether the renewal job returned successfully. Keep notification ownership current, including when an agency or administrator changes. An alert delivered to an abandoned mailbox offers little protection. Revisit the inventory after changing DNS, adding a reverse proxy, moving a hostname or changing the web server’s configuration.

Investigate a failed renewal from the failed step

• Record the affected hostname, client version, time and exact non-secret error.
• Identify whether the failure is validation, issuance, deployment or public serving.
• Check the relevant DNS, routing, file access and scheduled-job environment.
• Repair and test the narrow cause before retrying production issuance.
• Verify the public certificate and normal application journeys after recovery.

For example, if validation fails after a DNS change, compare the current public records with the intended challenge route before replacing certificate tooling. If issuance succeeds but the browser still sees an old certificate, inspect the public termination point and deployment process. Repeatedly requesting certificates will not fix a proxy that reads another file. Keep the original error and subsequent actions in a timeline so the next person can follow the diagnosis.

If a private key may have been exposed, treat that as a security incident rather than an ordinary expiry reminder. The response can include replacing keys, revoking affected certificates through the appropriate process and investigating the exposure. Never place a private key or DNS credential in a support ticket. Share the hostname, certificate identifiers where useful and safe diagnostic output so the team can investigate without receiving control of the domain.