4 ms·

For everyone that complains about Let's Encrypt, I just want to state that Let's Encrypt solves the single largest use case for issuing certificates for domains

by eximius 10y ago

For everyone that complains about Let's Encrypt, I just want to state that Let's Encrypt solves the single largest use case for issuing certificates for domains - a single server you control which hosts one (or more) website(s). All of these issues with 3 month certs, rate limiting, and limited certs/domain stem from much more complicated problems and it isn't fair to expect Let's Encrypt to tackle those.

dsr_ 10y ago
And unless something really odd is happening, a small server owner will run into these problems when first setting up your LE certs for automated renewal and not any time thereafter.
- sdoering 10y ago
  That is something I do not see in my own (n=1) experience. The only problem I had was with a poorly written crontab entry, that was totally my fault. Setting up my 5 domains, hosted on one small (virtual) server instance was just a breeze. Esp. compared to my former experience with StartSSL. And now, with a cronjob doing auto renewal everything is solved. So for me at least Let's Encrypt just made life better.
  - sbarre 10y ago
    This was also my scenario.. 10 domains, one virtual server.. It took me about 45 minutes from "never done this" to "all sites done with a cron job for auto-renewals". The final thing I did once everything was set up was donate to the project.
- imron 10y ago
  Not even then. They should be using the staging servers for all testing and integration so they'll never hit the limits (a small server owner will not be needing more than 2,000 certificates per domain to be issued per week).
OriginalPenguin 10y ago
Wait, what? How does the 3 month cert limit stem from a much more complicated problem? The 3 month cert limit is an arbitrary limit by Let's Encrypt, and has nothing to do with a more complicated problem. They could just as easily make it 6 months or a year, but instead they chose 3 months.
- Someone1234 10y ago
  > How does the 3 month cert limit stem from a much more complicated problem? Broadly speaking Certificate Revocation is garbage. It doesn't work. So when a bad actor generates a bad certificate there's a legitimate chance that without Certificate Pinning, that Certificate will be accepted even if theoretically revoked. A three months max duration limits the potential liabilities to three months. Additionally three months offers the better theoretical security against state actors. While a 2048 bit key is normally considered to take tens of years to break, it is possible a state actor with unlimited resources could construct a quantum computer that could cut that time down significantly. If the certificate pair is regenerated every three months using a safe cryptographic source this makes breaking it likely not worth while even for a quantum computer.
  - okket 10y ago
    > While a 2048 bit key is normally considered to take tens of years to break [...] FYI: You can renew your cert without changing the key, e.g. for mail servers and DANE/TLSA. http://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/ http://www.internetsociety.org/deploy360/blog/2016/03/lets-e... http://www.internetsociety.org/deploy360/blog/2016/01/lets-encrypt-certificates-for-mail-servers-and-dane-part-1-of-2/ http://www.internetsociety.org/deploy360/blog/2016/01/lets-e... (part 1)
  - dingaling 10y ago
    > A three months max duration limits the potential liabilities to three months. But what attack is that blunting? 1. A bad actor with access to the system will just regenerate another LE cert and carry on. 2. A bad actor who has injected a bad cert, but without system access, still has three months to conduct his fraud which is more than enough time to phish 90% of the user-base. I'm not privy to the LE decision-making process but 90 days seems like the result of a bad compromise. Automated certs should be renewed on a very-high-frequency ( like hourly ) otherwise there's little benefit over the traditional model, and a lot of downsides such as breaking pinning. 90 days seems to have been chosen to be painful enough to push people into adopting auto-renewal but not frequent enough to overload LE's system, and thus not actually providing any security gains.

by eximius 10y ago

dsr_ 10y ago

And unless something really odd is happening, a small server owner will run into these problems when first setting up your LE certs for automated renewal and not any time thereafter.

sdoering 10y ago
That is something I do not see in my own (n=1) experience. The only problem I had was with a poorly written crontab entry, that was totally my fault. Setting up my 5 domains, hosted on one small (virtual) server instance was just a breeze. Esp. compared to my former experience with StartSSL. And now, with a cronjob doing auto renewal everything is solved. So for me at least Let's Encrypt just made life better.
- sbarre 10y ago
  This was also my scenario.. 10 domains, one virtual server.. It took me about 45 minutes from "never done this" to "all sites done with a cron job for auto-renewals". The final thing I did once everything was set up was donate to the project.
imron 10y ago
Not even then. They should be using the staging servers for all testing and integration so they'll never hit the limits (a small server owner will not be needing more than 2,000 certificates per domain to be issued per week).

OriginalPenguin 10y ago

Wait, what? How does the 3 month cert limit stem from a much more complicated problem? The 3 month cert limit is an arbitrary limit by Let's Encrypt, and has nothing to do with a more complicated problem. They could just as easily make it 6 months or a year, but instead they chose 3 months.

Someone1234 10y ago
> How does the 3 month cert limit stem from a much more complicated problem? Broadly speaking Certificate Revocation is garbage. It doesn't work. So when a bad actor generates a bad certificate there's a legitimate chance that without Certificate Pinning, that Certificate will be accepted even if theoretically revoked. A three months max duration limits the potential liabilities to three months. Additionally three months offers the better theoretical security against state actors. While a 2048 bit key is normally considered to take tens of years to break, it is possible a state actor with unlimited resources could construct a quantum computer that could cut that time down significantly. If the certificate pair is regenerated every three months using a safe cryptographic source this makes breaking it likely not worth while even for a quantum computer.
- okket 10y ago
  > While a 2048 bit key is normally considered to take tens of years to break [...] FYI: You can renew your cert without changing the key, e.g. for mail servers and DANE/TLSA. http://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/ http://www.internetsociety.org/deploy360/blog/2016/03/lets-e... http://www.internetsociety.org/deploy360/blog/2016/01/lets-encrypt-certificates-for-mail-servers-and-dane-part-1-of-2/ http://www.internetsociety.org/deploy360/blog/2016/01/lets-e... (part 1)
- dingaling 10y ago
  > A three months max duration limits the potential liabilities to three months. But what attack is that blunting? 1. A bad actor with access to the system will just regenerate another LE cert and carry on. 2. A bad actor who has injected a bad cert, but without system access, still has three months to conduct his fraud which is more than enough time to phish 90% of the user-base. I'm not privy to the LE decision-making process but 90 days seems like the result of a bad compromise. Automated certs should be renewed on a very-high-frequency ( like hourly ) otherwise there's little benefit over the traditional model, and a lot of downsides such as breaking pinning. 90 days seems to have been chosen to be painful enough to push people into adopting auto-renewal but not frequent enough to overload LE's system, and thus not actually providing any security gains.