3 ms·

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

by 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.

by Maakuth 11y ago

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.