💾 Archived View for gemini.thegonz.net › glog › 220115-keyRotation.gmi captured on 2022-03-01 at 15:03:05. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
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).