Let's Encrypt uses incorrect/incomplete intermediate

When requesting/installing a "let's encrypt" certificate through the virtualmin interface, "let's encrypt" signed it with their "X3" authority. Virtualmin didn't include the "X3" authority in the intermediate certificates of the site, which caused various trust issues of my site.

I believe they started using the X3/X4 certificates around 2 weeks ago. https://community.letsencrypt.org/t/upcoming-intermediate-changes/13106

Status: 
Active

Comments

Utilities such as wget and curl require proper CA chains. Additionally, SSL Labs issue a grade of "F". So as it stands now, those utilities cannot connect to virtualmin websites using Lets Encrypt and security of the sites themselves are greatly impacted (as detailed by SSL Labs). I don't think it would be absurd to label this a higher priority security issue.

The CA certificates can be obtained from https://letsencrypt.org/certificates/ The issuer of a cert can be obtained by: openssl x509 -in ssl.cert -noout -issuer

If you didn't want to inspect the cert generated by lets encrypt, then I suppose you could just include all of their signing certs in the CA bundle, but that seems wasteful.

Is a fix in the works for the next release?

Will the "automatic renewal" feature overwrite the intermediate that I manually installed? If so, then that makes this a larger issue.

My other concern would be that most people wouldn't know to do this, so it leaves their sites not really secure. I'd also imagine that some important bots (like google bot), may have an issue connecting as well.

There are several tickets open about this issue. I'm confused as to why there really hasn't been an official response about an actual fix. All the responses have been about a work around.

Will the "automatic renewal" feature overwrite the intermediate that I manually installed?

Is a fix coming in the next release?

Are you still seeing this issue in the most recent Webmin version that's been pushed out?

That should have been corrected at the time Jamie responded to you above. He wasn't implying you'd always have to use a workaround... the workaround was just a way to getting a working cert, until the new Webmin version was available in the repository.

This is fixed in the current release

LeonB - which webmin version are you running there?

I am having this same issue as well, though I have OCSP stapling enabled on my Apache 2.4.23 set up on CentOS 7 x64 but stapling fails because Apache "can't retrieve issuer certificate". Also Safari fails to connect to the site, and so does wget and curl. I am running Webmin 1.810/Virtualmin 5.04 Pro. I just generated a new certificate for my domain, never done it before on this version of Webmin/Virtualmin, yet still having this problem.

JEMEDIACORP - what is the domain you're having problems with? I'd like to try connecting to it myself to see what cert is being provided.

vidma's picture
Submitted by vidma on Tue, 01/05/2021 - 06:39

Have same issue after renewed the "let's encrypt" certificate. Any ideas how to solve it?

Ilia's picture
Submitted by Ilia on Tue, 01/05/2021 - 16:02

Next Webmin 1.970 release will have it fixed for users with acme_tiny script.

The work-around would be is to apply the patch in the link above or install certbot package.

After applying the patch or installing certbot package you would have to re-request Let's Encrypt certificates.

vidma's picture
Submitted by vidma on Wed, 01/06/2021 - 01:31

Thanks, problem solved after installing the certbot.