Like credit cards, Digital Certificates have expiration (ValidTo) dates. They also have start (ValidFrom) dates, which most credit cards don’t have. Normally the start date is the issue date, but it doesn’t have to be. You could start the validity period a week or a month after the issue date. The end date is normally 1 year (or however long you paid for) after the start date. The certificate is only valid between the start and end dates. It is up to the software that uses the certs to not use it outside of the validity period. There are times you have to use an expired cert (or the corresponding private key). For example, to open old encrypted messages in your Email message store. One solution is when you renew your certificate to go through the message store and decrypt any encrypted messages with your old private key, then encrypt them again with your new public key. Once that is done you can toss your old cert and private key (or at least archive them).
Certs can be issued for any validity period. It is common to issue them for 1 year, 2 years or even 3 years. The longer the cert life, the less frequently you have to renew them, but the more likely it is that the information in the cert will no longer be current or accurate. Recently, some vendors (like Apple) have said they they will not accept certs longer than 13 months after their start date.
You can ask a CA to renew your cert any time (usually for free). The end date will normally not change unless you paid for a cert lifetime longer than the original validity period. You don’t get additional certificate lifetime unless you paid for it. In some cases, you can even change the SubjectDN information when you renew (say if you changed your name or email address). Of course the new information must be validated the same as for the initial issue.
Many people believe that CAs put expiration dates on certs just so they can charge you again for a new cert once a year. The real reason is to force the issuing CA to review the identifying information in the cert’s SubjectDN, and update anything that is no longer valid or current. There is nothing that says the CA has to charge a full certificate price when they renew a cert, or charge anything at all. Some CAs still sell 2 and 3 year certs, and will renew them for free until you have used up the lifetime you paid for.
Another reason for an expiration date is to keep the revocation list from growing without bound. Once a cert reaches its expiration date (actually a bit after that), it can be purged from the appropriate CRL (or OCSP database). Without expiration, CRLs could grow without bound.
Once a cert has expired, it must be renewed. This is very similar to doing the initial certificate request. You can create a new CSR and new private key with the same info as the existing cert and submit it to the CA for signing as usual. If you happened to save the old CSR and private key, you can just re-submit it (which would be renewal with rollover).
There are two ways you can renew a cert:
Renewal with Rollover – you keep the old public and private keys but create a new certificate with a later expiration date. I call this “old wine in new bottles”. In this case, you can still open all your old encrypted emails. You still need to update your cert in shared address books, since the old cert will now be rejected as “expired”. The downside is that the longer you use a given keypair the more likely it is to have been compromised. At some point you really should do renewal with replacement.
Renewal with Replacement – you create a whole new keypair and use that to create the renewal CSR. I call this “new wine in new bottles”. In this case, you will need the old private key to open old emails (unless you bulk re-encrypt all old messages with the new public key). You also need to publish your new cert in any directories the old one was published in (and hopefully notify people using your cert to refresh their copy from the shared address book). The longer you use a given keypair, the more likely it is to be compromised. So, with renewal with replacement limits the time you use a given keypair.
SixWallet can actually construct a valid CSR from any existing cert (even ones from other issuers), and then the new CSR can be submitted for signing as usual. You can even make changes to the SubjectDN information before submitting it if needed. It can do it with keypair replacement or rollover. The CA will happily sign the certs either way. They don’t keep track of your old key material to compare your public key with.