[Play 2.3] Implementing client certificate for calling a 3rd-party API URL

[Nick Mayorga]

Hello,

So after reading a thousand different articles by our esteemed Mr Sargent and others, I still have a few lingering questions on how I am implementing this.

Basically, I have a 3rd-party API URL that is expecting a public client certificate. I am using a WS.url(testURL).post(Map("TokenId" -> Seq("token"))) to hit the URL in my controller. I am doing a simple map on the response to process it.

This particular operation is total one-off validation and has little to do with the rest of the application's internal workings, meaning that the SSL configuration I have set up should only be used for this one particular call and nothing else.

I've only set up the following so far (names changed to protect innocent):

play.ws.ssl {

    keyManager = {
      stores = [
        { type: "pkcs12", path: "conf/inventory/myKey.p12", password: "password"}
      ]
    }
    debug = {
        ssl = true
        certpath = true
        handshake = true
        keygen = true
    }

    default = false
    loose.allowWeakCiphers=true

}

My next question may sound silly, but there isn't a definitive answer anywhere that I've found: do I need to run activator while specifying -Dhttps.port=9443 to get these configs to take effect?

I had experienced that if I didn't specify the java -D opts on when running the app (mentioned here https://www.playframework.com/documentation/2.3.x/ConfiguringHttps),

when that route gets hit, an SSL handshake is attempted but nothing is given from my side, no keys found, no trust stores added, which then fails the handshake.

However, once I do run with -Dhttps.port=9001 (no other -D specifiers for keystore, etc) and again try to hit that route (preceeded by http://), I see a found key called 'playgenerated', my trust stores get added as trust certs, but the SSL handshake seems to hang before 

even before a ClientHello happens.My key from my new config still doesn't seem to be recognized, only the one gen'd by Play. 

If I change that route to use https://, my debug output starts getting weirdly unformatted, but the handshake at least gives it a go, however it looks like multiple handshakes happening at the same time.

And I see some of this towards the end of the log:

New I/O worker #3, Exception sending alert: java.io.IOException: writer side was already closed.
New I/O worker #6, SEND TLSv1.2 ALERT:  fatal, description = internal_error
New I/O worker #8, fatal error: 80: Inbound closed before receiving peer's close_notify: possible truncation attack?
javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?

If I break down and specify everything in my run statement as such: activator -Djavax.net.debug=ssl:handshake:data -Dhttps.port=9443 -Dhttps.keyStore=conf/inventory/myKey.p12 -Dhttps.keyStorePassword=password -Dhttps.keyStoreType=pkcs12 run

and hit my route once more, I do finally see my key found at the outset, trust stores get added, but then right at ClientHello time the output again looks like it's intiating multiple handshakes at the same time.

My initial handshake looks like it does find a 'matching alias' (magical words!) when I spelunk through the SSL output but that is somehow lost in a sea of other handshakes and doesn't seem to be used.

I've lost a lot of time trying to get this to work, and I have doubly confirmed with our client that the certs in my keystore are correct, also confirmed by that fleeting 'matching alias' that never seems to take.

I guess my biggest question(s) remains: 

  1) can I use the out-of-the-box configuration to get this done? Or does it seem like I would have to create a custom SSL client to hit this URL?

  2) could anyone point me towards a straight forward implementation of this?

     a) is it this? https://groups.google.com/forum/#!searchin/play-framework/incantation$20ssl|sort:relevance/play-framework/kIg5lV0mbvo/ZiNXq_z91RQJ

     b) or maybe this? https://tersesystems.com/2014/07/07/play-tls-example-with-client-authentication/

  3) is this an unsolvable issue in 2.3 given the various bugs I have seen talked about with regards to the Ahc implementation?

  4) am I just missing something small like another config?

  5) what could be causing multiple handshakes to all go off concurrently?

Any help is greatly appreciated, I am really reaching at this point and am not sure of a way through this!

Thanks,

Nick M

[Will Sargent]

You can use a one-off client with different configuration than the rest of the app:

https://github.com/wsargent/play-ws-with-letsencrypt

Here, we've got the main configuration, but we pull it in using a specialized client.

--

Will Sargent

Engineer, Lightbend, Inc.

will.s...@lightbend.com

--
You received this message because you are subscribed to the Google Groups "Play Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/2f5b2b8c-d112-4691-b600-e759d885f8b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.