URLRead certificate validation inconsistency during redirects

Direct Answers

1. Does VerifyCertificate apply to every URL in a redirect sequence? Yes. The underlying HTTP library (libcurl on Linux/macOS, WinHTTP on Windows) reuses the same verification context for all hops. The VerifyCertificate setting you pass to the initial URLRead call governs certificate validation for the entire redirect chain.
2. Will a redirect to a self-signed certificate fail if the initial request had verification disabled? No, it will succeed. With VerifyCertificate -> False, certificate validation is disabled for every hop, including redirects to endpoints presenting self-signed or otherwise untrusted certificates.
3. Is there a way to inject custom CA certificates into URLRead without modifying system-level files? Not through a documented URLRead option. The function relies exclusively on the OS/global certificate store. The supported workarounds require configuration before the Wolfram kernel starts.

Confirmed Behavior (Version 13.3+)

• URLRead delegates HTTP handling to the platform stack. VerifyCertificate maps directly to that stack's verify-peer/verify-host toggles.
• Both libcurl and WinHTTP preserve the verification setting across redirects. They do not re-read options per hop.
• No URLRead parameter (as of 13.3) accepts a custom CA bundle path or trust-store object.

Likely Explanation (Platform Nuances)

The inheritance behavior is a consequence of how the underlying libraries implement redirect following. libcurl's CURLOPT_SSL_VERIFYPEER and WinHTTP's WINHTTP_OPTION_SECURITY_FLAGS are set once on the easy handle or session and remain active for the entire transfer, including all redirects. Wolfram's wrapper does not reset these between hops.

Edge cases that could alter this:

• If a redirect crosses from HTTPS to HTTP (downgrade), verification becomes moot for the final hop.
• Platform-specific redirect limits (libcurl default 50, WinHTTP default 10) may terminate the chain before a problematic certificate is encountered.
• POST-to-GET conversion on 301/302 redirects is handled by the library and does not affect certificate verification.

Workarounds for Custom CA Certificates

Linux/macOS (libcurl)

Set environment variables before launching the Wolfram kernel:

export SSL_CERT_FILE=/path/to/custom-ca-bundle.crt
# or
export SSL_CERT_DIR=/path/to/cert-directory/

The kernel inherits these at startup; libcurl reads them when the first URLRead executes.

Windows (WinHTTP)

WinHTTP does not honor SSL_CERT_FILE. You must import the CA into the Windows certificate store (CurrentUser or LocalMachine "Trusted Root Certification Authorities") programmatically before the request:

RunProcess["certutil", {"-addstore", "Root", "C:\\path\\custom-ca.cer"}]

Alternatively, use ExternalEvaluate with PowerShell to script the import.

Verification Steps

1. Create a test chain: Endpoint A (valid cert) → 302 redirect → Endpoint B (self-signed cert).
2. Call URLRead["A", VerifyCertificate -> False] — should succeed.
3. Call URLRead["A", VerifyCertificate -> True] (default) — should fail on the redirect with an SSL verification error.
4. For deeper inspection, start the kernel with CURL_VERBOSE=1 (Linux/macOS) to see per-hop verify-peer logging.

One Diagnostic Detail

If you are seeing behavior that contradicts the above (e.g., a redirect fails despite VerifyCertificate -> False), please provide the Wolfram Language version and operating system. A library upgrade or a non-standard HTTP stack (e.g., a corporate proxy terminating TLS) could change the inheritance model.