curl 8.22 Tightens Certificate Pinning When a TLS Peer Sends No Certificate

curl 8.22.0, released on 2 September 2026, includes an OpenSSL-related TLS correction described by the curl project as “no server cert is only okay if also not pinned.” The underlying change makes a precise promise: when a public-key pin is configured, the absence of a peer certificate must not take an acceptance path intended for deployments that explicitly disabled certificate verification.

The project change also centralizes selection of the appropriate pinned-public-key option for the connection being verified, including the distinction between an HTTPS proxy and the destination server. That distinction matters because an HTTPS request through an HTTPS proxy can involve two separate TLS peers and two separate trust decisions.

What changed—and what did not

Public-key pinning compares the peer certificate's public key against a configured value or digest. It is an additional identity constraint; it is not a substitute for understanding the normal certificate-verification policy.

Before this correction, an OpenSSL-backed path that encountered no peer certificate could treat the condition as acceptable when certificate verification was disabled, without also requiring that no public-key pin had been configured. curl 8.22 tightens that condition: no peer certificate is acceptable only when verification is disabled and no pin applies.

The fix does not mean certificate verification should be disabled. It does not merge origin pins with proxy pins, repair an incorrect pin, rotate pins automatically or make every TLS failure retryable. It ensures that a configured pin cannot be satisfied when the required certificate evidence is absent.

Why proxy operators should care

An automation client can establish TLS to the proxy, then create a CONNECT tunnel and establish another TLS connection to the destination. These layers have different identities:

1. the HTTPS proxy certificate authenticates the proxy endpoint;
2. the destination certificate authenticates the origin inside the tunnel;
3. proxy public-key pinning applies to the proxy layer;
4. origin public-key pinning applies to the destination layer.

Confusing the layers can produce false confidence, failed rotations or logs that blame the wrong system. A successful TCP connection to the proxy does not prove the origin identity, and an origin pin does not authenticate the proxy.

Use the proxy gateway certificate expiry runbook to keep routine expiry monitoring separate from pin validation.

Identify configurations that need review

Inventory applications using curl or libcurl with an OpenSSL-family TLS backend. Record the running library version rather than relying on a shell binary installed on the same host.

Prioritize configurations that use any of the following:

• origin public-key pinning;
• HTTPS-proxy public-key pinning;
• disabled peer verification in a lab or legacy exception;
• separate TLS settings for proxy and origin;
• custom connection reuse or shared connection caches;
• automatic proxy rotation after TLS failure;
• direct fallback when a proxy route fails.

Do not store full pin material or private configuration values in the inventory. Record a configuration alias, pin version, owner, peer layer and planned retirement date.

Build a two-layer regression matrix

Use a proxy and origin you control. Never simulate a missing certificate against an unrelated public service. Create test fixtures that isolate each trust boundary.

The last row is not a recommended production configuration. It is included only to prove that the corrected behavior distinguishes “no verification and no pin” from “a pin exists but cannot be evaluated.”

Test the running backend

Different libcurl builds can use different TLS backends. Capture the version and backend string from the actual application runtime. A container, language binding or statically linked service may not use the operating system's curl package.

For each test, record:

client_build_alias
curl_version
tls_backend
route_type
peer_layer
verification_policy
pin_configured
certificate_present
curl_result
connection_reused

Never record proxy passwords, private keys, complete authorization headers or session cookies. If diagnostic output contains certificate details, restrict access and retention.

Keep proxy and origin options separate

In libcurl and the curl command-line tool, proxy TLS verification and origin TLS verification have separate controls. The same principle applies to public-key pins. Review code and configuration so the proxy pin is not accidentally assigned to the origin or vice versa.

A useful review technique is to render a configuration map with two columns: “proxy TLS” and “origin TLS.” Place CA policy, hostname verification, public-key pin, client certificate and SNI ownership in the correct column. Any value that appears in both should be there deliberately.

Use the proxy request header integrity test for HTTP boundary checks, but do not mix header evidence with TLS identity evidence.

Treat missing-certificate failures as identity failures

