curl 8.22 Fixes HTTPS Proxy CA-Blob Selection with Native CA

The curl project’s September 2, 2026 changelog lists a focused proxy TLS fix: libcurl now honors CURLOPT_PROXY_CAINFO_BLOB over Native CA. The change matters to applications that connect to an HTTPS proxy, supply that proxy’s CA material from memory, and also enable the operating system’s native certificate store.

This is not evidence that every curl proxy deployment was insecure. It is a configuration-specific precedence correction, and the right response is to inventory the exact runtime path, upgrade where applicable, and prove the selected trust behavior with a controlled certificate matrix.

Public source note: curl project, curl 8.22.0 changelog, September 2, 2026; curl project, TLS Certificate Verification documentation, reviewed September 10, 2026.

What changed

libcurl separates TLS verification for an HTTPS proxy from verification of the destination server reached through it. Applications can provide CA data for the proxy as an in-memory PEM blob through CURLOPT_PROXY_CAINFO_BLOB. They can also request use of a native CA store through proxy TLS options when the selected backend supports it.

The 8.22.0 changelog says the proxy CA blob is now honored over Native CA. Operationally, this means teams using both mechanisms should not rely on assumptions formed from another curl version, TLS backend, or operating system. The intended proxy trust source needs a regression test.

Do not confuse the two TLS legs:

A successful destination response does not by itself prove that the proxy certificate was evaluated against the intended trust source.

Determine whether the change applies

Check all of these before prioritizing work:

1. The application uses libcurl rather than only the curl command-line interface.
2. The configured proxy URL uses HTTPS, so there is a TLS connection to the proxy.
3. The code sets CURLOPT_PROXY_CAINFO_BLOB.
4. The code or build enables Native CA for proxy verification.
5. The active TLS backend supports the relevant options.
6. The deployed libcurl version predates the corrected release.

Record the result per binary or container image. An application may ship more than one libcurl build across operating systems, and backend behavior can differ.

Useful inventory fields are:

application_build
libcurl_version
tls_backend
operating_system
proxy_scheme
proxy_verify_peer
proxy_verify_host
proxy_cainfo_blob_configured
proxy_native_ca_enabled
origin_cainfo_source

Never record the contents of private keys, proxy credentials, tokens, cookies, or production secrets.

Build a controlled trust matrix

Use an HTTPS proxy endpoint you own or are authorized to test. Prepare two non-production test CA roots:

• Blob root: included only in the in-memory proxy CA blob;
• Native root: installed only in the isolated test system’s native store.

Issue separate proxy certificates from each root for the same authorized proxy hostname. Keep hostname verification enabled, keep the destination certificate valid, and use a harmless destination response marker.

Run at least these cases:

The exact combined-policy expectation depends on the TLS backend and documented option semantics. Write it before running the test; do not reverse-engineer a desired answer from the outcome.

For each attempt capture version, backend, options, proxy hostname, certificate issuer fingerprint, verification result, curl error code, destination marker, and timing. Hash or fingerprint certificates rather than storing unnecessary full chains.

Compare old and corrected builds safely

Run the same matrix against the deployed build and curl 8.22.0 or a vendor build containing the fix. Use identical application code, fixture certificates, proxy endpoint, destination, environment, and option order.

Important controls:

• start each process clean so CA caches do not cross cases;
• do not disable peer or hostname verification;
• do not substitute an HTTP proxy, because it removes the proxy TLS leg;
• keep origin trust fixed while proxy trust changes;
• preserve the first failure before retrying;
• test every production TLS backend separately.

The proxy TLS session-resumption test helps preserve separate handshake and connection-reuse evidence. Use the proxy request-header integrity test if the application result changes after the tunnel is established.

Avoid unsafe workarounds

Do not respond by setting CURLOPT_PROXY_SSL_VERIFYPEER to zero or weakening hostname verification. Encryption without identity verification does not establish that the client reached the intended proxy.

Safer responses are:

1. upgrade to curl 8.22.0 or an appropriate vendor package carrying the fix;
2. apply the upstream correction through the normal software-maintenance process;
3. temporarily simplify to one documented proxy trust source in a controlled configuration;
4. add the trust matrix to release qualification.

Treat proxy CA material as configuration data with ownership, rotation, expiry, and audit controls. An in-memory blob avoids a file path, but it does not remove lifecycle responsibilities.

Deployment checklist

• Confirm the shipped libcurl version and TLS backend, not just the development machine.
• Verify that the proxy scheme is HTTPS.
• Search code and configuration for CURLOPT_PROXY_CAINFO_BLOB and proxy Native CA settings.
• Keep proxy and destination CA policies separate.
• Test blob-only, native-only, untrusted-root, and wrong-hostname cases.
• Keep peer and hostname verification enabled.
• Repeat for every supported OS and backend.
• Roll out gradually and monitor proxy TLS verification errors.
• Document the intended trust-source policy and certificate rotation owner.
• Do not log credentials, private keys, CA blob contents, or sensitive traffic.

FAQ

Does this fix affect ordinary HTTP proxies?

The trust-selection issue concerns the TLS connection to an HTTPS proxy. A plain HTTP proxy has no equivalent proxy-certificate verification step, though destination TLS may still occur through a tunnel.

Is the destination CA bundle the same as the proxy CA bundle?

No. They secure different TLS peers. libcurl provides proxy-specific verification and CA options so the policies can remain separate.

Does a successful request prove the CA blob was used?

No. Another enabled trust source may also accept the certificate. Use certificates trusted by exactly one test source to prove selection.

Should teams remove Native CA everywhere?

No. Choose a documented policy appropriate to the platform and backend. The news item is a reason to validate precedence, not a universal instruction to abandon native stores.

Compliance note

Run certificate tests only against proxy endpoints, test roots, machines, and destination services you control or are authorized to use. Do not install experimental roots in shared production stores, disable verification, intercept third-party traffic, or expose proxy credentials and private key material.