9 ms·

I'm really pleased to see this initiative and I've used the private beta with letsencrypt-nosudo[0] to issue a certificate, but after successfully getting a cer

I'm really pleased to see this initiative and I've used the private beta with letsencrypt-nosudo[0] to issue a certificate, but after successfully getting a certificate my site failed the SSL Labs test[1] with an 'unknown CA' error, even though I used the newer one that should have been trusted. It was probably down to user error and the additional complexity of denying sudo privileges for the set up script, but it took much more work than I expected. Then I noticed the certs will only ever be good for 90 days, and I'll have to do this multiple times a year! Bottom line for me is that with DV certs so inexpensive and simple to get, I'd rather pay a few dollars a year for normal commercial certificates. I can do things like use CloudFront at a custom subdomain with HTTPS without needing to point DNS somewhere every few months to get a cert reissued. I simply can't justify the extra work involved to get 'free' certificates, and I'm happy to continue buying regular DV certs. Maybe these are temporary limitations and if so I will definitely try again in the future. [0]https://github.com/diafygi/letsencrypt-nosudo https://github.com/diafygi/letsencrypt-nosudo [1]https://www.ssllabs.com/ssltest/index.html https://www.ssllabs.com/ssltest/index.html

kevinreedy 11y ago
I actually love the idea of 90 day (or less) certificates! Once you automate the process of replacing your certificate (which let's encrypt will greatly help with), it won't matter how short the period is. Also, if a key gets compromised, it'll be valid for a shorter time. Give https://letsencrypt.org/2015/11/09/why-90-days.html https://letsencrypt.org/2015/11/09/why-90-days.html a read! If you want to get more in-depth about certificate revocation, http://news.netcraft.com/archives/2013/05/13/how-certificate-revocation-doesnt-work-in-practice.html http://news.netcraft.com/archives/2013/05/13/how-certificate... is also a great/depressing read.
- deleted 11y ago
  [deleted]
- ars 11y ago
  If someone compromised the key they also compromised the system used to automatically generate more keys, so a short expiration is not as helpful as it looks. It's even worse than that: A smart attacker will copy the method used to generate keys, and leave the server. Then they can keep generating keys and you will probably never notice. I feel that automation is a mistake, something security sensitive like this should be on a completely different machine.
  - kevinreedy 11y ago
    I'm not in the beta, and thus haven't been able to play with it yet. But, I don't believe there'd be anything prohibiting you from generating the certs on a separate machine. In fact, I'd imagine that's what you'd want to do (if you have more than one server) rather than generating a separate certificate for every web server or load balancer.
    - pfg 11y ago
      That's correct. I've recently deployed LE on a side project. The official letsencrypt client supports a mode called webroot, where you basically tell the client where your webroot is located on your file system, and it will place a file in .well-known/acme-challenge/<random> to confirm ownership. I use nginx in front of multiple domains with different backends (which do not all have the platform equivalent of a webroot), so I simply added a location directive for .well-known to all vhosts pointing to the same directory which I then pass to letsencrypt. It would be trivial to move this to a separate machine by using a reverse proxy for .well-known instead of serving it directly from your load balancer's filesystem. The rest is just scp'ing your certificates and keys to your load balancers (or using your configuration management software of choice to achieve the same). With ACME being an open protocol it's quite likely that someone will end up writing a client specifically for this use-case, making it even easier.
  - AgentME 11y ago
    Generating the cert involves proving that you own the domain. An attacker can't copy that away (unless they've stolen the domain entirely from you, in which case the SSL keys are not your primary issue).
- bmelton 11y ago
  Does Google still penalize short-term / soon-expiring SSL certs in search rankings? Edit: this does not appear to be a thing that happens.
  - tedchs 11y ago
    Why do you think that's a thing that's happening?
    - bmelton 11y ago
      Hrm. Good point. At some point I remember some SEO guru or other claiming that long-duration domain name registrations were good for SEO, but looking at it now, it seems as though that was a correlation !== causation, as MS, Goog, et al register their domain names for decades at a time, and also tend to have high search rankings. As for the rest, chalk it up to my over-active imagination, compounded with that bad knowledge. SSL is an SEO boost (according to a random Googling), and if domain name expiration was a factor, it made sense to me that SSL expiry would factor too. TLDR, I was a dumb.
  - mappu 11y ago
    I would assume not, given that https://letsencrypt.org/2015/11/09/why-90-days.html https://letsencrypt.org/2015/11/09/why-90-days.html cites "According to Firefox Telemetry, 29% of TLS transactions use ninety-day certificates. That’s more than any other lifetime."
