Mocking HTTP Services with WireMock – Part 2

By | March 3, 2018

In this second article on HTTP testing with WireMock and REST Assured I will show how to set up a HTTPS mock service, with and without mutual authentication, using WireMock and then use REST Assured as a HTTP client to send requests to the service.

I highly recommend reading the first article if you haven’t already.


I am assuming that you have the example project from the first article ready. If not, you can also find the completed example on GitHub.

Creating a Keystore and Truststore

If your example project does not contain keystores and truststores for the client and server (located in the client and client/server directories in the project root directory) you need to create these keystores and truststores using the script below before being able to proceed with the HTTPS examples.
If you are using an operating system that does not have a Bash shell, open a terminal window, go to the root directory of the example project created above and run the commands in the script one by one. Some commands may need to be adapted to the environment in question.

  • In the project root directory, create a file named “” with the following contents:

  • Open a terminal window.
  • Go to the example project’s root directory.
    In my case this means that I am standing inside the “wiremock-test” directory.
  • Make the script executable using the following command:
    chmod +x
  • Launch the script using the following command:
    When asked to enter and re-enter the keystore password, enter “secret” without quotes.
    When asked whether to trust this certificate, enter “yes” also without quotes.

HTTPS without Client Authentication

Using HTTPS without client authentication is very straightforward with both WireMock and REST Assured. In the example below I have used a JUnit rule to create the WireMock service.

Note that:

  • There is a public instance variable named mWireMockRule of the type WireMockRule and annotated with the @Rule annotation.
    As before, this is the JUnit rule that will setup and start the WireMock server before each test method and also stop it after each test method.
  • When setting up the WireMock server, a HTTPS port is configured using the httpsPort method.
  • Again when setting up the WireMock server, a keystore and a keystore password are configured using the keystorePath and keystorePassword methods.
    When using HTTPS without mutual authentication, configuring a keystore is sufficient on the server side.
  • In the method successfulNoClientAuthTest the WireMock server is configured to expect a GET request to the standard path used in these examples that contain the HTTP header Accept with the text/plain value.
    Having received such a request, WireMock will return a plaintext response containing a greeting.
  • When preparing the request to be sent by REST Assured, the method relaxedHTTPSValidation is invoked.
    Using relaxed HTTPS validation, REST Assured will trust all hosts regardless of whether their certificates are valid or not. In fact, this method removes the need to configure a keystore.
  • When preparing the request, the method keyStore is used to set the client keystore and keystore password.
    As before, this is not strictly necessary when having relaxed HTTPS validation, nevertheless I wanted to include this in my example since I most often have valid test-certificates I can use in my tests.
  • Finally, the response is validated and logged as we have seen in the earlier examples.

When run, the example/test should pass yielding the following lines of log output in the console:

If you want to debug the SSL handshake or just look at the details of a successful SSL handshake, add the following flag to the Java VM options of your test launch-configuration:

HTTPS with Mutual Authentication

HTTPS with mutual authentication seemed impossible at first, until I realized that REST Assured probably contain a bug related to keystore/truststore configuration. I have not investigated this further but I did find a way to work around the issue by using a custom SSL socket factory.
Regretfully, a side-effect of the workaround is an additional 200 lines of code.

Note that:

  • The WireMock server is created, started and stopped programmatically.
    This is not necessary, you could just as well use a JUnit rule like in the previous example but I wanted to show that it is a feasible option.
  • When the WireMock server configuration is created, the needClientAuth method is called with a boolean true as parameter.
    This enables mutual authentication with HTTPS on the server side.
  • When the WireMock server configuration is created, a keystore and truststore and their corresponding passwords are set.
    HTTPS mutual authentication require both a keystore and a truststore.
  • In the test/example method successfulWithClientAuthRestAssuredTest the WireMock server is configured to expect a GET request to the usual path, with the Accept header having the text/plain value.
    As in the previous example, WireMock will respond with a plaintext body containing a greeting.
  • Before using REST Assured to send the test-request to the server, a SSL socket factory is created.
    We’ll get back to the SSL socket factory creation in a little while, let me just finish examining the test-method.
  • The class SSLSocketFactory is deprecated.
    SSLConnectionSocketFactory should be used instead. Regretfully REST Assured only accepts a socket factory of the former type.
  • REST Assured is used to send a request to the WireMock server.
    If REST Assured had worked as advertised, we should have used the following code to send the test-request. Instead we have to configure REST Assured to use the SSL socket factory just created.

  • The remainder of the test-method is spent logging and verifying the response as we have seen in the previous examples.
  • There is a method named createNewClientSSLSocketFactory which creates a SSL socket factory.
    I included this method in the case REST Assured is updated to use the newer socket factory.
  • There is a method named createOldClientSSLSocketFactory which creates a SSL socket factory of the old, deprecated, type.
    Both methods that create SSL socket factories configure the factory to have a keystore and a truststore and not to verify the name in the certificate against the hostname.
  • Finally there are methods to create client key and trust managers and methods that loads the client keystore and truststore.

When run, the test should pass and a few lines similar to what we have seen in earlier examples should be logged to the console:

Final Words

The WireMock project was started back in 2011 and I do get the feeling that it is a mature piece of software. WireMock is very nice and seem to have all the features that I could wish for in a HTTP mock server. The one drawback I have found with WireMock is the total lack of documentation in the source-code and the fact that I haven’t been able to find any JavaDoc, which given the otherwise high standard, I find very surprising.
The examples in this article have but scratched on the surface, there are many more features available in WireMock!

Happy coding!


One thought on “Mocking HTTP Services with WireMock – Part 2

Leave a Reply

Your email address will not be published.