Today, I was asked by a client to look at best practices for digital certificates, such as X.509 and the like. I extended that research to include all types of encryption certificates, SSL/code signing, etc.
Basically, there was a dearth of best practice information available for setting the expiration dates on certs issued for various purposes.
We found a wealth of mentions in PCI, FFIEC, FDIC, NCUA, HIPAA, NIST and other guidance about checking to make sure that expiration dates were valid, reasonable and such, but no real guidance for what “reasonable” is or anything to cite to make a statement that your approach and processes fit the reasonable judgement. There were plenty of guidance sources on checking authenticity of certs, vendor selection and all of that, but little to help organizations in their attempts to define reasonable best practices for how long certs should live once issued.
Our next step was to take a look at the practices of some of the leading certificate vendors and see if we could establish a consensus from their approaches. Quick checks into their process revealed the following:
The major certificate vendors (Verisign, Thawte, etc.) issue certificates with a maximum life span of 2-3 years for most purposes. They explained that this minimized the overhead management work for them while establishing enough care for cryptographic changes (this doesn’t happen right? MD5 nightmare anyone, anyone?), organizational changes and churn in their client base. Secondary vendors (Comodo, RapidSSL, GlobalSign, etc.) in this arena issue certificates for a maximum of 5 years. It appears that they are willing to extend trust a little further to minimize their workload/overhead in management of the certs and processes.
Generally speaking, after reviewing this data, the various standards and processes and the mechanisms that the “big boys” use, I would offer the following as a best practice for setting up expirations on certificates in general.
The best practice for establishing expiration dates on certificates should be two years with a hard set maximum of five years. Two years should be the established baseline for processes and organizations with any increases (up to a maximum of five years) requiring appropriate risk assessment/acceptance from responsible parties in an organization.
I hope this helps folks who are working on establishing certificate systems and other processes in their organizations. If you disagree with my approach or work, please let me know. I am always open to comments via the blog or @lbhuston on Twitter. Thanks for reading!
Curious, I have been bouncing this around for years. What is the true risk of having a certtificate valid for more than 5 years? I mean the ‘real’ risk. At least for client/user certs rather than CA, Trusted level certs.
Why would I for example want or need to change my personal SMIME cert on an annual, or even a 5 year basis? Who is going to steal it and use it without the passhrase to my private key for installation/import purposes?
Why not 10 years, or possibly about as long as I am likely to ever use the same messaging service??
Matt
As the blog post says, this is really more about the risk of crypto changes and business practices than the loss of confidentiality of the cert. If you have confidence in your cert, I see nothing wrong with extending its use until you become uncomfortable or a compromise of its security occurs.
In terms of business best practices, the CAs would have to answer the question as to why they designed the system this way.
Thanks for reading!