gluejar 11y ago
I think you really have to understand that at its heart, Let's Encrypt is not about free certs as much as it is about automatic certs. If you just want a cert, definitely use an established provider. But a year from know, LE will be making this a "set and forget" thing, which is how it should be. LE is NOT a painless way to get certs for legacy infrastructure. I found this out by using it for an elastic beanstalk hosted site. I just wrote about it at https://go-to-hellman.blogspot.com/2015/11/using-lets-encrypt-to-secure-elastic.html https://go-to-hellman.blogspot.com/2015/11/using-lets-encryp...
- toomuchtodo 11y ago
  On the plus side, Amazon could choose to automate IAM SSL storage and renewal through Let's Encrypt so it would be fully automatic. Might take a bit until they do that though... Paging /u/jeffbarr?
- joshmoz 11y ago
  Head of Let's Encrypt here. You nailed it. It's important that our certs be free because we can't automate a billing interaction. If we had to charge then sysadmins couldn't just type a command and be on their way. Automated renewal could fail because billing info was out of date. This stuff has to just work, reliably, if we're going to expect the entire Web to use TLS.
Maakuth 11y ago
There's definitely some rough edges on the tooling that will make this less painful. You likely used it with development endpoints, which only give certificates signed by untrusted CA (happy hacker fake CA or something like that). However, the point[1] of short lifetime of the certificates is to incentivize automating it. I'm highly hopeful that in a short while, having an HTTPS certificate is a matter of apt-get install. [1]: https://letsencrypt.org/2015/11/09/why-90-days.html https://letsencrypt.org/2015/11/09/why-90-days.html
- tombrossman 11y ago
  Here's the issuer from the certificate I got, and I believe it was the (beta) production one and not the development endpoint. Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X1 Possibly user error still, but I use HTTPS across all my personal sites and they all rate well on third-party tests so I'm not a total noob (I hope...).
  - diafygi 11y ago
    Ah! Ok, I think you need to add the intermediate certificate[1] that chains the Let's Encrypt Authority X1 to the IdenTrust root. Here's instructions on how to do this for nginx: https://github.com/diafygi/letsencrypt-nosudo#how-to-use-the-signed-https-certificate https://github.com/diafygi/letsencrypt-nosudo#how-to-use-the... [1]: https://letsencrypt.org/certs/lets-encrypt-x1-cross-signed.pem.txt https://letsencrypt.org/certs/lets-encrypt-x1-cross-signed.p...
    - schoen 11y ago
      Note that you also have to do this step for other CAs, it's just that browsers often cache intermediates that they've seen before so sites may mysteriously work for most or almost all users but fail for others if the intermediates are missing. This configuration problem is extremely common and often confusing for people to diagnose. It might be more obvious with Let's Encrypt's intermediate because not as many browsers have that cached yet, but the configuration issue is technically the same regardless of what CA you're using. Sending chain files is mandatory if you want to be compatible with all user-agents that accept the root that you're chained to.
