5 ms·

I've seen this improve a lot in recent years with Let's Encrypt, so that's been a great trend. LE is still tedious as heck to set up on your own, though, so I

by Swizec 6y ago

I've seen this improve a lot in recent years with Let's Encrypt, so that's been a great trend. LE is still tedious as heck to set up on your own, though, so I guess people who haven't migrated to modern hosting yet are still being left behind. Most hosting-for-devs platforms these days give you HTTPS by default and don't think would even let you host a website without.

user1980 6y ago
Tedious to set up, tedious to maintain. January 31 of this year I got an email telling me that my LE client used the older ACMEv1 protocol, not the newer ACMEv2 protocol. They gave me 4 months notice to update my LE client to something compliant. I burnt the time and did the work. On March 3 myself and many others[0] got an email demanding that we manually re-issue our certificates because of a vulnerability discovered in the LE service. They gave us one day to comply, after that they would revoke the certificates and our users would receive security errors. I begrudgingly went through all my servers and issued the command to forcibly renew certificates. Not a huge burden for me, but likely a bigger burden for larger operations. As the feature set grows (new challenge types, wildcard support, etc.) and the service gets even more popular, it's going to be an even bigger target and the effects of a monoculture will really be felt. I'm starting to see the value in paying for certificates, and more specifically, using providers that don't provide a public certificate issuance API (or at least stick it behind a paywall.) How many times would LE have to accidentally issue gstatic.com or fbcdn.net before they get the Symantec treatment[1]? Too big to fail: It's not just for investment banks. And that should give anyone seeking a decentralized internet pause. [0]: https://www.zdnet.com/article/lets-encrypt-to-revoke-3-million-certificates-on-march-4-due-to-bug/ https://www.zdnet.com/article/lets-encrypt-to-revoke-3-milli... [1]: https://www.zdnet.com/article/mozilla-warns-it-plans-to-distrust-all-symantec-chained-certs-in-october/ https://www.zdnet.com/article/mozilla-warns-it-plans-to-dist...
- na85 6y ago
  >Tedious to set up, tedious to maintain. It took me maybe 10 minutes to set up for my nginx setup. Debian and OpenSUSE both package letsencrypt's certbot. Tedious to set up and maintain is essentially the opposite of my experience.
- inetknght 6y ago
  > How many times would LE have to accidentally issue gstatic.com or fbcdn.net before they get the Symantec treatment[1]? Too big to fail: It's not just for investment banks. And that should give anyone seeking a decentralized internet pause. I agree that some problems are unfortunate. But let's contrast for a moment. LetsEncrypt has demonstrated track record of quickly fixing issues. Symantec has a demonstrated track record of hiding issues instead of fixing them. It's wise to consider options carefully. LetsEncrypt isn't the be-all end-all service for TLS and your needs might not be compatible. But I don't think it's fair to shove LetsEncrypt aside just because it's had its share of problems. For a free service it's pretty damn reputable.
  - treis 6y ago
    It's a good service, but I think the GP's point is that it's not trivial to do. Lots of websites probably went down because they missed that e-mail and we've seen lots of major websites go down due to some issue related to their certificate. Let's Encrypt has lowered the bar, but it's still a bar that needs to be overcome.
    - tialaramex 6y ago
      As we'd expect ISRG not only fixed the immediate problem they also accelerated plans to ensure that any similar problem would have less serious ill effects. In particular a current Certbot (or similar software from other developers) will conclude that it should try to replace a certificate which has been revoked and not only certificates that will shortly expire. So if a similar event happened, and you missed the email, your Certbot will treat the certificates much as if they'd expired and replace them automatically. Also if you didn't replace a revoked certificate the thing is: Online revocation is broken. Most of your users will not have noticed your certificate was revoked. Popular browsers do have an out-of-band way to enforce revocation but they didn't use it on that Let's Encrypt incident because they felt it was low risk. So maybe some people are running Internet Explorer (really?) or have explicitly turned on revocation, everybody else doesn't even see a warning page.
