Problem with chain in SSL

Hi,

I have a website on a production server that i try to use ley’s Encrypt SSL
on my computer when i surf to that website i get it to work
from cellphones it works. from any other computer in the office we get that there are issues with chain in the certificate
from my computer at home i get the website without error

i used Cerfity to create the SSL

i have found this IIS 8.5 building incorrect chain with Lets Encrypt Authority X3
and tried all. i didn’t had the X1 certificate at all. so i have just removed the bindings and re-created them

nothing help

what can be done? before i give up and pay for SSL

I guess you need to import the current intermediate certificate. (It’s strange that certify did not do this for you.)

https://support.microsoft.com/en-us/help/954755/how-to-configure-intermediate-certificates-on-a-computer-that-is-runni

You can download it at https://cert.int-x3.letsencrypt.org/

Are you talking about Let’s Encypt Authority X3 by DST Root CA X3 expiration in 17/03/2021?

if so, it is what i have.

as i have said. the website works for me on my cellphone and my work pc and home pc. but no in my work colleges pcs. i have asked a friend to try and it works for him as well with out a certificate warning that i described before

it seems like it is only happend in windows 7 (every browser)

If you enter your website at https://www.ssllabs.com/ssltest/ does it say “Chain Issues: Incomplete” (indicating you really do have chain issues) or does it say “Chain Issues: No” (indicating that it should be fine)?

What is the precise SSL error you are getting on the computers that don’t work? This is the NET::ERR string shown by Google Chrome in small gray text, or the Technical Details section shown by Firefox, or the errors directly under “There is a problem…” in Internet Explorer, or directly under “Safari can’t verify the identity…” in Safari.

To diagnose the cause it can help to have the certificates the problem computer receives shown, even as a screenshot might be useful - and sometimes the problem can be obvious when looking at them without even sending to a forum like this. Displaying details of a certificate for a site when connection is rejected due to security issues varies by browser, but on desktop browsers it’s usually pretty obvious how to do it.

It is technically possible for a Windows Domain or even individual computer to be configured specially to reject Let’s Encrypt specifically, but that’s unusual. Can you visit other sites using Let’s Encrypt OK from the affected machines? If you need an example to try https://tlrmx.org/ ought to work, there is nothing much to be seen there but it has a Let’s Encrypt certificate.

1 Like

Please detail the steps you took to create the cert and the files names used when creating the PFX file.

it is: Chain issues None in ssllab

the error i get is “not secure” at the url (in chrome) and the gray text that under advanced allow me to continue anyway. in explorer the 2 red and green buttons (green for contiune anyway)

I have used certify program to make it

It would certainly be very helpful if you could tell us your domain name.

https://www.klil.co.il

that domain from my computer is working fine. from the problematic pc i get this error in the picture

Thanks, so that site (www.tlrmx.org) has a perfectly good certificate, I think we’ve definitely narrowed the issue to the particular machines which aren’t trusting this, and more importantly to you, aren’t trusting your own site.

I think the next thing to explore would be to ask the machines which certificates authorities they do trust, and see if “DST Root CA X3” is on the list as it usually would be. on Windows PCs. The Digital Signature Trust Co. no longer exists, but that widely trusted root now belongs to Identrust, and essentially vouches for Let’s Encrypt as trustworthy until Microsoft get around to deciding formally about it.

Hopefully one of this forums Windows efforts knows how to check that?

1 Like

To examine the root certificates present on a Windows system, press the Start button and type certmgr.msc and press Enter, and choose Trusted Root Certification Authorities on the left.

on that particular machine this DST ROOT CA X3 is not there (on mine it is)

i have exported the one i have on my windows 7 to my the one that doesn’t and it works now.
i have add this to the domain controller as well that didn’t have that

what should i do now? how can i know that users/clients that surf that website won’t have problems with the certificate as well?

In an absolute sense you can’t know, the owner/ administrator of a PC gets to make their own trust decisions. However the defaults out of the box will trust Let’s Encrypt on anything halfway modern (e.g. Windows XP is modern enough under this thinking).

Somebody has made an explicit decision to distrust DST Root CA X3 on those machines at some point. There is not usually any sort of audit trail, so unless somebody remembers doing it and can say why it’ll probably remain a mystery. I’m sorry this isn’t a very satisfying answer, perhaps another forum participant has a better one?

our domain controller is old machine, it has dst X1 and dst X2 but didn’t had X3 (now it does)

can that have any effect?

When you say “old machine” can you be a little more specific? I am not a Windows expert, but I expect the important thing here will be the version of Windows (on the domain controller, and possibly also the desktop or laptop) and perhaps when (roughly) it was first installed.

I seem to remember (Windows experts might know better) that old versions of Windows had a complete list of trusted CAs at install, newer ones fetch updates periodically from Microsoft’s web site.

Older versions of Windows may not include the necessary CA and would have downloaded it automatically from Windows Update. If root certificate updates are disabled or a firewall prevents it from getting new certificates from Windows Update then it may be missing.

Do you have root certificate updates disabled in Group Policy? (Computer Configuration -> Administrative Templates -> System -> Internet Communication Management -> Internet Communication Settings)

Unfortunately, there is a lot of bad security advice floating around on the Internet that suggests turning this off. If you do not regularly audit CAs and add them to the certificate store manually yourself then you really should not turn this off.

If it is not turned off, check your Event Log for errors starting with Failed auto update retrieval of third-party root list. If this error is present the computer is being blocked from contacting Windows Update for the new root certs somehow.

There is an IPv4/IPv6 issue that hasn’t been addressed: