I have the same problem. I renewed my certificate and changed the web server to fullchain.pem generated by certbot on /etc/letsencrypt/live/.
Yup, appears to have been the same problem for me. Was using only the final certificate rather than the full chain.
Thanks everyone for the help!
today i have the same problem on linus servers. Resolve:
in the server with Web Server run:
choice certificate where you can renew and choice 1: Attempt to reinstall this existing certificate.
than restart httpd or nginx
3 posts were split to a new topic: Win2016 R3 problem
We also ran into problems last night, this might help someone out there:
•Kerio Connect 9.3.1 (Mailserver)
•Certbot to Auto Renew Certificates.
•A python Script to insert certificates into Kerio Connect after Certbot update.
Everything looked good and updating certificates without errors, but there were complaints about the expired certificate.
The problem is the INTERMEDIATE cert a stated in the subject of this thread.
It isn't updated by certbot, so we had to manually download it and put it in the right place on the server. We downloaded it and had to rename it from "lets-encrypt-r3.pem" to "lets-encrypt-r3.crt"
We put the certificate in: /opt/kerio/mailserver/sslca
After a reboot of Kerio Connect Mailserver everything works as expected and everybody was happy singing, dancing and reading all important spam-emails again.
Link to intermediade cert, change to .crt if necessary:
Hope this helps anyone.
That's a root certificate.
It is. You were probably using an incorrect configuration.
Yes, link changed, thanks!
I didn't care if the configuration was incorrect, I just wanted the f.....g thing to work.
Certbot just uses the chain provided by the ACME server. If there is any issue with the chain provided, it's probably user error, as currently there is no known issue with certbot and certificate chains.
For a few hours I have been having the same problem on some random navigators.
I have Nginx as an application server. Regenerate the certificate, I am using the fullchain certificate, I check the intermediate chain and it looks good (as in the examples above).
Certificate chain 0 s:CN = janis.rocketpin.com i:C = US, O = Let's Encrypt, CN = R3 1 s:C = US, O = Let's Encrypt, CN = R3 i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1 i:O = Digital Signature Trust Co., CN = DST Root CA X3 ---
The same browsers with problems entering my site, have problems entering https://community.letsencrypt.org/
I would appreciate any ideas, I really don't know what else to try.
thanks for your help.
I see only:
--- Certificate chain 0 s:/CN=janis.rocketpin.com i:/C=US/O=Let's Encrypt/CN=R3 1 s:/C=US/O=Let's Encrypt/CN=R3 i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1 ---
Did you change something after that post?
Then the problem may be within those browsers / Operating Systems.
So which browser?
Thanks! That seems to be solution in my case.
A post was split to a new topic: Errors from browser-based email client
Just to be clear about this, Certbot updates the files in
/etc/letsencrypt/live at every renewal (including a new CA-recommended trust chain). Many people use these files directly in their server applications.
If, however, you copy or migrate these files manually to another location, Certbot will no longer update that copy for you, unless you write a custom script using Certbot's
--deploy-hook feature. If Certbot isn't updating it, your copy of the chain may get out of sync with the up-to-date copy that Certbot provides in
My ACME client is WIN-ACME ver 18.104.22.1686.
We are deploying the website on Windows/IIS, how can I remove this certs?
Thank you very much for your help.
On Windows, just reboot your server and the old R3 will disappear from your chain.
Yes, I think that's the problem in our case. We are using a --deploy-hook script written in python and for some reason it doesn't update the intermediate cert. Well, it works now anyway with some hands-on magic. Have to look into it and see what's (not) going on.
Update: the script only copied privkey and cert, not fullchain. Problem solved.
The problem is that the last certificate in the fullchain generated by certbot shows
"version": 3, "serialNumber": "4001772137D4E942B8EE76AA3C640AB7", "notBefore": "Jan 20 19:14:03 2021 GMT", "notAfter": "Sep 30 18:14:03 2024 GMT", "caIssuers": [ "http://apps.identrust.com/roots/dstrootcax3.p7c" ], "crlDistributionPoints": [ "http://crl.identrust.com/DSTROOTCAX3CRL.crl" ]
While NotAfter is Sep 30 18:14:03 2024 GMT, the issuer http://apps.identrust.com/roots/dstrootcax3.p7c is still serving the expired cert