Certbot still deliver the old expired CA certificate.... This result in Trust failure because Webserver (nginx and apache2) sends all certificates in (full)chain.pem
I have to manual delete the expired CA Cert.
My domain is:
I ran this command:
certbot -d DOMAIN --nginx certonly
It produced this output:
My web server is (include version):
nginx version: nginx/1.14.2
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of
certbot --version or
certbot-auto --version if you're using Certbot):
i cannot update certbot because debian dont offer any update.(but this should not change any behavior by certbot)
The expired trusted root is the current default path - as seen on this very site.
If you would rather use the shorter/alternate path, you can do so by manually editing the
chain.pem) file used and removing the last cert from within it.
This "edit" won't survive the renewal, and thus the need for a newer ACME client that supports the
certbot can't be upgraded, on your system, beyond version "0.31.0", you may have to opt for another choice.
another ACME client, like:
it would be better lets encrypt just remove this expired CA or change default path... so on first renew all expired CA's should be removed..
imagine you have no access to the server this would be killing lets encrypt... (mostly all browser ignore this, but older browsers and server does not ignore this)
it would be better
It might be better
But then the problem shifts to ones that don't have one now.
[there is no choice where everyone is better]
yes delivering an expired CA cert is the best solution, especially for beginners
Let's encrypt is so easy that every one can use is. Everything works automatic.
I see many "Expired" or not trusted Topic mhh looks like everything works
when nobody cares... i don't care
Let's Encrypt serves a chain up to the (now expired) DST Root CA X3, because that helps with
Android compatibility. The current plan is to serve this chain until about 2024, though those plans may change at any time.
Most clients should have no problem with either chain - ISRG Root X1 is included in the current chain, and any validation algorithm following RFC4158 (and having ISRG Root X1 in the trust store) will use that as its trust anchor.
There are some clients - especially older versions of non-OS/non-browser related TLS implementations (OpenSSL, GnuTLS and others) that do not implement RFC4158 correctly. Those clients can verify the alternate chain, but not the default*.
For these clients, there are sometimes client-side workarounds available (removing the expired root from their trust store, enabling optional features....). Serving the shorter alternate chain server-side is a valid workaround server-side, but will break Android < 7.1.1.
*Assuming that ISRG Root X1 is in their trust store. Clients where this does not apply usually have issues with either chain, unless they ignore the expiry of DST Root CA X3
and the server serves the long chain.
Conclusively, both chains have advantages- and disadvantages. There is no solution for everyone.
The decision to serve the long chain (ending in the expired DST Root CA X3) was made, because the team believes that this will help the most
users (those surfing to the site on their mobile devices). Other TLS implementations are generally more used by scripts, devops etc - not end users. Browsers in general will have no trouble with either chain, unless the (OS) trust store is out of date - in that case, neither chain works (except for systems that ignore the expiry of DST Root CA X3, e.g. Android).
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.