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?
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.
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:
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.