REST Assured has a proxy specification that carries the intermediary’s address and credentials together:

import static io.restassured.RestAssured.given;
import io.restassured.specification.ProxySpecification;

var proxy = ProxySpecification.host("proxy.example")
    .withPort(8080)
    .withScheme("http")
    .withAuth(proxyUser, proxyPassword);

var request = given().proxy(proxy);

The application supplies proxyUser and proxyPassword from its normal credential source. The fragment builds a request specification; invoke the intended API URL through request using the test’s normal request and assertion code.

The http scheme describes the proxy endpoint. The API URL can remain HTTPS. REST Assured’s withAuth mechanism supplies Basic proxy authentication; it does not negotiate every corporate authentication scheme merely because two strings were provided.

Place API credentials in the API’s own authentication configuration. Avoid substituting a general Authorization header or a service password for the proxy account. For HTTPS, authentication to the intermediary can be needed while establishing CONNECT, before the destination’s HTTP exchange exists.

When the remaining failure is certificate trust

A rejected CONNECT challenge and a TLS certificate validation error are different results. If the required organization-managed CA is missing from the client’s trust arrangement, obtain that CA through the approved administrative channel and configure the test client’s truststore.

REST Assured exposes trustStore for that purpose. A truststore changes which issuers the HTTPS client trusts; it does not choose the proxy or provide its login. Keep hostname and certificate validation enabled rather than using an accept-all handshake to collect whatever certificate happens to be presented.

Related articles