Proxy TLS Certificate Errors: Diagnose Proxy vs Target TLS

A TLS certificate error during a proxied HTTPS request does not tell you which connection failed. Diagnose the request as separate stages: client → proxy transport, proxy authentication/CONNECT, then client → target TLS through the tunnel. The certificate hostname and the stage where curl stops are usually more useful than the generic “SSL error” label.

This guide uses example hosts and commands for diagnosis. Replace them with an endpoint and target you are authorized to test. Do not disable certificate verification as a production workaround.

The key distinction: proxy TLS vs target TLS

There can be two independent TLS relationships:

1. Client → proxy TLS exists when the proxy URL itself uses https://.
2. Client → target TLS exists when the destination is HTTPS. With an ordinary http:// forward proxy, curl normally establishes a CONNECT tunnel first and then performs the target TLS handshake through it.

An http:// proxy therefore does not imply plaintext traffic to an HTTPS target. It means the proxy transport itself is HTTP; target HTTPS remains TLS-protected through the tunnel after CONNECT succeeds.

Before troubleshooting, record both the proxy scheme and target scheme.

Step 1: capture the curl build and exact failure

curl --version

Record the curl version, TLS backend, operating system or container image, system time, exit code, and complete sanitized error. Trust-store behavior can differ by TLS backend and operating system.

Preserve which hostname the error names. A proxy hostname and a target hostname point to different trust boundaries.

Step 2: establish a direct-target control

Use a target you control or are authorized to test:

curl --silent --show-error --output /dev/null \
  --connect-timeout 10 --max-time 30 \
  --write-out 'code=%{http_code} remote_ip=%{remote_ip} connect=%{time_connect} total=%{time_total}\n' \
  https://example.com/

A successful direct request shows that this client can validate this target on the direct path. It does not validate proxy credentials, the proxy certificate, CONNECT policy, route selection, or proxy-to-target reachability.

Step 3: test an HTTP proxy and inspect the stages

curl --verbose \
  --proxy 'http://proxy.example.net:12345' \
  --proxy-user "${PROXY_USER}:${PROXY_PASS}" \
  --connect-timeout 10 --max-time 30 \
  https://example.com/

Read the trace in order:

1. DNS/TCP connection to the proxy.
2. Proxy authentication and policy response.
3. CONNECT response for the HTTPS target.
4. Target TLS handshake through the established tunnel.
5. Target HTTP response.

A 407 Proxy Authentication Required is a proxy-authentication challenge, not a target certificate failure. RFC 9110 requires a proxy-generated 407 to include Proxy-Authenticate.[1]↗

Likewise, a non-2xx CONNECT response occurs before a successful target tunnel exists. A target certificate error after CONNECT does not by itself prove the proxy endpoint is unhealthy.

Step 4: test an HTTPS proxy only when the endpoint supports it

Do not change http:// to https:// just to see whether an error disappears. The scheme must match the service actually offered by the endpoint.

When an endpoint explicitly supports HTTPS proxy transport:

curl --verbose \
  --proxy 'https://proxy.example.net:12345' \
  --proxy-user "${PROXY_USER}:${PROXY_PASS}" \
  --connect-timeout 10 --max-time 30 \
  https://example.com/

curl verifies HTTPS-proxy TLS separately from target TLS. Its official documentation provides proxy-specific trust controls such as --proxy-cacert, --proxy-ca-native, and --proxy-insecure, distinct from target controls such as --cacert, --ca-native, and --insecure.[2]↗[3]↗

That separation gives you a useful diagnostic rule:

• an error naming the proxy hostname before CONNECT can belong to client → proxy TLS;
• an error naming the target hostname after CONNECT can belong to target TLS;
• a CONNECT rejection between those stages is an HTTP/proxy result, not a certificate result.

Step 5: apply a custom CA to the correct trust boundary

If an authorized test target uses a private CA:

curl --cacert /approved/path/target-ca.pem \
  --proxy 'http://proxy.example.net:12345' \
  https://example.com/

If an authorized HTTPS proxy uses a private CA:

