NOTE : a good open source cross platform CA is xca, https://github.com/chris2511/xca
Basically, you can create a new CA using the same private key and subject from the old CA. You replace the old CA certificate with the new one in Keychain Access. Finally, you continue creating or signing certificates in the normal way using Certificate Assistant.
Please try these steps using a test CA first. Make sure they work as expected with the test CA. That way if anything goes wrong, you won’t have affected your actual CA. Make a backup copy of your old CA before making any changes to it. Let me know if you have any questions.
Note: These instructions assume you need to renew a root CA and not an intermediate CA.
Procedure:
1. In Keychain Access, export your CA’s certificate as “old.cer”.
2. Convert the old CA certificate to a new PEM format file “old.crt”:
openssl x509 -inform der -in old.cer -out old.crt
3. In Keychain Access, export your CA’s private key as “old.p12”.
This will require you to set a passphrase to protect the exported file.
4. Convert the old CA private key to a new PEM format file “old.key”:
openssl pkcs12 -in old.p12 -out old.key
5. Make a backup of your old CA, including the old.* files and all files here:
~/Library/Application Support/Certificate Authority/Name of CA
6. Create an openssl.cnf file with settings that match your old CA cert.
Here is a minimal example:
[ req ]
distinguished_name = req_distinguished_name
[ req_distinguished_name ]
[ v3_ca ]
basicConstraints = critical, CA:TRUE
keyUsage = critical, keyCertSign, keyEncipherment, digitalSignature
extendedKeyUsage = critical, serverAuth
or
[ req ]
distinguished_name = req_distinguished_name
[ req_distinguished_name ]
[ v3_ca ]
basicConstraints = critical, CA:TRUE
keyUsage=critical, digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyAgreement, keyCertSign, cRLSign
extendedKeyUsage=critical, emailProtection, clientAuth, serverAuth, codeSigning, 1.3.6.1.5.2.3.4, 1.3.6.1.5.2.3.5, 2.5.29.37.0
You may need to change the keyUsage and extendedKeyUsage lines to match your old CA. See the x509v3_config(5) man page for more info.
7. Get the subject string from the old CA cert with this command:
openssl x509 -noout -subject -in old.crt
It should be a single line this:
CN=My Example CA, C=US/emailAddress=user@example.com
You may have more fields in your subject for city, organization, etc. You’ll use this in the next step when creating a CSR for the new CA. Ignore the subject= part
8. Create a new signing request using the old CA’s key and the openssl.cnf
file created in the last step:
openssl req -config openssl.cnf -extensions v3_ca -new -key old.key -sha256 -out new.csr -subj “SUBJECT_STRING_FROM_PREVIOUS_STEP”
9. Sign the new CA certificate using your old CA’s key:
openssl x509 -req -extfile openssl.cnf -extensions v3_ca -days 365 -in new.csr -signkey old.key -sha256 -out new.crt
Note that you can change the “-days” option if 365 days isn’t enough time before the CA cert expires. 7250 is about the max you can use
Also note this will create a random serial number for the new cert which shouldn’t interfere with serial numbers used by any of your existing signed certs.
10. Find an old certificate that you signed with your old CA. Verify the certificate using your old and new CA certs:
openssl verify -CAfile old.crt -verbose some_old_cert.crt
openssl verify -CAfile new.crt -verbose some_old_cert.crt
Do not proceed unless both report “OK”. If the new one doesn’t say “OK”, something went wrong.
11. Drag new.crt into Keychain Access. You will now have two identically named certificates which share the same private key. You will be able to tell which one is newer by the “Expires” column.
12. Delete the old root CA cert in Keychain Access. DO NOT delete its private key, since it is now the private key for the new CA cert.
13. Continue using the CA through Certificate Assistant as before. Test this by signing some new certificates.