Question
URLFetch returns SSLHandshakeFailed on Linux when server omits intermediate certificates
Sora Maple
0 reputation · 15 Oct 2023, 18:43 UTC
96K views
Loading…
0 reputation · 15 Oct 2023, 18:43 UTC
When using URLFetch with VerifyCertificate->True (the default) to access an HTTPS site that presents a certificate chain missing intermediate certificates, the request succeeds on Windows and macOS but fails with an SSLHandshakeFailed error on Linux. The goal is to determine why this platform‑specific difference occurs and whether the bundled CA bundle used by URLFetch on Linux can be inspected or supplemented without reinstalling Wolfram Language.
Because VerifyCertificate->False disables all validation and is unsafe for production, and because Wolfram Language provides no public API to list or refresh its embedded certificates, users lack a supported method to adjust trust anchors on Linux. Additionally, the exact version‑dependent behavior of the CA bundle selection is not documented, leaving uncertainty about how updates to the underlying trust store would affect URLFetch.
What CA bundle does URLFetch employ on Linux by default? Is there a supported way to extend or replace that bundle without a full reinstall? Does setting VerifyCertificate->False affect any other security checks beyond certificate validation?
On Linux, URLFetch typically fails with SSLHandshakeFailed when a server omits intermediate certificates because the underlying OpenSSL implementation requires a complete chain of trust to be presented by the server. In contrast, Windows and macOS often employ Authority Information Access (AIA) chasing, where the client automatically downloads missing intermediate certificates using URLs embedded in the certificate itself. Linux clients generally do not perform AIA chasing by default.
By default, URLFetch on Linux employs a bundled CA certificate store provided by the Wolfram Language installation to ensure consistency across different distributions. Because this bundle is embedded within the application's internal resources, there is no supported public API to dynamically extend or replace these trust anchors without modifying the installation files directly—an action that is not recommended as updates will overwrite changes.
Setting VerifyCertificate → False disables the validation of the server's certificate chain entirely. This means the client will no longer verify that the certificate was issued by a trusted CA or that the certificate matches the hostname of the server. While this bypasses the SSLHandshakeFailed error, it leaves the connection vulnerable to Man-in-the-Middle (MitM) attacks, as any certificate (including self-signed or fraudulent ones) will be accepted.
To confirm that the failure is caused by missing intermediates rather than an expired root or network issue, run the following command on the affected Linux machine:
wolfram
linuxopenssl s_client -connect your-server.com:443 -showcertsIf the output indicates a verify error:num=20:unable to get local issuer certificate, the server is failing to provide the necessary intermediate chain. The correct resolution is to configure the web server to send the full certificate chain (the server certificate plus all intermediates).
To provide a more specific workaround, please specify if you are using a system-installed version of the Wolfram Language (e.g., via a package manager) or a standalone installation, as this affects where the internal CA bundles are located on the filesystem.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.