curl 8.22 Makes mbedTLS Hostname Verification Independent of Peer Verification

curl 8.22 includes an mbedTLS backend correction with an important operational consequence: a certificate hostname mismatch can no longer disappear merely because peer verification is disabled while hostname verification remains enabled. The change aligns the backend more closely with the independent meaning of the two libcurl options.

The curl project described the change as “mbedtls: enforce verifyhost when verifypeer is disabled.” Its regression case used peer verification off, hostname verification on, and a certificate issued for a different name. Before the fix, that mbedTLS path could return success; after the fix, the hostname mismatch remains a verification failure.

This is especially relevant to proxy operators and buyers because one request may contain two distinct TLS relationships: the client-to-HTTPS-proxy connection and the proxy-to-origin connection. A test that treats them as one certificate check can hide the layer that actually failed.

What changed in the mbedTLS backend

Certificate verification answers several questions. Two of them are separate:

• Is the certificate chain trusted under the configured trust policy?
• Does the certificate identify the hostname the client intended to reach?

The affected callback cleared the complete verification-flag set when peer verification was disabled. That also removed the hostname-mismatch flag, even if hostname verification was still requested. curl 8.22 changes the filtering so only the disabled check is removed; a name mismatch survives and can produce the expected peer-verification error.

This correction is not a reason to disable peer verification. Production clients should normally keep both chain and hostname verification enabled. The unusual combination belongs in controlled compatibility diagnostics, not in a permanent workaround.

Why proxy workflows need two TLS checks

With a plain HTTP proxy carrying an HTTPS tunnel, the client authenticates the destination after the tunnel is established. With an HTTPS proxy, the client may first authenticate the proxy gateway, then separately authenticate the destination inside the tunnel.

Document both layers in every test:

Do not infer that a successful proxy handshake proves the origin identity. Do not rotate the proxy exit when the actual failure is a stable hostname mismatch; rotation adds noise and can turn a deterministic configuration error into a costly retry storm.

A safe verification matrix for curl 8.22

Run the following cases only against systems you own or are authorized to test. Use a disposable laboratory certificate and a non-production endpoint.

1. Confirm the runtime with curl --version and record the TLS backend. A curl version alone is not enough; the behavior discussed here is specifically about an mbedTLS build.
2. Establish a baseline with peer and hostname verification enabled and a certificate whose name matches the endpoint.
3. Replace the certificate with one issued for a different laboratory hostname. Keep both checks enabled and confirm a verification failure.
4. In the isolated regression case, disable peer verification but leave hostname verification enabled. A curl 8.22 mbedTLS build should still reject the wrong hostname.
5. Repeat the matrix separately for the HTTPS proxy name and the origin name. Label each result by TLS layer.
6. Test both a fresh connection and an eligible reused connection. Do not assume connection reuse exercises the same handshake path.
7. Restore strict verification and remove the laboratory exception immediately after the test.

For libcurl, record the effective values of the origin options and their proxy-specific counterparts. A command-line reproduction should capture the resolved target, proxy scheme, error code and TLS backend without logging credentials or session tokens.

Interpret failures without unsafe fallback

A hostname mismatch is an identity failure, not a capacity signal. The correct response is to stop the affected route, preserve a sanitized diagnostic record and fix the intended hostname, certificate deployment or proxy configuration.

Avoid these fallbacks:

• retrying the same mismatch across many residential exits;
• switching from HTTPS proxying to an unencrypted proxy transport;
• disabling both certificate checks to make the request succeed;
• bypassing the proxy without an explicit policy decision;
• suppressing the error in aggregate success metrics.

If an upgrade changes the result from success to failure, treat that as evidence that an earlier backend path accepted a mismatch. Investigate the endpoint identity instead of pinning the old behavior.

Upgrade checklist

• Inventory every curl/libcurl build and its TLS backend.
• Search configuration for disabled peer or hostname verification.
• Separate proxy TLS options from origin TLS options.
• Add a deliberate wrong-hostname test to pre-production checks.
• Confirm failure classification does not trigger exit rotation.
• Verify logs redact proxy credentials, cookies and full query strings.
• Test connection reuse, failover and recovery behavior.
• Keep both verification controls enabled in production.

Teams reviewing adjacent safeguards can also use the certificate pinning check, the proxy certificate expiry runbook, the failover recovery drill and the proxy bypass audit.

FAQ

Does disabling peer verification become safe in curl 8.22?

No. Hostname verification covers only one part of server identity. Disabling chain verification removes a major trust control and should not be used in production.

Does the change affect every curl TLS backend?

The reported correction is specific to mbedTLS. Backend behavior and supported combinations can differ, so record the actual runtime backend and test it directly.

Should a proxy pool rotate after a hostname mismatch?

Usually no. A certificate name mismatch is normally deterministic for the TLS endpoint and requested name. Rotation is appropriate for defined capacity or network failures, not for hiding identity errors.

What should be retained from the test?

Keep the curl version, backend, effective verification settings, TLS layer, sanitized endpoint alias, error code, test timestamp and pass/fail result. Do not retain passwords, authorization headers or raw user data.

Compliance note

Perform certificate and proxy testing only on infrastructure you control or have explicit permission to assess. Preserve strict verification for production traffic, collect the minimum diagnostic data required, and never use proxy rotation to bypass access controls or disguise unauthorized activity.