Proxy TLS Certificate Errors: Distinguish Proxy and Target Verification Failures

First identify the two possible TLS connections

1. Client to proxy TLS, when the proxy URL itself uses https://.

2. Client to target TLS through a tunnel, after an HTTP proxy accepts CONNECT for an HTTPS target.

Capture the exact curl build and error

curl --version

Run a direct target control

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

Test an HTTP proxy without inventing an HTTPS-proxy layer

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

• DNS and TCP connection to the proxy;

• proxy authentication or policy response;

• CONNECT response;

• TLS handshake with the target hostname;

• target HTTP response, if any.

Test an HTTPS proxy as a separate trust boundary

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

• an error naming the proxy hostname can belong to the client-to-proxy TLS layer;

• an error naming the target hostname can belong to the target TLS layer after tunneling;

• a CONNECT rejection can occur between those two layers and is not a certificate result.

Use custom CA files only for the correct layer

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

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

Treat insecure flags as diagnostic only

Common failure patterns

Capture a reviewable evidence record

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 and 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:
Command actually executed: yes | no
Credentials included in report: no
Reviewer:

Limitations and factual boundaries

• Certificate verification proves identity only within the selected trust model; it does not prove target permission, route quality, or application correctness.

• A valid proxy certificate does not validate the target certificate.

• A valid target certificate does not prove the proxy endpoint, credentials, or requested geography are correct.

• A successful CONNECT response does not guarantee that the target TLS handshake or HTTP request will succeed.

• Different curl TLS backends and operating-system trust stores can produce different results.

• The examples above were not executed in this content operation and are not evidence of BytesFlows product compatibility or performance.

Next step

Evidence used for this draft

• curl TLS certificate verification documentation: curl verifies certificate signatures and hostname identity by default and strongly discourages skipping verification in production.

• curl official manual: documents distinct HTTPS-proxy options including --proxy-cacert, --proxy-ca-native, and --proxy-insecure, separate from target TLS options.

• RFC 9110: defines CONNECT as establishing a tunnel after a successful response, which helps separate proxy HTTP responses from the later target TLS exchange.

2026-07-20 review update