Many folks and organizations are running their own Certificate Authority (CA) internally, to manage certificates for internal services and (infrastructure) devices, which won’t ever be exposed to regular users. Some manage those CAs manually, e.g., via OpenSSL directly, or via tools like easyrsa, cfssl, etc.
In the Freifunk Hochstift infrastructure, we use an internal CA for host certificates (e.g., used for Icinga2), internal services like LDAP, OpenVPN, NetBox, IPMIs, etc. The CA is managed by some helper scripts directly calling the openssl binary. When I created the CA back in 2015 I didn’t think much about the expiry date, set it to 10 years from then, and focused on the infrastructure to be set up. I’ve also set up monitoring for the certificates of the services, we deployed, but did not set up monitoring for the CA expiry.
So here we are, and recently, those 10 years were up, and our OpenVPN used for managed access stopped failing because it couldn’t connect to the Anycasted LDAP servers. All 4 instances failing at once was wild and didn’t make much sense. Some debugging revealed problems to be related to SSL/TLS, yet the service certificates were OK. After a while, I figured out the CA had expired, but now what?
Turns out, you can build a new certificate from an existing key and get yourself unstuck. As this journey wasn’t very pleasant, I stumbled across some mostly-but-not-fully-working articles out there, and had to dive into /usr/lib/ssl/misc/CA.pl, here’s the way I got myself out of this mess.