acme/letsencrypt support #31
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I recently built a toy gemini server with autocert support built in. We've also had recurring troubles maintaining our TLS certificates on ctrl-c.club, so...
Would you consider a PR adding autocert support to molly-brown?
The hairiest part would be that the server would have to bind to either port 80 or 443 to handle acme challenges, but I could support both challenge types so the user could choose which, and in the case of port 80 autocert comes with a convenient handler that redirects everything to the corresponding
https://url. I'd add documentation about all this, and of course wouldn't bind to any ports if the user doesn't enable autocert support in configuration.Gemini uses TOFU for certs, meaning that changing them frequently is a bad idea, similar to how you wouldn't want to change your server's SSH key all the time. Let's Encrypt certs are bad for Gemini usage because they change every 90 days or often even sooner. A better option would be to generate a self-signed cert that you'll never change, or that expires in a long period of time like 5 years.
That makes sense as it causes the cert-expiration vulnerability to come around more often, but could it still make sense as an opt-in feature for the sysadmin that doesn't want to manage a CA, keys, certs, etc? OTOH I understand if you just want to discourage the CA system - don't feel that you're being rude to just close this issue.
I don't adminstrate this repo, so I can't close the issue or anything, was just offering my comments. In my opinion, it's always a bad idea to do Let's Encrypt, but we can see what Solderpunk says if he replies.
I completely understand why people do use Let's Encrypt. I never had the courage to actually mandate, rather than recommend, TOFU in the spec. Even if I had, I don't know that people would have necessarily followed it anyway. I certainly underestimated the extent to which TLS libraries would make it surprisingly difficult to use TLS in non-CA contexts. I still plan to this year finally follow up on one of my windmill tilting dreams and write a TLS observatory for Gemini...
Anyway, while I don't really begrudge anybody choosing to use LE for Gemini, I'm not sure I want to encourage it as strongly as adding really smooth turn-key LE compatibility to Molly Brown would. It also seems like a non-trivial bit of work that I wouldn't personally make use of at any of my MB-powered hosts. So, I think I will politely decline this suggestion and close the issue. Hope you understand!