4 ms·
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, C
by 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 agoAh! 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 agoNote 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.