we are using an proprietary software on Windows which utilizes Msxml2.XMLHTTP.3.0 from msxml3.dll to retrieve Data from our Webserver where we use certbot.
This was working fine until monday 30.11.
So i did not think of certificate issues at first, but after trying with a different domain with a cert from DigiCert and tried using non SSL connection, which are working, i now know that LE is the issue here.
Already tried to remove the old "DST Root CA X3" from the chain on the webserver, installing the intermediate R3 and new "ISRG Root X1" certificates on the clients etc.
Nothing did help.
Had a similar issue also in Outlook 2016 where Images from external LE-SSL Websites cannot be displayed anymore. Others work.
If the chain on the webserver was including the actual DST root (as opposed to the ISRG Root signed by the DST Root), something is/was probably wrong with how the chain is configured.
Can you provide more detail on the webserver configuration? For example, what software/version is it? What does the TLS configuration look like?
Installing R3 on the clients shouldn't be necessary. Technically, ISRG Root X1 should be installed automatically on Windows clients, but verifying it is installed is still good since there seems to be a variety of configurations that prevent the automatic installation.
Nothing remarkable about Let's Encrypt intermediate or root certs happened on Nov 30.
Have you checked to make sure your cert is still valid? We would have checked that and more if you would provide a domain name and sample URL of failing images. Without that it is hard to guess what is wrong exactly.
You could use a site like this to check your cert chain SSL Checker
Is ISRG Root X1 (signed by ISRG Root X1) present in your windows certificate store, under Trusted Certification Authorities, and if not find out why not (is automatic update of CA root certificates disabled by group policy, etc).
It could be unrelated but your version of Msxml (Msxml2) is long since abandoned by Microsoft (20 years ago?), is there any way you can upgrade? If this software is important to your business you need to update it, otherwise your business is at risk. If it's not important to your business, bin it.
It's very likely you can set an option to ignore TLS certificate validation, but this is generally not recommended unless you don't care if the connection is secure or not.
The Problem exists in different Windows versions, Windows 10, Windows Server 2012, Windows Server 2016.
The ISRG Root X1 is as you mentionied present in the certificate store.
Our Software we are using is mandatory for our business. Even if its unsafe to use msxml3 (which is still maintained) the communication is only in our private network, so not a problem with security issues.
Since the Software is proprietary and is unconfigurable for, we can't change the SSL options for it.
We are running different Apache 2.4 installations on Debian Servers from v8 to 11, also with different Versions Certbot.
This issue is present on all machines. Regardless the configuration.
Forgot to mention that i already tried to create new certificates with --preferred-chain "ISRG Root X1" also.
And like i said, if switching to a cert from digicert, without changing any other configurations, the problem is gone.
Is your apache server using chain.pem or fullchain.pem? If just chain.pem are you also specifying intermediate certificates?
Without a url to test it's hard to know what chain your server is actually presenting.
Regarding maintenance of MSXML3 it was definitely last updated in 2007 (SP3), unless you have a link to an MS document that says otherwise. I'm confused as to whether your are using MSXML 2 or MSXML 3.
Exact error thrown when trying to connect to a Server with LE:
Error Nr.: 1429 - 'OLE-IDispatch-Ausnahmecode 0 von msxml3.dll: Fehler beim Herunterladen der angegebenen Ressource.
Your chain is the DST Root CA X3 (expired root) one which is not trusted on windows, however windows should follow the path to the version of ISRG Root X1 (signed by DST Root CA X3) and realize it has ISRG Root X1 (self signed) in it's trust store, and use that chain instead.
As already mentioned by @rg305 you could switch to another ACME CA (such as ZeroSSL) the benefit of that is their cross signed root is trusted by older software, really though there's no good reason why the ISRG Root X1 chain shouldn't have worked especially if you are using fullchain.pem.
Are you 100% sure you have the ISRG Root X1 (self signed) installed on Windows (not ISRG Root X1 signed by DST Root CA X3)? You mentioned Outlook didn't work at one point and you shouldn't have to install this stuff (especially not the R3 intermediate), windows should be updating it itself unless that has been blocked. Check that group policy has not blocked automatic root certificate updates (How to enable the "automatic root certificates update" on Windows Server 2016 - Microsoft Q&A). There was briefly a fashion for blocking these updates a long time ago due to an old limitation in windows, and some administrators never removed that setting.
Ah, MSXML2 is a name I haven't heard in a long time. And yeah, its diagnostics are terrible. If it gave more useful errors than just "The download of the specified resource failed" when calling document() functions within XSLT, I'm pretty sure I personally would have been spared several man-weeks of debugging time.
I believe it basically uses the same underlying HTTP/HTTPS libraries as the rest of Windows, so here are some ideas for some further troubleshooting:
See if you can connect to the server using other libraries on that same computer, like Powershell or IE.
See if you can use that library (maybe make some simple scratch program) to connect to https://helloworld.letsencrypt.org/ and https://valid-isrgrootx1.letsencrypt.org/. That might help narrow down whether it something specific to your server, or something for all servers using Let's Encrypt certificates.
