LetsEncrypt test sites show invalid certificate on Server OS

[zarek-marshall]

I require general assistance with a problem I’ve been having NOT with generating certificates, but with the way LetsEncrypt chain validation is occurring, and I can demonstrate this problem using Windows Server 2012 R2 Standard.

If I access the LetsEncrypt test site (https://valid-isrgrootx1.letsencrypt.org/) from a non server OS (Windows 10) using Chrome, the certificate is reported as valid.

However, if I access the same test site from any Server OS (have tried a few) but for argument’s sake Windows Server 2012 R2 Standard using Chrome, I get the following certificate issue

“The certificate cannot be verified up to a trusted certification authority”

I notice that there are two Certificate Paths for that test site (using ssllabs):
#1 is Not Trusted (using the LetsEncrypt non cross signed intermediate).
#2 is Trusted (using the IdenTrust cross signed intermediate).

So, I’m wondering if Windows Server OS’s handle certificate validation differently from Windows Desktop OS’s. Also, is there anything that can be done either by LetsEncrypt, or failing that, us (other than installing the LetsEncypt root on all server OS machines), to prevent this issue?

Thanks,

[rg305]

I can confirm and replicate your claim:

And also see this in Win10 using EDGE:

And also in Windows Server 2016 (IE):

[rg305]

It seems that Microsoft has removed that root cert or had never added in.

The only time it validates is when using the “DST Root CA X3”.

[zarek-marshall]

It’s my understanding that the IdenTrust certificate has been widely distributed for a number of years, but that the LetsEncrypt root is not yet widely distributed (I think the only place I know that it gets distributed is Firefox version 50 and above).

[_az]

@zarek-marshall

https://valid-isrgrootx1.letsencrypt.org/

Isn't including the cross-signing path at all:

$ openssl s_client -connect valid-isrgrootx1.letsencrypt.org:443 -servername valid-isrgrootx1.letsencrypt.org  -showcerts | openssl x509 -noout
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = valid-isrgrootx1.letsencrypt.org
verify return:1

If you try helloworld.letsencrypt.org, you shouldn't have any trust problems, even on Server 2012:

$ openssl s_client -connect helloworld.letsencrypt.org:443 -servername helloworld.letsencrypt.org  -showcerts | openssl x509 -noout
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = helloworld.letsencrypt.org
verify return:1

I think most/all users are using the cross-signed path.