When a pin is configured and the peer does not provide a certificate, changing the residential exit address is not a valid remediation. The client lacks evidence required by policy. Classify the result as a TLS identity failure, stop retries for that route and alert the responsible owner.

Do not:

• disable pinning to make the request pass;
• disable peer or hostname verification;
• rotate rapidly across proxy exits;
• fall back silently to a direct connection;
• accept a certificate from a different layer;
• copy diagnostic secrets into a ticket.

The correct response may be to restore the expected endpoint, correct a gateway configuration, deploy an approved pin transition or roll back the client upgrade while preserving security requirements.

Plan safe pin rotation

Pinning creates operational coupling to key changes. Maintain at least a documented current and next-pin plan where the client and policy support it. Validate the transition in a controlled environment before certificate renewal or gateway replacement.

Track:

• which peer layer owns the pin;
• the pin version and activation window;
• the certificate/key rotation owner;
• canary and rollback criteria;
• the maximum overlap period;
• removal of obsolete pins.

Never keep a broad or stale pin set simply to avoid failures. The set should represent an approved identity transition, not a collection of every key ever observed.

Test connection reuse

A reused connection can hide a new handshake problem until the cache expires. Run tests with fresh connections and with the production reuse policy. Force a controlled endpoint or certificate transition, then verify that the client does not continue to attribute an old verified connection to a new configuration.

Separate metrics for new and reused connections. A canary that exercises only warm connections can miss the exact condition that new deployments encounter.

Rollout gates

Before approving curl 8.22 for a pinned proxy workflow, require:

• matching proxy and origin pins succeed only at their intended layers;
• a wrong proxy pin fails before the tunnel is used;
• a wrong origin pin fails inside the tunnel;
• a missing certificate fails whenever the relevant pin is configured;
• no TLS identity failure triggers uncontrolled rotation;
• no mandatory-proxy workflow falls back to direct traffic;
• new and reused connections both follow policy;
• logs identify the failing layer without exposing secrets;
• pin-rotation ownership and rollback are documented;
• validated-result rate and tail latency remain within the canary budget.

Upgrade checklist

• [ ] The deployed curl/libcurl version and TLS backend are known.
• [ ] Origin and HTTPS-proxy pin configurations are inventoried separately.
• [ ] Disabled-verification exceptions are documented and scheduled for removal.
• [ ] Controlled fixtures cover matching, mismatching and missing certificates.
• [ ] Both proxy and origin TLS layers are tested.
• [ ] Fresh and reused connections are included.
• [ ] TLS identity failures have a bounded, non-rotating response.
• [ ] Direct fallback is disabled for mandatory-proxy tasks.
• [ ] Logs exclude passwords, private keys, cookies and full tokens.
• [ ] Current and next-pin procedures are rehearsed.
• [ ] Canary and rollback thresholds are approved.

FAQ

Does this change affect every curl user?

No. It is specifically relevant to OpenSSL-backed TLS handling when a peer certificate is absent and public-key pinning or disabled verification is involved. Confirm the backend and configuration used by the running application.

Can a public-key pin replace CA and hostname verification?

Pinning is an additional constraint and should be designed with the organization's certificate policy. Do not disable normal verification merely because a pin is present.

Is the proxy pin the same as the destination pin?

No. An HTTPS proxy and the tunneled destination are different TLS peers. Configure, rotate and observe their pins independently.

Should a missing-certificate error be retried through another exit?

Not automatically. When policy requires a pin, the missing certificate means required identity evidence is unavailable. Stop and diagnose the relevant TLS layer.

Related 98IP guidance includes proxy credential rotation, proxy failover recovery drills and proxy bypass audits.

Source note: curl project, “Changes in 8.22.0,” released 2 September 2026; curl project change “openssl: no server cert is only okay if also not pinned,” merged 25 August 2026. External source locations are retained only in the internal operations record.

Use only controlled systems and destinations you own or are authorized to test. Follow certificate policies, access terms, privacy obligations and applicable law. Never weaken TLS verification or expose credentials to complete a proxy test.