Certificate renewal is the process of replacing an SSL certificate that is approaching its expiry date with a new certificate, obtaining a fresh certificate from the certificate authority before the existing one expires, installing it on the server, and ensuring continuous HTTPS coverage without any interruption to service. The renewed certificate is a completely new certificate, issued fresh by the CA with a new validity period, rather than an extension of the existing certificate’s validity.

The need for certificate renewal arises from the fundamental characteristic of SSL certificates, they have a defined validity period, after which they are no longer accepted by browsers. An expired certificate triggers the same browser error warnings as a missing certificate, visitors see a full-screen security warning that the connection is not private. For redirect management domains where expired certificates prevent HTTPS visitors from receiving redirect responses rather than error pages certificate renewal is a critical operational responsibility.

Certificate renewal has become significantly simpler with the widespread adoption of the ACME protocol and automated certificate management tools. What previously required manual processes, generating a certificate signing request, submitting it to a CA, downloading the issued certificate, and installing it on the server, is now handled automatically by ACME clients that manage the complete renewal lifecycle without human intervention. For most modern infrastructure automatic renewal through ACME is the standard and the manual renewal processes of earlier years are largely obsolete.

Certificate validity periods

Certificate validity periods define how long a certificate is accepted by browsers before renewal is required. The trend over the past decade has been toward shorter validity periods, driven by security research showing that shorter validity limits the damage from compromised certificates and encourages automation.

Historical validity periods: early SSL certificates had validity periods of two to five years. Long validity periods were convenient for manual certificate management, renewing annually or less frequently reduced operational overhead. The trade-off was that compromised certificates remained valid for extended periods and outdated certificates with weak algorithms stayed in use long after better alternatives were available.

398-day maximum: the CA/Browser Forum, the industry consortium that sets baseline requirements for certificate authorities, mandated a maximum validity period of 398 days, approximately 13 months, effective September 2020. Certificates issued after this date cannot have validity periods exceeding 398 days. This limit replaced the previous two-year maximum and was driven by browser vendors, Apple, Google, Mozilla, who announced they would stop trusting certificates with longer validity periods regardless of CA/Browser Forum baseline requirements.

90-day Let’s Encrypt certificates: Let’s Encrypt issues certificates with 90-day validity periods, significantly shorter than the 398-day maximum. The shorter validity is intentional, it encourages automation by making manual renewal impractical, reduces the window during which a compromised certificate remains valid, and limits exposure from certificate mis-issuance. The 90-day period requires renewal roughly four times per year, a cadence that makes sense only with automated renewal tools.

Proposed 47-day and shorter validity: the CA/Browser Forum and major browser vendors have been discussing further reductions in maximum certificate validity, proposals for 47-day and eventually shorter validity periods have been under consideration. Shorter validity periods make automation even more important and further reduce the risk from compromised certificates. The trend is clearly toward shorter, more frequently renewed certificates as automation makes this operationally feasible.

How certificate renewal works

Certificate renewal follows the same process as initial certificate issuance, domain validation, certificate request, and certificate delivery, but triggered before the existing certificate expires rather than when starting fresh.

Renewal timing: certificates should be renewed before they expire, the standard recommendation is to renew when 30 days or fewer remain. This provides a buffer for dealing with any issues that arise during renewal, DNS propagation delays for DNS-01 challenges, temporary CA availability problems, or configuration issues, without risking expiry. Let’s Encrypt’s recommended renewal window is 30 days before expiry. Automated ACME clients typically check certificates daily and initiate renewal when the threshold is reached.

Domain validation repetition: certificate renewal requires completing domain validation again, the CA must verify that the certificate requester still controls the domain before issuing a renewal. This repeated validation is a security feature, it ensures that if a domain changes hands between renewal cycles the new owner’s certificate is not automatically renewed. ACME-based renewal completes domain validation automatically, the client performs the HTTP-01 or DNS-01 challenge without manual intervention.

New certificate issuance: the CA issues a completely new certificate, with new serial number, new validity period starting from the issuance date, and potentially different cryptographic parameters if the CA’s issuance policies have changed. The renewed certificate is not a modification of the expiring certificate, it is a fresh certificate that happens to cover the same domains.

