💾 Archived View for bbs.geminispace.org › u › alexlehm › 4526 captured on 2023-11-04 at 16:11:10. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-09-28)
-=-=-=-=-=-=-
Re: "How many here use the same TLS certificate on their gemini..."
I am using letsencrypt and reuse the private key each time to avoid getting a new cert hash when it is renews. that seems to work fine
2023-08-19 · 3 months ago
@alexlehm Good to know that's an option, thanks! Is that the default or is some special setup needed?
Because of users getting notified about a new certificate each time it changes, which could also happen for a man-in-the-middle attack, it is best to use a certificate with a very high expiration date. Mine's 4095-12-12 and was created automatically by Agate, the Gemini server I use. But those high dates shouldn't be used on certificates on the web.
If your gemini server doesn't support creating certificates, the already mentioned gemcert can easily create one for you:
— https://tildegit.org/solderpunk/gemcert
Oh thank you @michaelnordmeyer and @Morgan for bringing up the point about getting notified when there is a new cert. I've tried to find posts about the differences between self-signed and CA certs and never came across that info. I suppose that doesn't effect any functionality, it's just a notification the user has to dismiss each time?
@alexlehm can you explain further or provide a link to more info on using the same key?
How about this for a thought? If I generate a long expiring cert from LetsEncrypt once just for the gemini server and save that seperately. Then let LetsEncrypt do it's normal thing (every 3 months) for the web server?
@supernova AFAIK Let's Encrypt only supports three months durations for security reasons.
Gemini doesn't support the chain of trust you have on the webs. Instead, it's trust-on-first-use. So any valid certificate will suffice as clients automatically trust valid ones, even self-signed ones.
If a certificate returned form a known (=visited) server changes, the client should display an alert. The user can then decide to again trust this new certificate and the client will subsequently silently accept this new certificate.
So it's not very secure in absolute terms. But you can get a secure transport, if the first certificate you (automatically) trusted was the proper one while having a very long expiration date.
@Morgan is set the parameter reuse_key = True in renewal.conf, that seems to keep the same cert data so that the hash does not change
@Supernova I believe this only requires the parameter reuse_key = True in the config. It is not possible to create long expiring certs with Letsencrypt, the expire time is automatically 3 months, you cannot change that
for those using LE, are you copying your keys to the user running your server? I ask because after using certbot, the directory holding the LE certs is not viewable by a regular user on my machine.
I copy the files with sudo and access them with the user the server is running under
@alexlehm Oh there is a runtime option, and I use docker certbot so I think I can use it this way:
docker compose run --rm certbot renew --reuse-key
I will see what happens next month upon renewal 😁
I see the purpose as different. The point of minting a key is to have a centralised chain of trust. I think the key life times are for the CA to validate or audit the keys. CRLs are not always effective, so everything must have a lifetime.
In Gemini, it's TOFU so the utility of a lifetime and of minting are both limited and across purposes.
2023-08-20 · 3 months ago
How many here use the same TLS certificate on their gemini server that they get for their web server? I found it not too hard to setup. I am surprised I don't see more gemini capsules doing the same.
💬 Supernova · 13 comments · 2023-08-19 · 3 months ago · #certificates