Making HTTPS Calls to Untrusted SSL Servers With REST Assured

Last updated: September 18, 2025

Written by: Graham Cox

Reviewed by: Liam Williams

Refactor Java code safely — and automatically — with OpenRewrite.

Refactoring big codebases by hand is slow, risky, and easy to put off. That’s where OpenRewrite comes in. The open-source framework for large-scale, automated code transformations helps teams modernize safely and consistently.

Each month, the creators and maintainers of OpenRewrite at Moderne run live, hands-on training sessions — one for newcomers and one for experienced users. You’ll see how recipes work, how to apply them across projects, and how to modernize code with confidence.

Join the next session, bring your questions, and learn how to automate the kind of work that usually eats your sprint time.

Regression testing is an important step in the release process, to ensure that new code doesn't break the existing functionality. As the codebase evolves, we want to run these tests frequently to help catch any issues early on.

The best way to ensure these tests run frequently on an automated basis is, of course, to include them in the CI/CD pipeline. This way, the regression tests will execute automatically whenever we commit code to the repository.

In this tutorial, we'll see how to create regression tests using Selenium, and then include them in our pipeline using GitHub Actions:, to be run on the LambdaTest cloud grid:

>> How to Run Selenium Regression Tests With GitHub Actions

In this tutorial, we'll see how to create regression tests using Selenium, and then include them in our pipeline using GitHub Actions:, to be run on the LambdaTest cloud grid:

>> How to Run Selenium Regression Tests With GitHub Actions

1. Introduction

In this article, we’ll take a look at using REST Assured to make HTTPS calls to HTTPS server URLs. In particular, we’ll see how to write tests when our system doesn’t trust the server’s SSL certificate. For example, because it’s a self-signed certificate.

2. Failing Tests With Untrusted SSL Certificates

We can use REST Assured to make calls to our server as follows:

given()
    .baseUri("https://self-signed.badssl.com")
.when()
    .get("/")
.then()
    .statusCode(200);

When we’re testing a non-HTTPS URL or a URL with a valid SSL certificate, a test like this will work perfectly fine.

However, if we’re testing an HTTPS URL that has an untrusted SSL certificate, REST Assured will throw an exception:

javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:130)
	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:378)
	... 57 more
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:388)
	at java.base/sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:271)
	... 123 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:148)
	at java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:129)
	... 126 more

In many cases, this is desirable behaviour. If we’re running tests against a website with a bad SSL certificate, we normally want the test to fail.

However, in some cases, we need to be able to test such sites. For example, we might be testing a pre-release version of our application that doesn’t have a valid certificate yet.

3. Relaxed HTTPS Validation

The easiest way to solve this issue is to enable relaxed HTTPS validation on our test calls. We can do this by including the call relaxedHTTPSValidation() in our call chain:

given()
    .relaxedHTTPSValidation()
    .baseUri("https://self-signed.badssl.com")
.when()
    .get("/")
.then()
    .statusCode(200);

This is a shorthand for providing SSL config that has relaxed validation enabled:

given()
    .config(config().sslConfig(sslConfig().relaxedHTTPSValidation()))
    .baseUri("https://self-signed.badssl.com")
.when()
    .get("/")
.then()
    .statusCode(200);

This is very simple and may well be all that we need. However, we need to be aware that this will accept any SSL certificate for our call, regardless of the reason it’s invalid. This includes if it’s untrusted, but also things such as if it’s expired or even if it’s defined for the wrong domain. It will also accept any SSL certificate for any website, not just the one that we’re interested in.

4. Trusting Certificates

Instead of configuring our client to just accept any SSL certificate, the alternative is to provide the actual SSL certificate for our website. This will allow us to trust the certificate, but without the extra baggage that comes with it – trusting other certificates too, and accepting certificates that are otherwise invalid.

4.1. Creating a Truststore

The first thing we need to do is create a Java Truststore containing the appropriate certificate.

We first need to get a copy of the certificate. We can download this directly from the server using the openssl command-line tool:

$ echo -n | openssl s_client -connect self-signed.badssl.com:443

The output of this will include, amongst a lot of other details, the actual certificate. We can find this between “—–BEGIN CERTIFICATE—–” and “—–END CERTIFICATE—–” lines:

We then need to write this into a file – for example, badssl.crt. Once we’ve done that, we can create a Java keystore from it:

$ keytool -import -trustcacerts -keystore badssl.jks -storepass changeit -noprompt -alias badssl -file badssl.crt

Certificate was added to keystore

This creates a file called badssl.jks with a password of changeit, in which we’ve stored the certificate found in badssl.crt.

Once we’ve done this, we should then verify the keystore to make sure it’s correct:

$ keytool -list -v -keystore badssl.jks -storepass changeit
Keystore type: PKCS12
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: badssl
Creation date: 12 Sept 2025
Entry type: trustedCertEntry

Owner: CN=*.badssl.com, O=BadSSL, L=San Francisco, ST=California, C=US
Issuer: CN=*.badssl.com, O=BadSSL, L=San Francisco, ST=California, C=US
Serial number: f52240328cae72f7
Valid from: Tue Sep 09 22:00:26 BST 2025 until: Thu Sep 09 22:00:26 BST 2027
Certificate fingerprints:
	 SHA1: 9C:F3:00:1D:37:04:A9:3D:94:0E:24:0D:72:72:4E:F6:1B:D8:86:2E
	 SHA256: CE:1F:57:5F:E6:4E:D2:D5:18:8B:B4:05:DD:D8:AE:E1:1A:00:18:35:FD:F5:1A:3C:6F:54:CC:43:65:96:C9:54
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3

At this point, we’re ready to use the certificate in our tests.

4.2. Using the Truststore per Request

We can configure REST Assured to use our truststore for a single request. We do this in a very similar way to how we enabled relaxed HTTPS validation. We provide an SSL config which knows about the truststore:

given()
    .config(config().sslConfig(sslConfig().trustStore("/badssl.jks", "changeit")))
    .baseUri("https://self-signed.badssl.com")
.when()
    .get("/")
.then()
    .statusCode(200);

Our badssl.jks file needs to be in the appropriate place on the classpath, and changeit is the store password that we defined earlier.

At this point, our test will pass correctly for any certificates in this truststore, but reject any others that are invalid.

4.3. Using the Truststore Globally

Instead of configuring the truststore on each individual request, we can configure REST Assured to globally support our truststore:

RestAssured.config = RestAssured.config().sslConfig(SSLConfig.sslConfig().trustStore("/badssl.jks", "changeit"));

This is the exact same configuration that we used before, but we’re updating the global configuration instead of specifying it on the single request. From this point on, all requests that we make will know about this truststore, and therefore will trust this SSL certificate:

given()
    .baseUri("https://self-signed.badssl.com")
.when()
    .get("/")
.then()
    .statusCode(200);

Here we’re doing nothing specific to trust the SSL certificate, but this time the test will pass. This is because the global configuration already knows about our truststore, and so the system trusts this certificate on every REST Assured call we make.

5. Summary

In this article, we looked at how to configure REST Assured to accept untrusted SSL certificates. This allows us to test websites that might be using self-signed or otherwise invalid certificates. Next time you need to test websites like this, why not give it a go?

The code backing this article is available on GitHub. Once you're logged in as a Baeldung Pro Member, start learning and coding on the project.