Your hosting dashboard says that a new certificate is ready. Does that mean your visitors are using it?
The answer depends on where HTTPS is managed. For your first renewal, write down who obtains the certificate, which service uses it, and how you will check the connection that a visitor actually makes. Those are separate questions, even when a hosting provider handles all of them for you.
Conceptual renewal workflow, not a production test result. Product-specific activation and checks depend on the actual HTTPS service.
Start with the service that handles HTTPS
HTTPS protects web traffic using TLS, or Transport Layer Security. A server certificate helps a client authenticate the server. It contains a public key and information about the names it covers, among other fields. The corresponding private key stays with the authorized server-side service or key-management system.
MDN's TLS guide explains that modern hosting services often manage certificates and configure HTTPS on your behalf. Before adding your own renewal job, check the provider's documentation and your service settings.
For a managed service, your work may be confirming that automatic renewal is enabled and finding the person responsible for alerts. For a self-managed server, you may also need a certificate client and a deployment procedure. A CDN, a load balancer, or a web server can be the component that handles the browser's TLS connection. A certificate on an application server behind it may cover a different connection.
1. Obtain the next certificate
Renewal normally means obtaining a new certificate before the old one becomes unusable. It does not change the expiry date printed inside the old certificate.
ACME, the Automated Certificate Management Environment protocol, lets a client automate certificate requests. In Let's Encrypt's explanation, the client proves control of the requested domain and asks the CA, or Certificate Authority, to issue a certificate. Issuance is one stage of the work. The details of domain validation depend on the client and deployment.
Record which names the certificate must cover and which client or provider is responsible. Also record where renewal failures are reported. A scheduled job without anyone receiving its failure notice is an incomplete handoff.
2. Make the HTTPS service use it
A new file on disk is useful only if the relevant HTTPS service loads it. The installation path and activation procedure depend on the product. Some services reload configuration, some use a managed upload or secret, and others handle this automatically.
Use the official procedure for your actual hosting platform. It should tell you which certificate chain and key format to supply, how to activate the change, and how to recover if activation fails. Do not assume a command from a different server product applies to yours.
An existing connection may continue under its previous TLS state. Checking a new connection matters when you want to see what the service now presents.
3. Check what the client receives
After activation, make a new connection to the public hostname using a client that performs normal certificate verification. Check the certificate it receives, including the intended names and validity period. Record the client, time, and hostname so another person can understand the observation.
The rules for certificate path validation and service names are described in RFC 5280 and RFC 9525. Finding the expected certificate fingerprint alone does not show that the client accepted its name and trust chain. Similarly, reading a local file does not show what a public endpoint serves.
If your hostname reaches several servers or regions, one successful connection is only one observation. Your deployment procedure should explain which destinations need checking. A certificate check also does not replace an application health check.
A worksheet for the next person
| Question | Fill this in for one service |
|---|---|
| Who obtains the certificate? | Provider or client, responsible person, alert destination |
| What names must it cover? | The actual hostnames visitors use |
| Where does the browser's TLS connection end? | The CDN, load balancer, or web server and its service name |
| How does that component load a replacement? | Official procedure and activation step |
| What did a new client connection receive? | Hostname, client, time, certificate details and verification result |
| What remains unobserved? | Other destinations or checks still required by the deployment |
This is a planning worksheet, not a report of a production test. Filling in the boxes helps you identify missing responsibilities before the next renewal. Keep private keys and account credentials out of the worksheet.
For a more detailed deployment flow and acceptance conditions, PKI Channel has a renewal and deployment guide in Japanese. Its diagrams separate obtaining, deploying, activating, and observing the replacement. Use it as an additional reference alongside the documentation for your platform.
AI was used for source review and drafting.
Top comments (0)