If I have deployed a digital certificate on a webserver and if it needs to be renewed then what steps do I need to follow? Will I need to generate a new longer public key private key pair? Why do certificates need to be renewed in the first place?

4 Answers 4


You don't need to generate a new key unless you want to or the key has been compromised (but hopefully if you know they key was compromised you've long since replaced it).

Most CA's will let you reissue a cert with the same subject, simply updating the expiration date.


You'll need to follow the same steps as for purchasing the certificate in the first place, including generating a new (but not necessarily longer) key pair.

Certificates expire partly because the certification companies like the regular business, but mostly because there are no good processes for revocation of compromised certificates in end-user web browsers, so having an expiration date on the certificate at least means that it can't be misused indefinitely if it gets compromised.

  • do the old certificate serial number go to the certificate revocation list's
    – user1184
    Jan 24, 2011 at 17:13
  • 3
    No, the old certificate won't be revoked, it will simply expire.
    – Mike Scott
    Jan 24, 2011 at 17:19

A certificate must be renewed because it has an expiry date. When the certificate has expired, clients will refuse to use it anymore (in the context of the Web, browsers show a scary warning in that situation).

So the question is: why is there an expiry date in the certificate ? Theoretically, this is a way to keep revocation lists small. A Certificate Revocation List (CRL) designates all certificates issued by a given CA and which must not be used anymore, even though they "look OK". Revocation is the act of "cancelling" a certificate. For instance, if a private key is compromised (stolen), then the rightful key owner informs the CA, which then revokes the certificate by including it in its periodically published CRL -- so that clients cease to accept the corresponding certificate. By construction, a CRL can only grow (like non-messiah people, certificates die and then stay dead), so a trick has been designed: expired certificates need not be included in a CRL (if a certificate is expired, clients will not use it -- they do not need to know whether it was also revoked). This keeps CRL size in check, since old entries are thus removed.

That's the theory about expiry dates. As for the practice, Peter Gutmann offers the following alternative explanation in his X.509 style guide:

This field denotes the time at which you have to pay your CA a renewal fee to get the certificate reissued.

A third explanation is that renewal allows the CA to migrate things. E.g. the URL at which the CRL can be downloaded is written in the certificates themselves; if the certificates never expired, that URL would have to be eternal -- and eternity is kind of long, for a business.

Which explanation you choose to believe in, is up to you.

As for the details of the renewal operation, they really depend on the CA. There is no conceptual impossibility for the CA to build a new certificate identical to the old one, except for the expiry date, sign it, and send it to you. This does not even require any action on your part. However, some CA will want more from you, possibly even the generation of a new key pair (as you did when you got the first certificate). The CA might require a longer key, if they have a strict policy about key lengths and the old key no longer complies with that policy. In theory, it is not the CA job to enforce minimal key lengths (clients should make that decision on a per-instance basis), but in practice the CA do mandate key types and lengths. The CA may also require a new key generation in case they did not bother implement a specific renewal operation.

  • This answer may have been accurate in 2011, but it misses the mark today. Due to several issues with CRLs and OCSP queries, browsers today silently ignore revocation failures (i.e. unable to download a CRL / get an OCSP response); this is not good. Reducing a certificate's validation period has become the defacto work-around. (Indeed, if a certificate were only good for 24 hours, the liklihood of it having been compromised should drop to near-zero.) Newer approaches to handling revocation checking include OCSP Stapling and Mozilla's CRLite (which leverages Cascading Bloom Filters).
    – GLRoman
    Jun 16, 2021 at 23:26

Why do certificates need to be renewed in the first place?

That happens because:

  • You lost your private key
  • Your private key is stolen
  • You want yourself to revoke the old instance of your certificate
  • Your certificate reached its expiration day
  • The password that protects your private key has been compromised
  • You have misused somehow your actual certificate

Will I need to generate a new longer public key private key pair?

No. Unless your CA asks you that for a reason or an other.

If I have deployed a digital certificate on a webserver and if it needs to be renewed then what steps do I need to follow?

It all depends on your CA, but in general you have nothing to do by yourself.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .