Since 2021-09-30, our on premise 8.5r10 has been having issues trusting certificates issued by Let's Encrypt, which I think is related to this: https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/
This causes issues with a few integrations to our other internal systems, mainly scheduled CRMscripts sending requests to retrieve JSON. There were no issues prior to the 30th of September...
The debug output from an HTTP instance attempting GET on any URL where Lets Encrypt certificates are used informs me that "SSL certificate problem: certificate has expired"
No browsers are having issues nor do they report on the certificate having expired. I can replicate the issue on two wholly separate and isolated installations of 8.5r10 by simply attempting the HTTP.get(String) method with on any server using Lets Encrypt, i.e:
Since Service doesn't use the Windows Certificate Store but only the provided curl-ca-bundle.crt in the Service-folder on the server, I assume this CA certificate doesn't trust the new Let's Encrypt root certificate?
Here is the complete output from the code above:
CURLOPT_SSL_VERIFYHOST no longer supports 1 as value!
Connected to curl.se (184.108.40.206) port 443 (#0)
ALPN, offering http/1.1
Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
successfully set certificate verify locations:
TLSv1.2 (OUT), TLS header, Certificate Status (22):
TLSv1.2 (OUT), TLS handshake, Client hello (1):
TLSv1.2 (IN), TLS handshake, Server hello (2):
TLSv1.2 (IN), TLS handshake, Certificate (11):
TLSv1.2 (OUT), TLS alert, Server hello (2):
SSL certificate problem: certificate has expired
Closing connection 0
TLSv1.2 (OUT), TLS alert, Client hello (1):
Is the issue with the curl-ca-bundle.crt in the Service-folder or am I misunderstanding something?
If it is the curl-ca-bundle.crt, is there any other solution except updating to a newer version (and presumably) getting an updated bundle certificate?