How to Extend (Renew) an SSL Certificate
Renewing an SSL/TLS certificate is a routine maintenance process that keeps your website available over HTTPS without browser warnings or downtime. Most “SSL incidents” do not happen during the initial installation; they happen when a certificate expires and is not renewed in time. Browsers are strict: an expired certificate triggers a full-page warning, damages trust, and often reduces conversions. The reliable approach is to treat certificates as a living infrastructure component: monitored, renewed early, and tested after each change.
The renewal workflow depends on the certificate source. Let’s Encrypt certificates are typically valid for 90 days and are designed for automation via ACME clients such as certbot. Commercial DV/OV/EV certificates often have longer terms (commonly one year, depending on policy) and may require a re-issuance process with validation. In both cases, from the server perspective you usually “install a new certificate” and reload services so the new certificate becomes active.
On CloudHosting you can simplify renewal by choosing the right service model. If you need a specific certificate type (DV/OV/EV, wildcard, multi-domain), see SSL Certificates. If you prefer a simpler operational path for typical websites, consider Hosting. If you need full control, multiple applications, reverse proxying, or custom validation workflows, Virtual Servers are usually the best fit.
1) Start by identifying what you are renewing
Before you do anything, identify whether your certificate is issued by Let’s Encrypt (ACME) or a commercial CA. The easiest way is to check the issuer and the validity dates. With Let’s Encrypt, renewal is typically automatic if the ACME client is still running and the validation method still works. With commercial certificates, renewal typically means re-issuance: you obtain a new certificate with new validity dates and then install it on the server.
Avoid last-minute renewals. For OV/EV certificates, begin the renewal workflow two to three weeks before expiration, because organization validation can take time. Even with Let’s Encrypt automation, you should regularly verify that renewal still works—DNS changes, firewall rules, and proxy reconfigurations can silently break ACME validation and cause the certificate to expire later.
2) Check expiration and confirm which hostnames must be covered
Renewal time is when “coverage gaps” show up. A certificate might cover only one hostname (for example, www) while users also visit the apex domain, or you might have added a new subdomain (api, shop, portal) since the last issuance. That leads to name mismatch errors, where HTTPS works for some addresses but fails for others. Before renewing, list the required hostnames and make sure the renewed certificate includes all of them (SAN entries).
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -ext subjectAltName
If you change the set of covered names, you are effectively doing a re-issue. With Let’s Encrypt, that typically means running certbot again with additional -d flags. With commercial CAs, it may be handled as a re-issue within the order, or as a new order, depending on the provider’s policy.
3) Let’s Encrypt renewal: automation, validation, and reloads
Let’s Encrypt is built for automation. On most systems, certbot is run by cron or a systemd timer and renews certificates when expiration is approaching. Your job is to ensure three things: the renewal job runs regularly, the validation method (HTTP-01 or DNS-01) still works, and the web server reloads after renewal. If any link breaks, the certificate may expire silently until users start seeing warnings.
certbot renew --dry-run certbot renew
HTTP-01 validation requires port 80 to be reachable and requires that requests to /.well-known/acme-challenge/ are routed correctly to your server. If you use strict redirects or a reverse proxy, make sure the ACME challenge path remains accessible. DNS-01 validation relies on publishing the correct TXT record in DNS; it is required for wildcard certificates and is also useful when port 80 cannot be opened. DNS-01 is robust, but it requires attention to DNS propagation time and correct DNS tooling.
After renewal, many setups require a reload for Nginx or Apache to start using the new certificate. A best practice is to use a deploy hook that triggers reload only when a certificate actually changed. This avoids unnecessary reloads and makes the process predictable. If you renew certificates for multiple vhosts or run services behind a load balancer, ensure reload is applied to the correct nodes and does not leave some servers on the old certificate.
4) Commercial renewal: CSR, private keys, and chain updates
Commercial renewals typically involve generating a CSR, submitting it, completing validation, and receiving a new certificate plus intermediate certificates. Even if the CA allows reusing an old CSR, it is often safer to generate a new private key periodically to reduce the risk associated with long-lived key pairs. Once you receive the renewed certificate, you install it on the server, ensure the full chain is served, and reload your web service.
openssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr
A common pitfall is the chain. Many CAs provide updated intermediates, and servers must deliver the full chain, not only the leaf certificate. If some users suddenly see trust errors after renewal, the cause is frequently an incomplete chain or wrong ordering. Always test what the server actually sends to clients after renewal.
5) Post-renewal verification: confirm the new certificate is live
After renewal, verify at least three things: the validity dates changed, the certificate covers the expected hostnames, and the connection is clean (no chain errors, no wrong certificate, no mixed content regressions). Test from more than one location. If you use a CDN or reverse proxy, you can end up with a new certificate at the edge but an old certificate at the origin (or vice versa). If you run multiple nodes behind a load balancer, confirm every node is updated.
openssl s_client -connect example.com:443 -servername example.com | openssl x509 -noout -dates -subject curl -I https://example.com
If you use HSTS, renewal discipline becomes even more important. Browsers will refuse to fall back to HTTP, so even a short expiration window becomes a visible outage. Enable HSTS only after renewals are automated, tested, and monitored, and roll it out gradually with a smaller max-age first.
6) Why renewals fail: patterns that repeat
Most failures follow a few patterns. For Let’s Encrypt: port 80 becomes unreachable, DNS points to a different IP, the webroot path changed, or a reverse proxy blocks the ACME challenge. For DNS-01: incorrect TXT values or insufficient propagation time are the common causes. For commercial certificates: incomplete validation steps, delayed OV/EV paperwork, or forgetting to update the intermediate chain can break trust.
Another classic issue is forgetting about “www” or newly introduced subdomains. The certificate is renewed, but users visit a hostname not included in the SAN list and see a mismatch error. Treat renewal as a chance to review your domain map and redirect strategy: pick a canonical hostname and redirect alternatives to keep behavior consistent.
7) Operational hygiene: monitoring and alerts
Even with automation, monitoring matters. A good baseline is an expiry monitor that warns you when the certificate has fewer than a threshold number of days remaining (for example, 14 or 30). This protects you from “silent automation failures”. You can also monitor ACME logs, web server reload outcomes, and HTTPS status checks, all of which help catch configuration regressions early.
Stable HTTPS Long-Term: Make Renewal a Process
SSL renewal is the right moment to build a reliable process: confirm hostname coverage, automate renewals, ensure consistent TLS configuration, and test after changes. When these elements are in place, renewal becomes routine rather than a recurring emergency. In practice that means fewer incidents, stronger user trust, and stable HTTPS regardless of whether you use Let’s Encrypt or a commercial CA.
In more complex infrastructure, remember that certificates may exist at multiple layers: CDN edge, load balancer, reverse proxy, and origin servers. When renewing, ensure every layer is updated and aligned. A well-defined workflow with ownership, checks, and alerts is the safest way to guarantee that HTTPS never interrupts business-critical flows.