- tialaramex 6y ago
  > How many times would LE have to accidentally issue gstatic.com or fbcdn.net before they get the Symantec treatment Our concern with Symantec was inadequate oversight. This is not some clumsy "Three strikes and you're out" rule. Symantec did not have the culture needed to do the job properly and we had no confidence that their management was capable of instilling such a culture. If you're American or just follow American events somewhat you may have seen the "One rotten apple" argument being pulled apart in respect of problems with their police. Symantec used this argument, asserting on two occasions that their policies were fine but an employee had fallen short and this employee was terminated so now everything is fine. I am not sure I believe them but it doesn't matter because: That is not good enough. We need public CAs to design procedures so that merely incompetent or lazy employees cannot sabotage things. Because individual humans are by their nature incompetent and lazy, such problems are to be expected and must be allowed for in your processes. The big incident that blew up for Symantec was Crosscert. Symantec had not explicitly disclosed that the Crosscert relationship existed. In fact even if you read their paperwork closely (as we did after the incident) they actually simply did not disclose key facts about the relationship to anyone, not to their users, not to relying parties (ie you and me), and not to their independent auditor. Perhaps not even to their own board of directors (of course maybe private documents available to the board had such a disclosure). It is likely that in practice Symantec as a corporation was unaware of what Crosscert were doing. Even if one or two Symantec employees had a good idea, the organisation as a whole was ignorant. As a result there was in practice no oversight over this entirely separate entity in a foreign country issuing certificates! We concluded that building confidence in a new management of new infrastructure would take several years and that was the minimum we could allow. At first Symantec decided to fight this at the executive level, which of course only made us more confident that we'd been correct not to have confidence in them. When that failed (my impression is that trying to bully Google senior management isn't a good strategy) they settled upon a plan of selling their CA business instead. So all that's a long way from Let's Encrypt accidentally mis-issuing a certificate from their own systems to bad guys.
inetknght 6y ago
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.
greggman3 6y ago
It's trivial if you use caddy caddy file-server --domain example.com example.com is now running https via letsencrypt (assuming you own example.com)

by Swizec 6y ago

user1980 6y ago

Tedious to set up, tedious to maintain. January 31 of this year I got an email telling me that my LE client used the older ACMEv1 protocol, not the newer ACMEv2 protocol. They gave me 4 months notice to update my LE client to something compliant. I burnt the time and did the work. On March 3 myself and many others[0] got an email demanding that we manually re-issue our certificates because of a vulnerability discovered in the LE service. They gave us one day to comply, after that they would revoke the certificates and our users would receive security errors. I begrudgingly went through all my servers and issued the command to forcibly renew certificates. Not a huge burden for me, but likely a bigger burden for larger operations. As the feature set grows (new challenge types, wildcard support, etc.) and the service gets even more popular, it's going to be an even bigger target and the effects of a monoculture will really be felt. I'm starting to see the value in paying for certificates, and more specifically, using providers that don't provide a public certificate issuance API (or at least stick it behind a paywall.) How many times would LE have to accidentally issue gstatic.com or fbcdn.net before they get the Symantec treatment[1]? Too big to fail: It's not just for investment banks. And that should give anyone seeking a decentralized internet pause. [0]: https://www.zdnet.com/article/lets-encrypt-to-revoke-3-million-certificates-on-march-4-due-to-bug/ https://www.zdnet.com/article/lets-encrypt-to-revoke-3-milli... [1]: https://www.zdnet.com/article/mozilla-warns-it-plans-to-distrust-all-symantec-chained-certs-in-october/ https://www.zdnet.com/article/mozilla-warns-it-plans-to-dist...

