Bridge SSL

SSL certificate renewal: renew before it expires

9 min readUpdated

Certificate renewal is getting a new certificate to replace one that is about to expire. Nothing is extended: the authority signs a new certificate with new dates, and it takes effect only once the server serves it. Whether the authority checks control of the name again depends on how long ago it last did. This page covers renewing on time and checking that the renewal is served.

Renewal produces
a new certificate with its own serial number and dates; the old one keeps its end date [1]
Longest the new certificate can last
200 days if issued since 15 March 2026; 100 days from 15 March 2027; 47 days from 15 March 2029 [2][3]
Domain validation can be reused for
up to 200 days for certificates issued since 15 March 2026; 100 days from 15 March 2027; 10 days from 15 March 2029 [2]
Organisation identity can be reused for
up to 398 days for certificates issued since 15 March 2026 [2]
Grace period after expiry
none: a client accepts a certificate only while the current time is inside its validity period [1]

Why renewal means a new certificate

A certificate is a signed statement with fixed dates. The dates are part of what the authority signed, so changing them would break the signature. In RFC 5280 terms, the validity period sits inside the tbsCertificate, the structure the signature is computed over [1]. An existing certificate cannot be prolonged; renewal is a new issuance.

Two consequences follow.

  • Obtaining the new certificate changes nothing by itself. Until it is installed and the server reloads, visitors receive the old one. A renewal completed in a control panel and never installed is the usual reason behind "I renewed and it still shows expired".

  • More than the dates can change. The intermediate that signs it may differ from last time, the key differs if you generated a new one, and the list of names is whatever this request contains. A subdomain added since the last issuance is not included unless someone adds it.

What carries over when renewing a certificate

Renewing a certificate repeats issuance, but not every check starts from zero. The rules for what a renewal may reuse are set in the CA/Browser Forum Baseline Requirements, which every publicly trusted authority follows [2].

What a renewed certificate takes from the previous one and what is replaced
ItemAt renewalRule
Datesalways new; the old certificate still ends on its own datesigned with the rest of the certificate [1]
Serial numberalways newunique for each certificate an authority issues [1]
Maximum lifetimethe ceiling in force on the day of issuance200, then 100, then 47 days [2][3]
Time left on the old certificateadded only if the authority does so, and never past that ceiling§6.3.2 [2]
Domain validationmay be reused if completed within the reuse period, otherwise repeated200, then 100, then 10 days [2]
Organisation identity (OV)may be reused if verified within the reuse period398 days [2]
Key pairnew if the request carries a new keyyour choice
Namesexactly what this request listsyour request

The shrinking reuse period changes what renewing certificates involves. From 15 March 2029 a domain validation older than 10 days cannot be reused, so a 47-day certificate renewed on schedule goes through domain validation again each time. The DNS record or web path that passed the check at first issuance has to keep passing it.

When to renew

Early enough that a failure can be fixed during working hours, which means at least a week before the end date rather than on it. That margin absorbs a failed validation, a support ticket or someone being away.

Ask your authority whether time remaining on the old certificate is carried over to the new one. Practice varies between SSL certificate authorities, and the maximum lifetime limits what can be carried: the new certificate never runs past the ceiling in force on its issue date, whatever was left on the old one [2].

The intervals are getting shorter. The CA/Browser Forum ballot SC-081v3 set the maximum lifetime of publicly trusted certificates in steps: 200 days for certificates issued since 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029 [3]. At 47 days, a certificate renewed by hand needs attention about eight times a year, which is the practical argument for automation.

If the certificate has already expired

An expired certificate has no grace period. From the moment the end date passes, every browser shows a full-page warning, ERR_CERT_DATE_INVALID in Chrome, and the site stays unreachable until a valid certificate is served. The website is rarely the only thing that uses the certificate: APIs, webhooks and mail can depend on it too. Restoring service comes first, and the order of work is on what to do when an SSL certificate has expired.

Renewing with a commercial authority

The process repeats the first issuance:

  1. Generate a new key and a certificate signing request, listing every name the certificate must cover. A new key is better practice than reusing the old one, because it limits how long any single key is in service.

  2. Submit the request to the authority.

  3. Complete validation. For domain-validated certificates this is quick; organisation and extended validation can involve documents and review, so start those earlier. See certificate types. A check the authority completed within its reuse period may not be repeated.

  4. Download the certificate with its chain, install both, and reload the server.

Renewing automatically with ACME

ACME, standardised in RFC 8555, is the protocol a certificate authority and an applicant use to automate verification and certificate issuance, without a person involved [5]. An ACME client on the server, or the platform serving the site, renews well before the end date, proves control of the domain, installs the result and reloads the server. Renewal then becomes a scheduled task rather than a calendar reminder.

Automation fails quietly when it fails. A renewal job that stops running reports no error, and monitoring built on the same job sees nothing wrong. Keep one check that is independent of whatever renews: a test from outside that asks each hostname which certificate it serves and how many days it has left.

Verifying afterwards

Run this after renewing a certificate, from a machine other than the server, for every hostname it covers:

$ openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -dates -ext subjectAltName

Three things to confirm: the dates are the new ones, every expected name is listed, and the chain is complete. The chain check stays visible in the terminal next to the dates, because openssl s_client prints it separately from the certificate it passes down the pipe: a depth= line for each certificate checked, 0 for the server's own and 1 for the intermediate that signed it, and a verify error line under any certificate that fails [4]. No verify error line means the chain checked out. verify error:num=20:unable to get local issuer certificate under depth=0 means the server does not send the intermediate; under a higher depth, the client does not trust the root. verify error:num=10:certificate has expired means a certificate in the served chain has expired: under depth=0 the old certificate is still the one served and the renewal has not reached visitors; under depth=1 the chain still carries an expired intermediate; see certificate chains. Repeat the check for mail servers, APIs and anything else that uses the certificate.

FAQ

Does renewal extend my existing certificate?

No. Renewal issues a new certificate with new dates. The old one expires when it always would have, and visitors receive it until the new one is served.

I renewed my certificate and the site still shows it as expired. Why?

The new certificate is not being served: it was saved where the server does not read it, the server was not reloaded, or a load balancer or CDN in front still holds the old one.

How early should I renew an SSL certificate?

At least a week before it expires, so a failed validation or installation can be fixed in working hours. Automated renewal should start earlier, with time to retry.

Do I need a new CSR to renew?

With a commercial authority, usually yes, ideally with a new key. ACME clients create both themselves.

How do I renew an SSL certificate?

Generate a new key and signing request, or let an ACME client do it, complete validation, install the certificate with its chain, reload and check from outside that the renewal is served.

Sources

  1. IETF, RFC 5280, Internet X.509 Public Key Infrastructure Certificate and CRL Profile — §4.1.1.3 signatureValue, §4.1.2.2 serial number, §4.1.2.5 validity, §6.1.3 basic certificate processing.

  2. CA/Browser Forum, Baseline Requirements for TLS Server Certificates (version 2.3.1) — §4.2.1 validation data reuse periods; §6.3.2 maximum validity period.

  3. CA/Browser Forum, Ballot SC-081v3 — schedule of reducing validity and data reuse periods.

  4. OpenSSL, X509_STORE_CTX_get_error manual page — verification results X509_V_ERR_CERT_HAS_EXPIRED (certificate has expired) and X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY (unable to get local issuer certificate), error depth in the chain; openssl-verify manual page — diagnostics; openssl-x509 manual page — options -dates and -ext.

  5. IETF, RFC 8555, Automatic Certificate Management Environment (ACME).