Support custom client certificates for Mutual Auth

I want to use my own client certs to test a service which uses Mutual Auth. So instead of only passing in the protocol, it would be neat to also specify a truststore + password. Something like this:

* configure ssl = { trustStore: 'classpath:security/trustStore.jks', password: 'secret', algorithm: 'TLSv1.2' }

or with a default jasypt encryption:

* configure ssl = { trustStore: 'classpath:security/trustStore.jks', password: 'ENC(ZqRBcxftoCD33dUPHX0liHvNH5xdfrUCmGw=)', algorithm: 'TLSv1.2' }

Currently in com.intuit.karate.http.HttpUtils:

    public static SSLContext getSslContext(String algorithm) {
        TrustManager[] certs = new TrustManager[]{new LenientTrustManager()};
        SSLContext ctx = null;
        if (algorithm == null) {
            algorithm = "TLS";
        }
        try {
            ctx = SSLContext.getInstance(algorithm);
            ctx.init(null, certs, new SecureRandom());
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
        return ctx;
    }

Retrieve SslContext with custom client cert(s):

    public static SSLContext getSslContext(URL trustStoreURL, char[] password, String algorithm) {
        SSLContextBuilder sslContextBuilder = new SSLContextBuilder();
        try {
            sslContextBuilder.loadTrustMaterial(trustStoreURL, password);
            sslContextBuilder.useProtocol(algorithm);
            return sslContextBuilder.build();
        } catch (GeneralSecurityException | IOException e) {
            throw new IllegalStateException("Error while creating SslContext", e);
        }
    }

[mattjm]

I’ll add a couple comments about SSL debugging from my years of experience supporting TLS mutual auth:

1. Don’t use Java keystores, use PKCS12. Java keystores require everything be done just perfectly in exactly the right order…and even then they won’t work half the time.

2. Trust path problems can also be caused by missing intermediate certificates (e.g. you trust the root cert, but the server isn’t presenting the intermediate certs in the trust path). You might also need to include intermediates with your client certificate (this is much easier with PKCS12 vs a java keystore).

3. (client debugging only) If you’re really stumped you can set up an Apache server, enable certificate authentication, set the logLevel very high, then point your HTTP client at the server. Obviously the Apache server won’t serve up what your client expects, but it will still try to handshake with the server and you can get really good information out of the debug logs.

4. (shouldn’t happen with Karate since it doesn’t use the Windows certificate keystore but I’ll mention it anyway) 9 times out 10 on Windows, handshake failures are because you’re missing a certificate’s private key or don’t have permissions on it.

[mattjm]

@jbadeau I will get rid of that fork–it worked but the current master upstream branch is far more polished. @ptrthomas has it taking a PKCS12 cert, which is easy enough to get from PEM using openssl (https://www.sslshopper.com/article-most-common-openssl-commands.html).

If you were interested in using the PEM code for something else, send email (email in my profile)–I think it’s a library I have somewhere.