diafygi 11y ago
Howdy, I wrote letsencrypt-nosudo. Sorry that the experience was so painful! Mind filing a detailed issue on the repo so I can fix it and make the user experience better?
- tombrossman 11y ago
  Oh I think it's simple enough and thanks for the tool, but I'm comparing it to the workflow I currently use which has fewer steps (generate CSR, paste in form on issuer's website, click link to validate domain). Headed out now but I'll try to provide some better feedback later.
  - diafygi 11y ago
    Yeah, unfortunately, the ACME protocol requires registering accounts and making requests using public key signatures, so it's not as user friendly as email confirmations (despite being way more secure and automatable).
matt4077 11y ago
I am actually incredibly happy with the process. nginx requires these concatenated certificates and I always get the order / file formats / trailing spaces wrong. With LE I got it up & running in < 3 minutes, including manually updating the config file.
mobiplayer 11y ago
You need to present your full certificate chain and not only your public cert. I'm running a certificate generated with Let's Encrypt on one of my sites and I've got an A+ result: https://www.ssllabs.com/ssltest/analyze.html?d=datasnitch.co.uk&s=2a01%3a7e00%3a0%3a0%3af03c%3a91ff%3afe6e%3accf9&latest https://www.ssllabs.com/ssltest/analyze.html?d=datasnitch.co...

kevinreedy 11y ago

I actually love the idea of 90 day (or less) certificates! Once you automate the process of replacing your certificate (which let's encrypt will greatly help with), it won't matter how short the period is. Also, if a key gets compromised, it'll be valid for a shorter time. Give https://letsencrypt.org/2015/11/09/why-90-days.html https://letsencrypt.org/2015/11/09/why-90-days.html a read! If you want to get more in-depth about certificate revocation, http://news.netcraft.com/archives/2013/05/13/how-certificate-revocation-doesnt-work-in-practice.html http://news.netcraft.com/archives/2013/05/13/how-certificate... is also a great/depressing read.

deleted 11y ago
[deleted]
ars 11y ago
If someone compromised the key they also compromised the system used to automatically generate more keys, so a short expiration is not as helpful as it looks. It's even worse than that: A smart attacker will copy the method used to generate keys, and leave the server. Then they can keep generating keys and you will probably never notice. I feel that automation is a mistake, something security sensitive like this should be on a completely different machine.
- kevinreedy 11y ago
  I'm not in the beta, and thus haven't been able to play with it yet. But, I don't believe there'd be anything prohibiting you from generating the certs on a separate machine. In fact, I'd imagine that's what you'd want to do (if you have more than one server) rather than generating a separate certificate for every web server or load balancer.
  - pfg 11y ago
    That's correct. I've recently deployed LE on a side project. The official letsencrypt client supports a mode called webroot, where you basically tell the client where your webroot is located on your file system, and it will place a file in .well-known/acme-challenge/<random> to confirm ownership. I use nginx in front of multiple domains with different backends (which do not all have the platform equivalent of a webroot), so I simply added a location directive for .well-known to all vhosts pointing to the same directory which I then pass to letsencrypt. It would be trivial to move this to a separate machine by using a reverse proxy for .well-known instead of serving it directly from your load balancer's filesystem. The rest is just scp'ing your certificates and keys to your load balancers (or using your configuration management software of choice to achieve the same). With ACME being an open protocol it's quite likely that someone will end up writing a client specifically for this use-case, making it even easier.
- AgentME 11y ago
  Generating the cert involves proving that you own the domain. An attacker can't copy that away (unless they've stolen the domain entirely from you, in which case the SSL keys are not your primary issue).
bmelton 11y ago
Does Google still penalize short-term / soon-expiring SSL certs in search rankings? Edit: this does not appear to be a thing that happens.
- tedchs 11y ago
  Why do you think that's a thing that's happening?
  - bmelton 11y ago
    Hrm. Good point. At some point I remember some SEO guru or other claiming that long-duration domain name registrations were good for SEO, but looking at it now, it seems as though that was a correlation !== causation, as MS, Goog, et al register their domain names for decades at a time, and also tend to have high search rankings. As for the rest, chalk it up to my over-active imagination, compounded with that bad knowledge. SSL is an SEO boost (according to a random Googling), and if domain name expiration was a factor, it made sense to me that SSL expiry would factor too. TLDR, I was a dumb.
- mappu 11y ago
  I would assume not, given that https://letsencrypt.org/2015/11/09/why-90-days.html https://letsencrypt.org/2015/11/09/why-90-days.html cites "According to Firefox Telemetry, 29% of TLS transactions use ninety-day certificates. That’s more than any other lifetime."

gluejar 11y ago

I think you really have to understand that at its heart, Let's Encrypt is not about free certs as much as it is about automatic certs. If you just want a cert, definitely use an established provider. But a year from know, LE will be making this a "set and forget" thing, which is how it should be. LE is NOT a painless way to get certs for legacy infrastructure. I found this out by using it for an elastic beanstalk hosted site. I just wrote about it at https://go-to-hellman.blogspot.com/2015/11/using-lets-encrypt-to-secure-elastic.html https://go-to-hellman.blogspot.com/2015/11/using-lets-encryp...

toomuchtodo 11y ago
On the plus side, Amazon could choose to automate IAM SSL storage and renewal through Let's Encrypt so it would be fully automatic. Might take a bit until they do that though... Paging /u/jeffbarr?
joshmoz 11y ago
Head of Let's Encrypt here. You nailed it. It's important that our certs be free because we can't automate a billing interaction. If we had to charge then sysadmins couldn't just type a command and be on their way. Automated renewal could fail because billing info was out of date. This stuff has to just work, reliably, if we're going to expect the entire Web to use TLS.

Maakuth 11y ago

There's definitely some rough edges on the tooling that will make this less painful. You likely used it with development endpoints, which only give certificates signed by untrusted CA (happy hacker fake CA or something like that). However, the point[1] of short lifetime of the certificates is to incentivize automating it. I'm highly hopeful that in a short while, having an HTTPS certificate is a matter of apt-get install. [1]: https://letsencrypt.org/2015/11/09/why-90-days.html https://letsencrypt.org/2015/11/09/why-90-days.html

tombrossman 11y ago
Here's the issuer from the certificate I got, and I believe it was the (beta) production one and not the development endpoint. Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X1 Possibly user error still, but I use HTTPS across all my personal sites and they all rate well on third-party tests so I'm not a total noob (I hope...).
- diafygi 11y ago
  Ah! Ok, I think you need to add the intermediate certificate[1] that chains the Let's Encrypt Authority X1 to the IdenTrust root. Here's instructions on how to do this for nginx: https://github.com/diafygi/letsencrypt-nosudo#how-to-use-the-signed-https-certificate https://github.com/diafygi/letsencrypt-nosudo#how-to-use-the... [1]: https://letsencrypt.org/certs/lets-encrypt-x1-cross-signed.pem.txt https://letsencrypt.org/certs/lets-encrypt-x1-cross-signed.p...
  - schoen 11y ago
    Note that you also have to do this step for other CAs, it's just that browsers often cache intermediates that they've seen before so sites may mysteriously work for most or almost all users but fail for others if the intermediates are missing. This configuration problem is extremely common and often confusing for people to diagnose. It might be more obvious with Let's Encrypt's intermediate because not as many browsers have that cached yet, but the configuration issue is technically the same regardless of what CA you're using. Sending chain files is mandatory if you want to be compatible with all user-agents that accept the root that you're chained to.

diafygi 11y ago

Howdy, I wrote letsencrypt-nosudo. Sorry that the experience was so painful! Mind filing a detailed issue on the repo so I can fix it and make the user experience better?

tombrossman 11y ago
Oh I think it's simple enough and thanks for the tool, but I'm comparing it to the workflow I currently use which has fewer steps (generate CSR, paste in form on issuer's website, click link to validate domain). Headed out now but I'll try to provide some better feedback later.
- diafygi 11y ago
  Yeah, unfortunately, the ACME protocol requires registering accounts and making requests using public key signatures, so it's not as user friendly as email confirmations (despite being way more secure and automatable).

matt4077 11y ago

I am actually incredibly happy with the process. nginx requires these concatenated certificates and I always get the order / file formats / trailing spaces wrong. With LE I got it up & running in < 3 minutes, including manually updating the config file.

mobiplayer 11y ago

You need to present your full certificate chain and not only your public cert. I'm running a certificate generated with Let's Encrypt on one of my sites and I've got an A+ result: https://www.ssllabs.com/ssltest/analyze.html?d=datasnitch.co.uk&s=2a01%3a7e00%3a0%3a0%3af03c%3a91ff%3afe6e%3accf9&latest https://www.ssllabs.com/ssltest/analyze.html?d=datasnitch.co...