4 ms·

I disagree; I don't think LetsEncrypt is tedious to get set up on your own. Here's what I recently did when I deployed a new site [0]: {dnf,yum,apt-get,wha

I disagree; I don't think LetsEncrypt is tedious to get set up on your own. Here's what I recently did when I deployed a new site [0]: {dnf,yum,apt-get,whatever} install -y certbot certbot certonly --webroot -w /srv/_default -d systemd.software -d www.systemd.software Certbot went through the registration process in the terminal window. Enter in an email address and read over the terms of service and then it goes and does its thing and finally spits out a success message telling me where the certificate and private key are on the filesystem. Then just point an nginx configuration file to the two [1] and tell nginx to test and reload its configuration. cp nginx.conf /etc/nginx/default.d/systemd.software.nginx.conf nginx -t && nginx -s reload Then, LetsEncrypt will send an email to me notifying me that one or more certificates are about to expire (20 days, 10 days, 1 day ...). I even decided to test that and make sure that works (on a different site a couple years ago) [2]. The certificate can be updated using the certbot-renew service: systemctl start certbot-renew.service Google searches show several examples which put the renewal service on a timer. That's it! I'm not sure what you think is tedious about that process. Would you care to elaborate? [0] https://systemd.software/index.html https://systemd.software/index.html [1] https://github.com/inetknght/systemd.software/blob/44c584c684a7c51b5191335aa85a0e1178383e33/nginx.conf#L49-L50 https://github.com/inetknght/systemd.software/blob/44c584c68... [2] https://knightoftheinter.net/img/LetsEncrypt_Expiration_Warnings.png https://knightoftheinter.net/img/LetsEncrypt_Expiration_Warn...

gjs278 6y ago
the amount of switches, and the systemd being involved. I don’t use systemd
- inetknght 6y ago
  The switches would need to be there for a GUI anyway. There would be a drop-down menu to select the authentication type (--webroot), a folder selection field to specify the web root directory (-w /srv/_default), and a list of domain names to certify (-d systemd.software -d www.systemd.software). How else would you configure the options? systemd.software is just a website and isn't related to running certbot. Indeed, if you'd visit the site you'd see I have a lot of gripes about systemd too! Systemd here is only used as an example for the renewal service. It actually just calls `certbot renew`: $ cat /usr/lib/systemd/system/certbot-renew.service [Unit] Description=This service automatically renews any certbot certificates found [Service] EnvironmentFile=/etc/sysconfig/certbot Type=oneshot ExecStart=/usr/bin/certbot renew --noninteractive --no-random-sleep-on-renew $PRE_HOOK $POST_HOOK $RENEW_HOOK $DEPLOY_HOOK $CERTBOT_ARGS The important bit here is the ExecStart: it's just `certbot renew --noninteractive --no-random-sleep-on-renew` which is indeed a lot of stuff to remember.
- boring_twenties 6y ago
  I was confused for a second as well, but I think "systemd.software" is actually the domain of the website. If the systemctl is what you're objecting to, on the other hand, then you need to get a grip.
  - 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

the amount of switches, and the systemd being involved. I don’t use systemd

inetknght 6y ago
The switches would need to be there for a GUI anyway. There would be a drop-down menu to select the authentication type (--webroot), a folder selection field to specify the web root directory (-w /srv/_default), and a list of domain names to certify (-d systemd.software -d www.systemd.software). How else would you configure the options? systemd.software is just a website and isn't related to running certbot. Indeed, if you'd visit the site you'd see I have a lot of gripes about systemd too! Systemd here is only used as an example for the renewal service. It actually just calls `certbot renew`: $ cat /usr/lib/systemd/system/certbot-renew.service [Unit] Description=This service automatically renews any certbot certificates found [Service] EnvironmentFile=/etc/sysconfig/certbot Type=oneshot ExecStart=/usr/bin/certbot renew --noninteractive --no-random-sleep-on-renew $PRE_HOOK $POST_HOOK $RENEW_HOOK $DEPLOY_HOOK $CERTBOT_ARGS The important bit here is the ExecStart: it's just `certbot renew --noninteractive --no-random-sleep-on-renew` which is indeed a lot of stuff to remember.
boring_twenties 6y ago
I was confused for a second as well, but I think "systemd.software" is actually the domain of the website. If the systemctl is what you're objecting to, on the other hand, then you need to get a grip.
- 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.