na85 6y ago
>Tedious to set up, tedious to maintain. It took me maybe 10 minutes to set up for my nginx setup. Debian and OpenSUSE both package letsencrypt's certbot. Tedious to set up and maintain is essentially the opposite of my experience.
inetknght 6y ago
> How many times would LE have to accidentally issue gstatic.com or fbcdn.net before they get the Symantec treatment[1]? Too big to fail: It's not just for investment banks. And that should give anyone seeking a decentralized internet pause. I agree that some problems are unfortunate. But let's contrast for a moment. LetsEncrypt has demonstrated track record of quickly fixing issues. Symantec has a demonstrated track record of hiding issues instead of fixing them. It's wise to consider options carefully. LetsEncrypt isn't the be-all end-all service for TLS and your needs might not be compatible. But I don't think it's fair to shove LetsEncrypt aside just because it's had its share of problems. For a free service it's pretty damn reputable.
- treis 6y ago
  It's a good service, but I think the GP's point is that it's not trivial to do. Lots of websites probably went down because they missed that e-mail and we've seen lots of major websites go down due to some issue related to their certificate. Let's Encrypt has lowered the bar, but it's still a bar that needs to be overcome.
  - tialaramex 6y ago
    As we'd expect ISRG not only fixed the immediate problem they also accelerated plans to ensure that any similar problem would have less serious ill effects. In particular a current Certbot (or similar software from other developers) will conclude that it should try to replace a certificate which has been revoked and not only certificates that will shortly expire. So if a similar event happened, and you missed the email, your Certbot will treat the certificates much as if they'd expired and replace them automatically. Also if you didn't replace a revoked certificate the thing is: Online revocation is broken. Most of your users will not have noticed your certificate was revoked. Popular browsers do have an out-of-band way to enforce revocation but they didn't use it on that Let's Encrypt incident because they felt it was low risk. So maybe some people are running Internet Explorer (really?) or have explicitly turned on revocation, everybody else doesn't even see a warning page.
tialaramex 6y ago
> How many times would LE have to accidentally issue gstatic.com or fbcdn.net before they get the Symantec treatment Our concern with Symantec was inadequate oversight. This is not some clumsy "Three strikes and you're out" rule. Symantec did not have the culture needed to do the job properly and we had no confidence that their management was capable of instilling such a culture. If you're American or just follow American events somewhat you may have seen the "One rotten apple" argument being pulled apart in respect of problems with their police. Symantec used this argument, asserting on two occasions that their policies were fine but an employee had fallen short and this employee was terminated so now everything is fine. I am not sure I believe them but it doesn't matter because: That is not good enough. We need public CAs to design procedures so that merely incompetent or lazy employees cannot sabotage things. Because individual humans are by their nature incompetent and lazy, such problems are to be expected and must be allowed for in your processes. The big incident that blew up for Symantec was Crosscert. Symantec had not explicitly disclosed that the Crosscert relationship existed. In fact even if you read their paperwork closely (as we did after the incident) they actually simply did not disclose key facts about the relationship to anyone, not to their users, not to relying parties (ie you and me), and not to their independent auditor. Perhaps not even to their own board of directors (of course maybe private documents available to the board had such a disclosure). It is likely that in practice Symantec as a corporation was unaware of what Crosscert were doing. Even if one or two Symantec employees had a good idea, the organisation as a whole was ignorant. As a result there was in practice no oversight over this entirely separate entity in a foreign country issuing certificates! We concluded that building confidence in a new management of new infrastructure would take several years and that was the minimum we could allow. At first Symantec decided to fight this at the executive level, which of course only made us more confident that we'd been correct not to have confidence in them. When that failed (my impression is that trying to bully Google senior management isn't a good strategy) they settled upon a plan of selling their CA business instead. So all that's a long way from Let's Encrypt accidentally mis-issuing a certificate from their own systems to bad guys.

inetknght 6y ago

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.

greggman3 6y ago

It's trivial if you use caddy caddy file-server --domain example.com example.com is now running https via letsencrypt (assuming you own example.com)