support standalone process with keystore/truststore type

[aklemp]

• Which version of WireMock you're using
  Wiremock 2.19.0
• How you're starting and configuring WireMock, including configuration or CLI the command line
  Started in Docker (https://hub.docker.com/r/rodolpheche/wiremock/) which is just bundling Wiremock in the standalone mode. The following arguments are used:
  --https-port 8443 --https-keystore /home/wiremock/keystore.p12 --global-response-templating --verbose
• A failing test case that demonstrates the problem
  As shown in the configuration above, I'm using a keystore in PKCS12 format for various reasons (default in Java 9, Java keytool warnings when using JKS, consistency with other services I use). However, the HTTPS endpoint is only working when giving a keystore in JKS format. I also think to have found the cause.
  When using the WiremockRule, the keystore and truststore types can be passed programmatically: https://github.com/tomakehurst/wiremock/blob/2.19.0/src/main/java/com/github/tomakehurst/wiremock/core/WireMockConfiguration.java#L349
  This is simply missing in the configuration for the standalone mode: https://github.com/tomakehurst/wiremock/blob/2.19.0/src/main/java/com/github/tomakehurst/wiremock/standalone/CommandLineOptions.java#L240
  I don't have a clue why this could be on purpose so it seems to be a bug.
• Profiler data if the issue is performance related

[tomakehurst]

I'll mark this as a feature request.

The reason we never bothered putting it in the CLI is that for a while the only practical reason to change it from the default was embedded Android testing.

[tomakehurst]

Happy to accept a PR if you need this at all quickly.

[aklemp]

Unfortunately, while testing the pull request, I noticed that this alone is not supporting PKCS12 as keystore. In addition the keystore password is required as described in #807. Temporarily setting the password in JettyHttpServer allows using a PKCS12 keystore. As described in the issue, it would break backwards compatibility so I haven't included that change in this PR.

[tomakehurst]

Sorry for the long delay on this.

Is it not sufficient to use the existing --keystore-password and --truststore-password parameters with a type of PKCS12?

[aklemp]

When I last tested this, it was not sufficient because it is not propagated in the JettyHttpServer.

[tomakehurst]

Ah yes, it's calling setKeyManagerPassword(), not setKeyStorePassword(). I honestly can't remember why I did it that way, but it's not very intuitive.

I think this is a rare case where a breaking change might be the best way forward, adding support for both a key store and key manager password as separate config parameters (switching --keystore-password so that it actually ends up calling setKeyStorePassword()).

Would you be willing to add this to your PR?

[aklemp]

Ok. I'm on it. Implementation seems to be done but I still have to test it in the next few days.

[aklemp]

Updated the pull request. But I have no idea where to document that it contains the breaking change.

[phillbarber]

Perhaps the breaking change could be documented in the release notes? It would be great if this could be merged. I was almost about to start working on a fix for https://github.com/tomakehurst/wiremock/issues/807 when I realised that this fixes it. Thanks @aklemp for addressing this.