Hi Greg and Jason, Greg Vickers wrote:
> Hi all, > > Jason Haar wrote: > >> Greg Vickers wrote: >> >>> Thanks again - we will do a re-key. Would I use the CA.pl script and >> > > <snip> > >> I really hope someone who knows more than Greg and I can give an >> authoritative answer to this question. I'd LOVE to know how to recreate >> a CA cert (instead of creating a new one and having to touch 1000's of >> machines to update them). But I get the feeling this can't be done > > > I found this article: http://www.debian-administration.org/articles/284 > Search for "renewing certificates" and you will see the following text: > > > Your certificate chain can break due to certificate expiry in two ways: > > * The certificates you signed with your root certificate have > expired. > * Your root certificate itself has expired. > > In the second case, you have some work to do. A new root CA > certificate must be created and distributed, and then your existing > certificates must be recreated or re-signed. > > > So that would seem to indicate that upon expiry of a root certificate > you have to create a new root certificate and recreate/resign any > certificates in use on web servers or whatever... bleck! I'll keep > looking unless someone confirms this behavior and dashes the hopes of > Jason and myself :P > > Thanks, If you have certificates which are to expire later than the CA root certificate itself, you can not perform re-key of CA root certificate. The term re-key refers to procedure of creating a new key-pair (see, for example, rfc3647, sections 4.3.3 and 4.4.7, you can download the rfc here: http://www.faqs.org/rfcs/rfc3647.html), and obviously the certificates will not be validated with the new key-pair. A solution could be one which Jason described. May be the reason by which the new root certificate is not recognized is that the serial number was changed? Anyway, you can perform a renewal of a root certificate (that is, leaving the key-pair intact, just producing a new certificate) by extending its lifetime and preserving everything else, including the serial number (which is usually 00 for root cert.). The following commands will do the extension (you need some tricks with index.txt file because of poor functionality of openssl x509 command): # I assume that you're using the Unix-like operating system here :) mkdir tests # Directory, where the cert is renewed cd tests echo "00" > serial # Serial file, indicating that our renewed cert will have the serial number of "00" touch index.txt # Fake textual database where issued cert will be registered, could be removed later # Converting existing certificate to a CSR openssl x509 -x509toreq -in ORIGINAL_CACERT -signkey ORIGINAL_PRIVATE_KEY \ -out certreq.csr # Renewing the certificate, extending its lifetime openssl ca -config CONF_FILE.cnf -startdate STARTDATE -enddate ENDDATE -in certreq.csr \ -out cacert_renewed.pem -keyfile ORIGINAL_PRIVATE_KEY -cert ORIGINAL_CACERT \ -extensions ca_ext # maybe you'll need also -policy POLICY_SECTION # Here the STARTDATE is that of your existing # root cert in a form YYMMDDHHMMSSZ # (you can obtain it with "openssl x509 -in ORIGINAL_CACERT -noout -dates") # For example "Dec 1 23:29:21 2003 GMT" will become 031201232921Z # The ENDDATE is the date which you'll set as the expiry date of renewed certificate You can use the original conf file for CONF_FILE.cnf, but MAKE SURE you've changed the value of "dir" (where everything is kept :)) to point to "tests": dir = tests All issued certificates should be validated OK when using the renewed certificate. (So you'll not be forced to resign issued certs). I hope this helps. You can also find this sites useful: www.eugridpma.org, http://ca.dutchgrid.nl/ Arsen. -- PGP Key: ID 0xBBE3DFD8 (expires: 2006-08-03) Fingerprint: 1C3B 2C01 40DF ED87 23B1 BF6F 95C4 2E77 BBE3 DFD8
smime.p7s
Description: S/MIME Cryptographic Signature
