💾 Archived View for gemini.thegonz.net › glog › 220115-keyRotation.gmi captured on 2024-03-21 at 15:12:51. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-04-28)
-=-=-=-=-=-=-
This was discussed on the mailing list some months ago, but now I've actually put it into practice.
The key this server was using was due to expire this year. I have now replaced it with one set to expire in 7497. However, there is no need for your client to ask you to trust the new key, because it is signed by the old key. I suspect that many clients will ask anyway, but e.g. my client diohsc will not.
This seems to me like a pretty decent way of doing occasional key rotations within TOFU. Not perfect, but much better than simply changing to a new self-signed key and requiring visitors to trust from scratch again.
I encourage any client authors reading this to support this technique. If the key presented at a host has not been seen before but is signed by the key which is currently trusted for that host, then that trust should be transferred to the new key.
For testing purposes, I'm preserving the old certificate (which signed the new one) here:
There is one small annoying problem with this approach: some verifiers require the distinguished name of the issuer to not be identical to that of the subject, whereas for Gemini it is natural to have both just give the hostname as Common Name. I solved this by adding a "GN" field to the new cert.
Here's how I created the new key:
openssl ecparam -genkey -name prime256v1 > new.key
openssl req -new -days 2000000 -x509 -sha256 -subj "/CN=*.thegonz.net/GN=2" -key new.key | \
openssl x509 -CA old.crt -CAkey old.key -CAcreateserial -days 2000000 > new.crt
Replace the CN with your own hostname, and old.crt and old.key with your current cert and key (and increment GN if you iterate the process).
René Wagner implicitly asks why I didn't just keep the old key but use it to sign a new certificate with a later expiry date.
That is a perfectly good method for dealing with premature expiry, and I agree that clients should accept such a certificate without complaint (as long as the originally accepted certificate hasn't expired when the new certificate is received). But the point is that sometimes you do want to actually rotate the key. In this case, I wanted to take the opportunity to move from a bulky RSA key to a lither elliptic curve key. (I'd have liked to have made it Curve25519, but that isn't universally enough supported yet.) Other cases where you want to rotate are when the cryptography underlying your key looks close to being broken, and when you fear that your key in particular may have been compromised.