Proxy mTLS Tests: Separate Target Client Certificates from Proxy Authentication

Name the authentication layer before changing an IP

This guide is for a team testing its own HTTPS endpoint that requires an authorized client certificate. A proxy account login, a tunnel response and target mTLS authentication answer different questions. Changing the residential exit cannot repair a missing client key or make an unauthorized certificate acceptable to the target.

In curl, target client-certificate options and HTTPS-proxy client-certificate options are separate. The latter apply to the proxy TLS connection, not to the target server. An HTTP proxy can establish a CONNECT tunnel only when the requested destination and port are permitted. These distinctions are documented by the curl project; this guide is a proposed acceptance workflow, not a test result for every 98IP route.

1. Prepare a harmless endpoint and a known identity

Use an owned non-mutating health or test endpoint with a documented response and a test identity that the target explicitly authorizes. Have the target owner confirm the required certificate chain and trust policy. Give each test a harmless correlation identifier that can be found in server logs; it must not contain credentials.

Keep the private key in its approved local store. Record certificate identity using a safe internal identifier or fingerprint, expiration and the permitted purpose. Record the client executable version and TLS backend using curl --version. Certificate formats and key selection differ by backend; confirm the installed client's supported configuration before assuming a PEM file and a separate key will work on every platform.

2. Prove the target baseline with two direct cases

Case A: call the endpoint without a client certificate, with ordinary server trust verification enabled. The fixture should reject access according to its configured mTLS policy. Depending on where that policy is enforced, you may see a handshake failure or an application denial; do not require one universal HTTP status.

Case B: repeat with the authorized test identity and the correct target trust configuration. Require the expected harmless response and target-side evidence of the accepted identity. If B fails, investigate certificate selection, key availability, chain, validity and server authorization before introducing the proxy. A functioning direct baseline makes the next comparison meaningful.

3. Repeat through the proxy without confusing the two identities

Case C: use the intended proxy access method but omit the target client certificate. Confirm whether proxy access and tunnel establishment succeeded separately from the target rejection. Case D: retain the same target context as B, add the approved proxy route, and supply the authorized target identity. Verify the expected response and accepted identity at the target again.

For curl configuration, --cert identifies the target client certificate; --key is used where the selected TLS backend requires a separate key, and --cacert selects a target CA file when appropriate. HTTPS-proxy counterparts such as --proxy-cert and --proxy-cacert belong to a separate proxy TLS leg. Do not move target credentials into those fields to fix a target error. An HTTPS proxy TLS leg exists only if the actual configured proxy endpoint supports that scheme; do not invent it from the HTTPS target URL.

4. Locate a failure at the last completed stage

A proxy access denial is an access-configuration problem before target identity testing. A refused or failed CONNECT concerns the permitted destination or route. A server trust failure concerns verification of the peer at the relevant TLS leg. A target rejection after reaching its certificate policy concerns the chosen identity and authorization. Use actual stage evidence rather than attributing every failure to the exit IP.

A CONNECT success is not the target application's HTTP success. Likewise, a target 200 is insufficient if it came from a default page without client authentication. Check response content, final host and target logs. Keep automatic cross-host redirects disabled for the fixture so a new destination cannot silently change the authentication boundary.

5. Repeat identity changes on fresh test connections

Run each matrix case on a fresh client connection to avoid confusing an earlier authenticated connection with the identity selected for a later case. After changing certificates, explicitly end the previous test context. If connection reuse is part of the real application, test it in a separate phase with an explicit identity-partition design.

Store only sanitized stage results, timing, correlation IDs and identity references. Do not upload private keys to the proxy console, place secret passphrases in shell history, or publish verbose traces containing authentication headers. Resolve CA or identity errors at their source; disabling server verification does not establish a valid mTLS acceptance test.

Where 98IP fits

Use 98IP dynamic residential IP when the approved test requires a residential route. Follow the account's actual extraction and authentication options, and consult the operation guides for supported connection setup. Confirm destination-port and endpoint-scheme availability before choosing the test route.

The proxy supplies a connection path. It does not issue your target certificate, authorize its identity, or guarantee that every client backend, tunnel or target policy is compatible. Keep the target private key under your own control and obtain the target owner's acceptance evidence before declaring the integration working.

FAQ and acceptance checklist

Does proxy username/password satisfy target mTLS? No. It authenticates proxy access; the target's client identity is separately selected and authorized.

Can rotating exits solve a rejected certificate? It cannot fix the certificate identity. If the target also applies a source-IP policy, evaluate that as a separate authorized requirement rather than confusing it with mTLS.

Pass criteria: direct missing-identity rejection, direct authorized-identity acceptance, proxy missing-identity rejection after the applicable access stages, and proxy authorized-identity acceptance with target evidence. Confirm harmless body content, verified peer trust, fresh matrix connections, no cross-host redirect, and sanitized logs. An unavailable route makes that case unresolved, not passed.

Test only owned or expressly authorized services with identities issued for the agreed purpose. Limit request volume and retain minimal evidence. No compatibility, security or performance guarantee follows merely from these proposed cases.