I am a noob considering certificate authorities. I followed this article a while ago to setup my own certificate authority and with its help setup my own freelan VPN network:
https://github.com/freelan-developers/freelan/wiki/X509-certificates-generation
Basically, all I had to do was call:
openssl req -new -x509 -extensions v3_ca -keyout key/ca.key -out crt/ca.crt -config ca.cnf
The issue is that my ca.crt certificate, which I believe to be the public key to ca.key is now expired according to openssl. I have used this certificate to sign other keys, though and would not want to have to go through that again.
Is there a way I can simply create a new ca.crt file with a longer expiry date?
I don't remember if I had to set the expiry date of ca.crt somewhere, but I don't believe I did, because it was only valid for 1 month. I would like to know if this is expected and recommended or actually a mistake I made along the way? How long should the ca.crt certificate be valid for, really?
I have found different commands online, but am not sure which one is right for me e.g.: https://stackoverflow.com/questions/13295585/openssl-certificate-verification-on-linux
https://serverfault.com/questions/306345/certification-authority-root-certificate-expiry-and-renewal
Best Answer
You have two issues to contend with. First is the continuity of end-entity (server and user) certificates. Second is the changing of the Root CA.
Yes, but see the details below.
The first issue, continuity of end-entity (server and user) certificates, is mostly resolved by using the same public key when you roll over your Root CA.
The new self-signed Root CA will still need to be installed into the relevant trust stores, but the key continuity means the end-entity certificates will not need to be re-issued. If you use a new public key for the Root CA, then you will need to reissue all of the end-entity certificates.
The second issue, rolling over the Root CA, must happen because its expired. This is the same problem as re-certifying a Root CA because the hash is changed from SHA-1 to SHA-256 to comply with CA/Browser Baseline Requirements. A number of CAs have done this in real life.
The impact of the rollover can be lessened by using the same public key. This will also help with enhanced security controls, like pinning a CA's public key. If the CA certificate is pinned (as opposed to the public key), then it will create a lot of extraneous noise in tools like Cert Patrol.
To roll over the CA, you need to create an "equivalent" Root CA certificate (or as close to equivalent as can be). The way user agents uniquely identify a certificate is outlined in RFC 4158, Internet X.509 Public Key Infrastructure: Certification Path Building.
The short of RFC 4158 is the pair {Subject Distinguished Name, Serial Number} can be used to uniquely identify a certificate in a store. As a CA or Issuer, you are supposed to ensure serial numbers are unique, even if you re-certify.
End-entity certificates have additional ways to be uniquely identified, including the Authority Key Identifier (AKID). In fact, a server's certificate can use a hash of the Issuer's {Subject Distinguished Name, Serial Number} as its AKID (if I recall correctly).
You seem to have figured out how to create a self signed CA certificate, so I won't discuss the OpenSSL commands.
The real problems occur when your public/private key pairs are compromised. You can't roll over your CA under the existing public key, so you have to issue a new Root CA certificate and re-issue all end-entity certificates.
To recap, here are you actionable items: