OK, by now you've created a CA, and you're managing it... but what happens when you made a mistake? What happens when you need to change your CRLdp extension? What if you need to add some extension you didn't think of?
Sure, if you haven't yet issued any certificates, maybe you just start over, but what if that's not an option? You can change some parts of your CA.
The concern, of course, with a modification of the CA is "will certificates still validate." And the answer is "maybe." Provided you keep the same key-pair, it's the CA private key that signed the certificates and a hash of the CA public key that's in the certificates AKI extension. So provided the keypair stays the same, certificates should continue to validate. However, if for AKID you're using the Subject and Serial of the CA's parent, then the Serial number will have changed, and verification will fail.
However, it's wise to consider other ramifications of the change you want to make. For example, if you're going to change the CRLdp extension, all certificates signed after the modification would have the new URI for your CRL, but all certificates before this will have the old one. So, you would want to keep the old URI up-to-date until all certificates issued prior to the modification have expired. It's easy to make the mistake of thinking "oh, I can always revoke the old ones" - but remember that anyone checking for this will be checking the URI in the old certificate and thus the old URI!
Obviously I can't list all possible changes and their ramifications here, but it is important to consder the ramifications of a change to your CA mid-stream. That said, there's many times when this is useful!
First and foremost, you need a your original request from when you generated your CA. Now, if you don't have it (if you used the x509 to create a self-signed certificate instead of req and ca as demonstrated in my method, then you'll need to use your existing certificate to re-generate the CSR.
You can do this using req as follows:
openssl x509 -x509toreq -in cacert.pem -out phil.pem -signkey private/cakey.pem
However, note well that due to a bug in the x509 command any extensions are not transfered to your new CSR. So, for example, if you used my method for creating a CA where the email address is only in SubjectAltNames extension and not anywhere else, this method will not work for you - you'll lose that email address.
Obviously you'll need the CA private key, and your CA directory with the index and serial files, etc.
First, make a backup of your CA keys and confs:
tar zcf ca-pre-modification.tar.gz ca/
Now, if your change involves a modification to the openssl.cnf (such as a CRLdp change), then adjust that now. If it involved a change to the signing command then be sure to adjust the following command. Once you're ready, simply re-sign:
openssl ca -create_serial -out cacert.pem -days 365 -keyfile private/cakey.pem -selfsign -extensions v3_root_ca -config ./openssl.cnf -infiles careq.pem
Now, you have a new CA certificate - but you'll need to test this CA against a pre-existing certificate prior to doing anything else. To do this, run:
openssl verify -CAfile cacert.req some_cert.crt
Where some_cert.crt
is a cert signed by your CA prior to the modification. You'll probably want to test a few certificates - particularly if different certificates have different kinds of AKI extensions. Once you're satisfied that every variant of certificate you've issued prior to the modification still verifies, you're done!