Certificate installation: the new certificate must be installed on the server before the old one expires. For automated renewal the ACME client handles installation, placing the new certificate files in the correct location and reloading the web server to pick up the new certificate. For manually managed certificates installation requires downloading the new certificate from the CA and updating the server configuration.

Zero-downtime renewal: properly executed certificate renewal causes no interruption to HTTPS service. The old certificate continues to be served until the new certificate is installed. After installation the new certificate is served. No gap occurs between the old certificate expiring and the new certificate being active, the new certificate is installed before the old one expires.

Automated certificate renewal

Automated certificate renewal through ACME clients is the modern standard, the operational complexity of manual renewal does not scale with the number of certificates and domains being managed.

ACME renewal cycle: ACME clients perform automated renewal through a scheduled process. A background process, cron job, systemd timer, daemon, runs periodically, typically daily, and checks the expiry date of all managed certificates. When a certificate has fewer than 30 days remaining the client initiates the renewal process, performing domain validation, requesting the certificate, and installing it automatically.

Certbot automated renewal: Certbot installs a systemd timer or cron job that runs twice daily. Each run checks all managed certificates and renews any that are within 30 days of expiry. Successful renewals are logged, failed renewals trigger error logging and optionally notification hooks.

The Certbot renewal command that runs automatically:

certbot renew

certbot renew

certbot renew

Running this manually outside the scheduled process renews all certificates within the renewal window, useful for testing renewal configuration or forcing early renewal.

acme.sh automated renewal: acme.sh installs a cron job when first run with --install-cronjob. The cron job runs daily and checks all managed certificates, renewing those within the renewal window. acme.sh supports post-renewal hooks, scripts that run after successful renewal to reload web servers, notify monitoring systems, or perform other post-renewal actions.

Renewal hooks: most ACME clients support hooks, scripts that run at specific points in the renewal process. Post-renewal hooks run after successful certificate installation, typically used to reload the web server so it picks up the new certificate. Pre-renewal hooks run before validation, used to prepare the environment for the challenge. Deploy hooks run when a certificate is actually renewed, as opposed to the periodic check finding no certificates needing renewal.

For redirect management infrastructure post-renewal hooks ensure the redirect server reloads its certificate configuration immediately after renewal, avoiding any window between certificate installation and server pickup.

Certificate renewal for redirect management

Certificate renewal has specific implications for redirect management, the requirements are the same as for any HTTPS infrastructure but the operational context differs in important ways.

SSL on all redirect source domains: every domain connected to redirect infrastructure requires valid SSL certificates throughout its lifetime as a redirect source. A redirect source domain with an expired certificate fails to serve HTTPS redirect responses, visitors who arrive at the domain over HTTPS receive certificate errors rather than being forwarded to the redirect destination. Certificate renewal must be maintained for every redirect source domain regardless of how many there are or how infrequently they are accessed.

Automated renewal for large redirect portfolios: organisations with large redirect domain portfolios, dozens or hundreds of source domains, cannot manage certificate renewal manually. A portfolio of 100 redirect source domains all using Let’s Encrypt 90-day certificates would require roughly 400 certificate renewals per year, impossible to manage manually. Automated renewal through the redirect management platform’s certificate infrastructure handles this without human intervention, certificates for all connected domains renew automatically before expiry.

Dedicated redirect management platforms that integrate automated SSL provisioning and renewal handle certificate management as a core platform function, the domain owner connects the domain and the platform takes responsibility for ongoing certificate management.

Renewal challenges for redirect-only domains: redirect source domains present a specific challenge for HTTP-01 certificate renewal, the domain exists only to serve redirects, not to host content. HTTP-01 validation requires the ACME client to serve a validation file at a specific URL path on the domain. For a domain configured to redirect all traffic the ACME client must either temporarily intercept the validation request before the redirect fires or use an alternative validation method.

DNS-01 validation avoids this challenge entirely, it validates domain control through DNS rather than HTTP, making it suitable for redirect-only domains that cannot serve HTTP content for validation. Redirect management platforms using DNS-01 validation for certificate renewal handle this correctly, no conflict with redirect rules.

