Whoops my certificate has expired – what do I need to do?

The amount of work depends on what has expired.

• If the root CA has expired then you need to reissue all certificate which include the root CA, and update trust stores
• If the enterprise CA has expired you need to renew all certificates signed by the enterprise CA, and update trust stores with the new certificate
• If your personal certificate has expired, you need to renew that certificate.

The amount of work also depends on the size of your enterprise.

I’ll list the work need if the certificate is going to expire next week – as this is more work than if it has already expired

If your personal certificate is going to expire

You need to

• renew it, create a new private key and certificate request
• or extend the date of the existing certificate  – by re-signing it
• update the keystores which include it.  This could be those used by java programs ( .p12, or .jks) as well as any browser keystore (.nssdb)

To renew your personal certificate

You can just recreate it.  If you are considering to use a stronger algorithms, such as Elliptic Curves, bear in mind that the servers need to be able to support what you specify.

Depending on how your openssl has been configured, if you have unique_subject = yes you may need to use openssl revoke… to remove the old personal certificate from the configuration.   This is to ensure there is only one certificate with the same distinguished name, and online checking of certificate validity (Certificate Revocation Lists and Online Status Certificate Protocol) can be used.  If you have unique_subject = no, you can recreate the certificate without revoking it.

• openssl genpkey  to generate a new private key
• openssl req to create a request

You do not need to recreate it – you can just sign it again.

You then need to do normal process of update the users of the certificate.

• openssl ca to sign the request
• openssl pkcs12 -export to create the .p12 file
• You may want to deploy it only when the machine is attached to the local network.  If you download it over wireless, or email, these may be compromised, and the bad guys can just use the new copy.  Downloading it over a wired connection eliminates this risk.
• certutil -D $sql -n $shortName to remove the certificate from the browser’s keystore
• pk12util -i $shortName.p12 $sql -W password to add the certificate to the browser’s keystore
• /opt/mqm/bin/runmqckm -cert -delete  to remove a certificate from a keystore (.jks)
• /opt/mqm/bin/runmqckm -cert -import to add a certificate to a keystore(.jks)
• restart the servers to pick up the new certificate

Rather than deleting the certificate from the keystore and adding the new one with the same short name,  you may want to make a copy of the old certificate from the keystore, or simply backup the whole keystore – as it should not change once frequently.  If there are problems, restore from the backup.

To renew your enterprise certificate

This requires a lot more work than updating a personal certificate.

Just like the personal certificate you can recreate it, or just sign it again.

You need to phase in the new certificate as it may take days or weeks to deploy it successfully.

The client’s trust store needs the CA certificate matching the CA used by the server’s certificate.

If you have two servers, and change servers to use the new CA certificate, the client’s trust store content will change over time.

• The old CA certificate – before any work is done
• Both old and new CA certificates during the migration period.  The server using the old CA will use the old CA in the client.   The server which has been migrated to use the new CA will use the new CA in the client.
• Just the new CA certificate.  Once the migration has finished. The old certificate can be removed when all of the servers have been migrated, or the certificate has expired.

A key store and a trust store can have certificate with the same distinguished names, but with a different short name or alias name.  My enterprise is called SSS, and the CA for my enterprise is CASSS… .  My trust store has

• the CA with C=GB,O=SSS,OU=CA,CN=CASSS and short name CASSS2016 and
• the CA with C=GB,O=SSS,OU=CA,CN=CASSS and short name CASSS2020 and

When you maintain a keystore you use the short name, for my example CASSS2016 or CASSS2020.

During the TLS handshake, when the server’s certificate is sent to the client, it is checked against all of the trusted CA certificates in the keystore, so having two certificates with the same DN does not matter.

The steps to deploy your new CA are

• Get the new CA.  Either create a new CA using the latest algorithms and cipher suites (the better solution), or have the old certificate resigned.
• For each user and server
  • Deploy the CA certificate into the trust stores with a new name – eg CASSS2020
• For each user and server
  • Renew or recreate each personal and server certificate and sign it with the new CA
  • Deploy it securely to each user and server and replace the old personal certificate
  • You may want to deploy the private key only when attached to the local network.  If you download it over wireless, or email, these may be compromised, and the bad guys can just use the new copy.  Downloading it over a wired connection eliminates this risk.
• For the server create java.security rules to disable weaker algorithms and cipher specs.   It is easy to undo this change.
  • This should identify any user not using the latest cipher suites and certificates.  These rules can be relaxed while problems are fixed.
• For each user and server
  • Make a copy of the old CA certificate prior to deletion
  • Delete the old CA certificate from the trust stores eg CASSS
  • After a validation period delete the copy of the old certificate

Start all over again!

You can see how much work you need to do when you renew your enterprise CA, so make sure you  renew it in plenty of time – months rather than days.