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

  • 1
    CA certifications shouldn't have long expiration dates. Honestly; No single certificate should be longer then 2 or 3 years. This forces you to increase the key size, to avoid weak certifications, in the future. – Ramhound Mar 8 '16 at 13:19

How can I renew my certificate authority signing key?

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.

Is there a way I can simply create a new ca.crt file with a longer expiry date?

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:

  • Use same public key for CA
  • Use same Distinguished Name for CA
  • Use new Serial Number for CA
  • Install newly issued CA on all client machines
  • Do not re-issue end-entity certificates

According to https://serverfault.com/questions/306345/certification-authority-root-certificate-expiry-and-renewal the following sequence should work:

openssl req -new -key key/ca.key -out key/newca.csr
openssl x509 -req -days 3650 -in key/newca.csr -signkey key/ca.key -out crt/newca.crt

Renew Root CA

openssl req -new -key key/ca.key -out key/newca.csr
openssl x509 -req -days 3650 -in key/newca.csr -signkey key/ca.key -out 

Key prv/public CA is the same, serial is new.

openssl verify -CAfile ./cacert.crt_old -verbose mail.cert
error 20 at 0 depth lookup: unable to get local issuer certificate

openssl s_client -showcerts -CAfile ./cacert.crt -connect mail.corp:443
Verification error: unable to verify the first certificate

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.