5 ms·

the certbot tools were made with the "default" experience in mind and no one tries them with more custom setups. the fact that they don't have easy guides on ho

by gjs278 6y ago

the certbot tools were made with the "default" experience in mind and no one tries them with more custom setups. the fact that they don't have easy guides on how to do it without certbot is worrying. you should be able to get a straightforward automated experience without having to use their convoluted tool that will choke and leave you hanging. google certbot systemd or certbot openrc to see it fail. tack on that they had to invalidate all of their certs one day and gave little warning and you could easily have experienced revoked SSL certs if your system wasn't the default setup.

inetknght 6y ago
> no one tries them with more custom setups I'm sorry, what? Are you projecting? By what measure is "custom" and by what measure is "no one"? My old setup was very custom and worked quite fine with certbot. My current setup is less custom and still works quite fine with certbot. I literally haven't had any trouble whatsoever with certbot. > the fact that they don't have easy guides on how to do it without certbot is worrying Without Certbot we'd be using openssl's arcane command line. And you're absolutely right, openssl is a !@#$ing dumpster fire. I'd argue that openssl's garbage tools are exactly why certbot was created. > google certbot systemd or certbot openrc to see it fail. I did google certbot systemd and certbot openrc. I don't see failures. Please cite some. > they had to invalidate all of their certs one day and gave little warning and you could easily have experienced revoked SSL certs if your system wasn't the default setup "They" are LetsEncrypt. And "They" aren't Certbot. In retrospect I thought I'd vouch for your message since I thought it would be a decently constructed argument. Instead I now recognize you didn't write a reasoned argument. That was my fault for vouching before reading. If you don't like Certbot or LetsEncrypt then nobody's forcing you to use them. Go pay for a SSL certificate since you don't understand how to use free tools. Or just use unencrypted connections and let your users get hacked.
- gjs278 6y ago
  users won’t get “hacked” using an unencrypted connection on a website that submits nothing. what will they hack? certbot and lets encrypt are highly connected, and if you can’t find the failures you are willfully blind. I do actually know how to use the free tools. you need your hand held by a python script that automagically takes care of things for you. it will also eventually deprecate and could have problems running on the platforms or python versions I choose one day. i’ve generated it with openssl. the how to use guides for certbot are almost comical, even their crons are nonsense. i’m not going to trust my setup to their magic scripts that could actually go wrong at any time. the process should be a lot more decoupled than “and now run this python script” and generating with openssl shouldn’t be such a second class citizen, especially for wildcard.
boring_twenties 6y ago
What software in common use ever checks certificate revocation lists? Browsers certainly don't.

by gjs278 6y ago

inetknght 6y ago

> no one tries them with more custom setups I'm sorry, what? Are you projecting? By what measure is "custom" and by what measure is "no one"? My old setup was very custom and worked quite fine with certbot. My current setup is less custom and still works quite fine with certbot. I literally haven't had any trouble whatsoever with certbot. > the fact that they don't have easy guides on how to do it without certbot is worrying Without Certbot we'd be using openssl's arcane command line. And you're absolutely right, openssl is a !@#$ing dumpster fire. I'd argue that openssl's garbage tools are exactly why certbot was created. > google certbot systemd or certbot openrc to see it fail. I did google certbot systemd and certbot openrc. I don't see failures. Please cite some. > they had to invalidate all of their certs one day and gave little warning and you could easily have experienced revoked SSL certs if your system wasn't the default setup "They" are LetsEncrypt. And "They" aren't Certbot. In retrospect I thought I'd vouch for your message since I thought it would be a decently constructed argument. Instead I now recognize you didn't write a reasoned argument. That was my fault for vouching before reading. If you don't like Certbot or LetsEncrypt then nobody's forcing you to use them. Go pay for a SSL certificate since you don't understand how to use free tools. Or just use unencrypted connections and let your users get hacked.

gjs278 6y ago
users won’t get “hacked” using an unencrypted connection on a website that submits nothing. what will they hack? certbot and lets encrypt are highly connected, and if you can’t find the failures you are willfully blind. I do actually know how to use the free tools. you need your hand held by a python script that automagically takes care of things for you. it will also eventually deprecate and could have problems running on the platforms or python versions I choose one day. i’ve generated it with openssl. the how to use guides for certbot are almost comical, even their crons are nonsense. i’m not going to trust my setup to their magic scripts that could actually go wrong at any time. the process should be a lot more decoupled than “and now run this python script” and generating with openssl shouldn’t be such a second class citizen, especially for wildcard.

boring_twenties 6y ago

What software in common use ever checks certificate revocation lists? Browsers certainly don't.