Recently Windows Azure Storage SSL certificate expired and that causes a lot of problems. Now the certificate can be retrieved by any user and so everyone could have noticed that it was going to expire.
Now what's the typical timeframe of replacing a soon to expire certificate? Is is a month before expiration or a week before expiration or any other time?
In other words, suppose I'm validating a third party service certificate and see that it expires in N days. If I notice it one day in advance it may be too late - I'll need time to contact the service owner and they will need time for reissuing the certificate and replacing it. If I notice it one month in advance - it may be too early to raise alarm - maybe the service owner is about to replace the certificate a bit later.
What's the value of N such that if the SSL certificate is about to expire in N days it's likely that the service owner has forgot about its expiration? What's the common practice of when to update a soon to expire SSL certificate?
I'm afraid the most common practice is "scrambling to replace it when it's already expired"...
But in addition to the very useful info listed by Kormoc, I'd strongly advise you to use a vendor who will send alerts - and make sure that those alerts to go a mailbox that someone will actually watch. If you set it to a personal address within the company, you risk that person being on vacation or sick or even having left the company. Instead, make sure you have an address that is either a group mailbox or a mailinglist that expands to several people.
If you've got any kind of monitoring system, you can also set a cron job to run e.g. once a week that reports the number of days to expiry, and start alerting you when the number of days drops below a certain value.
I'm a big fan of monitoring systems. NAGIOS's standard plugin
check_http
has a check for SSL certificate expiry, and you can set that go WARNING a certain time before, and CRITICAL another, shorter, time before. So I guess the first piece of my answer is not to let the certificate vendor, or anyone else, be responsible for notifying you. Have your own automated system that does it, and ensure it does it when you determine it should be done.What should those times be set to? You know how long it takes you to turn a notification into a valid freshly-minted CSR, how long your your certificate vendors take to turn around CSRs, and how long it takes you to schedule downtime to get the new certificate installed on each server. Add those three times together, and that's the bare minimum time to generate an automated notification; a good NAGIOS CRITICAL threshold value.
Then add on a comfy margin for holidays, inertia, etc., and that's a good WARNING threshold. In my case I add two weeks for that.
In addition, if the failure of service would be business-critical, add at least an extra week to avoid that happening.
And as a final tip, if you're just using bog-standard SSL certificates, and you're currently paying a lot for them, find a cheaper fulfilment house and buy longer-period certificates instead. The best way not to miss an SSL certificate renewal is not to have one coming up any time soon.
Comodo starts alerting at 60 days, http://www.instantssl.com/ssl-certificate-support/server_faq/ssl-certificate-renewals.html
GoDaddy recommends 60, http://support.godaddy.com/help/article/864/renewing-your-ssl-certificate
Entrust recommends 30, http://www.entrust.net/ssl-technical/renew_faq.cfm
Others don't seem to have a start recommendation easily found
Universally it seems to be documented that to renew before the 15 day mark.
A nice helper script is
ssl-cert-check
See the article "Proactively Handling Certificate Expiration With ssl-cert-check" for further informations
For ubuntu it is part of the universe repositories.