The short answers are "Don't do that, in most circumstances" and "probably re-issue them".Hello! May be this is faq, but I can't find any info which explains what I need to do in step-by-step manner what I need to do in case of CA expiration. I generated CA about 8.5 years ago for 10 years (default value), so I'll face CA expiration soon enough. I have ca.key and ca.crt, as I understand I can create new crt by the same key for next 10 years, but what I need to do with existing certificates. As you can see I run openvpn for 8 years but still know nothing about certificates :-(Could you point me to instructions or explain me what to do? :-) Thank you!
The longer answer has several points:This is a middle-of-the-road summary. If you only have three certificates (your CA, your server, and yourself), you can do a lot less work. If you have millions of certificates, you need a lot more planning and infrastructure.
You also need to consider what the cost is of a security breach.a) re-using the same key is a bad idea. After 10 years, you probably can afford a larger key size. And you've given any adversary plenty of time and material to attack, assuming a single-level CA.
b) Client certificates with expiration dates past the CA's expiration are often treated as invalid by validators. It doesn't make sense for a CA to say 'I can be trusted until 2011, but I'm verifying Fred's identity until 2040'!
So client certificates probably expire before, or at the same time as the CA. That means you have to re-issue them. Thus, you might as well generate new keys. Re-using the CA keys doesn't save you anything.
c) What you do is create your new CA certificate, and add it to the Trusted CAs file (or directory) that you distribute.
You want the valid-from date to be before the old CA expires, so you can start issuing and using new client certificates. This allows a smooth roll-over from the old to the new certificates.
Allow time for it to be adopted; end-users won't pick it up instantly - if you can push it to them, it will save a lot of calls at expiration.
When the old CA certificate has expired, you may (or may not) want to remove it from the trusted CA list.
Considerations:a) It may be necessary to validate older material - say a signed e-mail from the period that it was valid. b) Some (mostly very old) software doesn't check expiration dates - especially embedded systems without clocks. They could be fooled if the old key is later compromised.
There's no perfect answer, but one reasonable compromise (depending on your environment) may be to leave the old CA in your trust list for a while, then archive it. In any case, destroy the private key so that nothing new can be signed by it.
If you issue intermediate CA certificates, similar considerations apply. If not, this is a good time to consider it. With an intermediate certificate, the CA certificate can have a longer expiration date (it only signs the intermediates, and its signing key is kept off-line). You still have the intermediate certificates expire - often on a shorter period. But the distribution effort is much less, as the servers (web, mail, ldap, etc) send intermediate certificates with each response. The client's trust list only needs to hold the top level CA - so if it's widely distributed, the less often the top level CA changes, the easier it is. But you still get the security of (more) frequent intermediate CA changes.
d) On the client side, there are similar issues. Newer software will ignore expired client certificates, so keeping them around so you can validate/decrypt old e-mail and files is important.
Note that in the latter case, you must retain the private client's private keys for decryption. (But not the CA's.) If the client's private key is destroyed, anything encrypted with it will be unrecoverable. (From e-mail to file systems!) Although it is not as secure as issuing new ones, re-using the client's private key may be expedient for this reason.
There is older software, including some popular web browsers, that does not ignore expired client certificates. They will annoy you by offering you an expired certificate when client authentication is used. But these all have security issues, so upgrade the browsers!
This is necessarily a brief summary of complex issue. I hope it puts you on the right track.
-- Timothe Litt ACM Distinguished Engineer -------------------------- This communication may not represent the ACM or my employer's views, if any, on the matters discussed.
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