CNAME delegation for renewal: some redirect management platforms implement certificate renewal through CNAME-based DNS delegation. The domain owner adds a CNAME record that delegates the _acme-challenge subdomain to infrastructure controlled by the redirect platform. The platform completes DNS-01 challenges autonomously, creating and removing the required TXT records, without requiring ongoing DNS access from the domain owner. This approach enables fully automated renewal for all connected domains without per-renewal DNS management.

What happens when certificates expire

Certificate expiry is one of the most impactful and preventable HTTPS failures. Understanding the consequences of expiry reinforces the importance of automated renewal.

Immediate browser errors: browsers check certificate validity on every connection. An expired certificate triggers an immediate, full-screen error page, in Chrome this is NET::ERR_CERT_DATE_INVALID, in Firefox this is SEC_ERROR_EXPIRED_CERTIFICATE. The error page explicitly states the certificate has expired and recommends against proceeding. Most visitors leave immediately rather than clicking through the warning.

HTTPS visitors cannot receive redirects: for redirect management the consequence of certificate expiry is that HTTPS visitors cannot reach the redirect response at all. The TLS handshake fails before the HTTP redirect response can be sent. Visitors who follow links to a redirect source domain with an expired certificate see an error page rather than being forwarded to the intended destination. The redirect effectively stops working for all HTTPS visitors.

HSTS makes expiry worse: domains with HSTS policies suffer more severely from certificate expiry. HSTS-covered browsers refuse to connect over HTTP, they require HTTPS. An expired certificate makes HTTPS fail. With HSTS in place these browsers cannot fall back to HTTP either, the domain becomes completely inaccessible for browsers with stored HSTS policies. The combination of expired certificate and HSTS means visitors cannot reach the domain at all until the certificate is renewed.

SEO impact: search engine crawlers that encounter expired certificate errors cannot index the domain’s content or follow its redirects. Link juice from backlinks stops flowing through the redirect to the destination while the certificate is expired. Extended certificate expiry causes the domain to be treated as unavailable, affecting how search engines evaluate its links and redirects.

Recovery after expiry: renewing an expired certificate immediately restores HTTPS functionality, browsers check the certificate on every connection, so as soon as the new certificate is installed future connections succeed. There is no lasting damage from brief expiry, a certificate that expired and was renewed within hours causes minimal disruption. Extended expiry, days or weeks, causes more significant impact, search engines may have cached the error state, visitors may have developed negative associations with the domain, and some HSTS-stored policies may have been cleared by users manually.

Monitoring certificate renewal

Certificate expiry monitoring provides advance warning before certificates expire, allowing renewal issues to be addressed before they cause service disruption.

Expiry monitoring services: services like UptimeRobot, Better Uptime, Freshping, and dedicated certificate monitoring tools check SSL certificate expiry dates for configured domains and send alerts at configurable thresholds, typically at 30 days, 14 days, and 7 days before expiry. Monitoring should cover every domain in the redirect portfolio, including source domains that may be less frequently visited and therefore less likely to have renewal failures noticed organically.

Server-level certificate auditing: ACME clients provide commands to audit managed certificate status. Certbot’s certbot certificates command lists all managed certificates with their expiry dates and renewal status. Regular auditing confirms all certificates are being renewed correctly and identifies any that are approaching expiry without automated renewal in place.

Certificate transparency monitoring: certificate transparency logs record every certificate issuance. Services that monitor CT logs for a domain send notifications when new certificates are issued, confirming that renewal happened, or when unexpected certificates are issued, detecting unauthorised issuance. CT monitoring provides both renewal confirmation and security alerting in one mechanism.

Synthetic HTTPS monitoring: monitoring tools that perform regular synthetic HTTPS requests to configured domains detect certificate errors as they would appear to visitors, providing end-to-end validation that HTTPS is working correctly. A synthetic monitor that visits https://redirect-source.com every five minutes detects a certificate error within five minutes of expiry, providing faster detection than daily certificate expiry date checks.