💾 Archived View for rawtext.club › ~sloum › geminilist › 001682.gmi captured on 2020-10-31 at 02:27:02. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
colecmac at protonmail.com colecmac at protonmail.com
Mon Jun 15 00:09:05 BST 2020
- - - - - - - - - - - - - - - - - - -
So I've realized that this will break a lot of workflows, I think.
Many sites on Gemini-space just use their Let's Encrypt cert for theirsite, but the Let's Encrypt tool, certbot, sets a new private key whenrenewing[1]. As far as I can tell, this is standard practice (certbot or no),and so I don't think that storing only the public key for TOFU is a good idea.
1: https://github.com/certbot/certbot/issues/231
However, this doesn't solve the issue Felix presented:
This means that trust in a server is lost as soon as a certificate is
expired and a subsequent renewal of the certificate with the same
private key is the same as visiting the host for the first time. But
when i refresh my server certificate before it expires (which is
recommended), we will have the situation that the client will not trust
the server anymore (same situation as when an attacker is doing a MITM
attack) which i think is not a good situation.
I'm not sure what to do about this. Both options seem bad, and both will causebreakage. It seems that there is no good way to do TOFU with certs, unlessyou want to try and control how servers use certs, like specifying that keypairsshould not change or something.
Solderpunk, I'd appreciate if we could work towards some general solution for this,and official recommendations for how to handle TOFU and cert renewal.
makeworld