curl --proxy-cacert /approved/path/proxy-ca.pem \
  --proxy 'https://proxy.example.net:12345' \
  https://example.com/

Do not download an unknown CA from an error page or trust a certificate merely because adding it makes the request succeed. Confirm the expected issuer and CA distribution channel with the service owner.

Use insecure flags only as a controlled diagnostic

curl's --insecure skips target certificate verification, while --proxy-insecure skips HTTPS-proxy verification.[2]↗ These options remove identity verification and are not production fixes.

If policy permits a short diagnostic comparison, change one variable at a time and record exactly which flag changed the result. Do not disable both layers and then conclude that the route is healthy.

Failure matrix

These are diagnostic categories, not universal conclusions. Middleboxes, enterprise TLS inspection, alternate DNS answers, container images, stale clocks, and target configuration can all change the observed chain.

Capture evidence before changing configuration

UTC time:
Client OS/container image:
curl version and TLS backend:
System time verified: yes | no
Proxy scheme: http | https | socks5 | unknown
Proxy hostname: approved test hostname or redacted
Target hostname: permitted hostname
Direct target result:
Proxy connection result:
CONNECT status, if any:
Certificate error names: proxy | target | unclear
Issuer/subject: sanitized
CA option used: none | --cacert | --proxy-cacert | native
Insecure option used: none | --insecure | --proxy-insecure
HTTP status, if any:
Exact curl exit code and error:
Credentials included in report: no

Do not publish proxy credentials, private CA material, account identifiers, internal hostnames, or unredacted verbose traces.

Common mistakes

Treating every TLS error as a proxy failure

First identify whether the failure happened before CONNECT, at CONNECT, or during target TLS. The same user-facing phrase can hide different layers.

Changing the proxy scheme without documentation

http://proxy... and https://proxy... describe different client-to-proxy transports. They are not interchangeable labels.

Fixing a 407 with certificate changes

A 407 is an authentication challenge. Check credentials and the advertised proxy authentication method before touching CA configuration.[1]↗

Leaving --insecure in production

A request succeeding after verification is disabled identifies a diagnostic direction; it does not establish a safe fix.

Production checklist

• Confirm proxy hostname, port, scheme, and authentication method from the current Dashboard or account documentation.
• Verify system time and curl/TLS backend.
• Run a direct-target control.
• Capture a sanitized verbose proxy trace.
• Separate proxy TLS, CONNECT, and target TLS stages.
• Apply CA overrides only to the layer that actually requires them.
• Never persist --insecure or --proxy-insecure as the solution.
• Redact credentials and private infrastructure before sharing evidence.
• Re-test after the smallest configuration change.

FAQ

Does an HTTPS target mean I need an HTTPS proxy?

No. An HTTPS target can be reached through an HTTP forward proxy using CONNECT. HTTPS proxy transport is a separate client-to-proxy TLS layer.

Does a successful CONNECT prove TLS is healthy?

No. CONNECT establishes the tunnel after a successful response; target TLS can still fail afterward.[1]↗

What is the difference between --cacert and --proxy-cacert?

--cacert controls trust for the target TLS connection. --proxy-cacert controls trust for an HTTPS proxy connection. curl documents the two verification contexts separately.[2]↗

Should I use --insecure to fix certificate errors?

No. It disables target certificate verification. Use it only for a policy-approved diagnostic comparison, then correct the trust or certificate problem instead.

Where should I start with a BytesFlows endpoint?

Use the current endpoint scheme, hostname, port, and authentication format shown in your BytesFlows account rather than copying example values from this article. Then follow the BytesFlows proxy setup guide. If name resolution fails before TLS begins, use the proxy DNS troubleshooting guide.

Sources and scope

The protocol and curl behavior in this guide is grounded in RFC 9110 and current curl TLS/manpage documentation.[1]↗[2]↗[3]↗ Example endpoints, timeouts, and hosts are illustrative values, not BytesFlows performance claims or guarantees.

This article does not claim that a valid certificate proves authorization, route quality, requested geography, or application correctness. It also does not claim that a proxy changes browser fingerprinting or bypasses target security controls.