4

I am trying to send a SOAP request by CFHTTP with a client certificate. My test requests in SOAP UI are successful but when I try to send requests by CFHTTP I get the following error:

I/O Exception: Received fatal alert: handshake_failure

My CFHTTP tag is like this:

<cfhttp
    url="https://..."
    method="post"
    clientcert="C:\..."
    clientcertpassword="password"
    result="httpResponse"
    >

I have tried to check the logs for more ideas of where the failure could be happening. I can only get the following:

http.log

"Information","ajp-bio-8014-exec-10","09/26/16","07:07:59",,"Starting HTTP request {URL='https://...', method='post'}"

coldfusion-out.log

Sep 26, 2016 07:07:59 AM Information [ajp-bio-8014-exec-10] - Starting HTTP request {URL='https://...', method='post'}

I have imported the certificates with keytool and when I list the certificates in cacerts I see them there.

Any other ideas where I can look to troubleshoot this issue?

Edited to add:

My certificate is in .p12 format and has a password. I have tested the .p12 file with the password in SOAP UI and it works.

I have installed CF10-Certman and confirmed the certificates are there from CF Administrator as well.

I've added these lines to my jvm.config:

-Djavax.net.ssl.keyStore=C:\\ColdFusion11\\jre\\lib\\security\\cacerts 
-Djavax.net.ssl.keyStorePassword=password 
-Djavax.net.ssl=debug
-Djavax.net.debug=all

I tried the keystore path with \ and / ("C:/Coldfusion11/...")

Additional coldfusion-out.log output:

Sep 26, 2016 11:10:06 AM Information [ajp-bio-8014-exec-2] - Starting HTTP request {URL='https://...', method='post'}
...
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
...
Allow unsafe renegotiation: true
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
%% No cached client session
*** ClientHello, TLSv1
RandomCookie:  GMT: 1458128991 bytes = { 40, ... }
Session ID:  {}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_RC4_128_MD5, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods:  { 0 }
Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2, secp192r1, secp224r1, sect233k1, sect233r1, sect283k1, sect283r1, secp384r1, sect409k1, sect409r1, secp521r1, sect571k1, sect571r1, secp160k1, secp160r1, secp160r2, sect163r1, secp192k1, sect193r1, sect193r2, secp224k1, sect239k1, secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Extension server_name, server_name: [host_name: url ]
***
ajp-bio-8014-exec-2, WRITE: TLSv1 Handshake, length = 195
ajp-bio-8014-exec-2, READ: TLSv1.1 Alert, length = 2
ajp-bio-8014-exec-2, RECV TLSv1 ALERT:  fatal, handshake_failure
ajp-bio-8014-exec-2, called closeSocket()
ajp-bio-8014-exec-2, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
Finalizer, called close()
Finalizer, called closeInternal(true)

The CipherSuite in SOAPUI is TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

UPDATE

I removed the clientcert and clientcertpassword from the cfhttp tag and now I am seeing this in coldfusion-out.log:

ajp-bio-8014-exec-1, WRITE: TLSv1.1 Handshake, length = 64
ajp-bio-8014-exec-1, setSoTimeout(360000) called
ajp-bio-8014-exec-1, WRITE: TLSv1.1 Application Data, length = 1680
ajp-bio-8014-exec-1, READ: TLSv1.1 Alert, length = 48
ajp-bio-8014-exec-1, RECV TLSv1.1 ALERT:  warning, close_notify
ajp-bio-8014-exec-1, called closeInternal(false)
ajp-bio-8014-exec-1, SEND TLSv1.1 ALERT:  warning, description = close_notify
ajp-bio-8014-exec-1, WRITE: TLSv1.1 Alert, length = 48
ajp-bio-8014-exec-1, called closeSocket(false)
ajp-bio-8014-exec-1, called close()
ajp-bio-8014-exec-1, called closeInternal(true)

I have reached out to the server administrator to see if they are seeing the request on their end.

UPDATE

Adding the clientcert back in fixed it!

kelseyelayne
  • 115
  • 8
  • For refference please read [this](http://stackoverflow.com/questions/6132846/importing-first-data-certificate-into-coldfusion) and [this](https://forums.adobe.com/thread/1855047) – Leo the lion Sep 26 '16 at 13:04
  • @Leothelion I have read both of these posts. I have tried the suggestions mentioned. I will add my jvm.config to my original post. – kelseyelayne Sep 26 '16 at 13:54
  • Are you sure that is the correct keystore file in use by ColdFusion? Have you ever updated Java on that server? The ColdFusion administrator system information page will tell you the path in use under the "Java Home" label. Also have a look at [this](http://stackoverflow.com/a/6353956/1636917). – Miguel-F Sep 26 '16 at 14:28
  • @Miguel-F I show in CF Administrator the Java home is "C:\ColdFusion11\jre" and I added the certificates to cacerts located in C:\ColdFusion11\jre\lib\security – kelseyelayne Sep 26 '16 at 15:32
  • Then that should be the correct keystore for your installation. Check that link I referenced for other possibilities – Miguel-F Sep 26 '16 at 15:45
  • @Miguel-F Yes, I reviewed the rest of the suggestions as well. I figured out I had -Djavax.net.ssl=debug in the wrong place within jvm.config. I will add the SSL debug output to my original question but hopefully I can figure it out now that I have the additional information. Thank you. – kelseyelayne Sep 26 '16 at 15:49
  • @Miguel-F I think the issue may be the TLSv1 Handshake and the TLSv1.1 Alert I receive back. I am working on trying to change the protocol for the handshake. – kelseyelayne Sep 26 '16 at 17:01
  • Did you omit some information around the `ClientHello ...` line? As I understand it that line is supposed to notify the caller of the highest supported TLS/SSL version. In this case `TLSv1`. Just curious if there is any more relevant information where those `***` are in the message you posted here. – Miguel-F Sep 26 '16 at 17:05
  • @Miguel-F the asterisks "***" are actually in the log and I didn't omit a ClientHello line. I've tried editing server.xml and jvm.config (-Dhttps.protocols=TLSv1.1) to force SSL protocol TLSv1.1 but it keeps using TLSv1. The server administrator at the other end of this attempted connection pointed out the difference as well as a possible issue. – kelseyelayne Sep 26 '16 at 17:10
  • I'm thinking the opposite, the SOAP service appears to only accept TLS 1.0 (not TLS 1.1). I'm wondering if the version of Java that ships with ColdFusion 11 (version 8 I think) has disabled the older TLS 1.0 protocol. If so you will need to re-enable that version (or some such). – Miguel-F Sep 26 '16 at 17:24
  • @Miguel-F I went into "Configure Java" and tried different combinations of checked TLS versions (TLSv1.1, TLSv1.0 and TLSv1.2) and no matter what settings I choose the handshake is in TLSv1. I will see if changing the jvm.config and server.xml to TLSv1 will fix it. – kelseyelayne Sep 26 '16 at 17:34
  • I found the following but it may be a red herring. On [this page](https://blogs.oracle.com/java-platform-group/entry/java_8_will_use_tls) about half-way down under the **Other Considerations for TLS** section. _As is common with TLS implementations, Perfect Forward Secrecy is not enabled by default. Those that do want to use it can update their https.cipherSuites property. Common values for this property are_ TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (which happens to match the cipher suite you are attempting to use. – Miguel-F Sep 26 '16 at 17:40
  • @Miguel-F to make it even more confusing, the log shows TLSv1 but Wireshark shows TLSv1.1 – kelseyelayne Sep 26 '16 at 19:17
  • I think you are heading down the right path using Wireshark to see what is really happening. So is it the ColdFusion server attempting to use 1.1 or the endpoint? – Miguel-F Sep 26 '16 at 19:29
  • I just realized that you are specifying a `clientcert` with your `cfhttp` call. Is that pointing to a correct file? I have not used that attribute before. When omitted the tag will use the `cacerts` file of the current JVM by default. Have you tried the call without specifying the `clientcert` attribute? – Miguel-F Sep 26 '16 at 19:46
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/124247/discussion-between-kelseyelayne-and-miguel-f). – kelseyelayne Sep 26 '16 at 23:16
  • @Miguel-F I think that has helped! I updated my post to show what I'm now seeing in the logs. Thank you. – kelseyelayne Sep 26 '16 at 23:17
  • Sorry I have been offline. Looks like you have made some progress. Is it connecting successfully now? – Miguel-F Sep 27 '16 at 11:13
  • @Miguel-F I am getting the error: "I/O Exception: [host]:443 failed to respond". No response back from the server side yet. – kelseyelayne Sep 27 '16 at 14:32
  • @Miguel-F Adding the clientcert back in fixed it! Thanks again! – kelseyelayne Sep 27 '16 at 15:40
  • So it was an issue on the end point's side? Go ahead and post an answer to this question with the resolution details. That way it will be easier for other users to find it. Glad you got it working. – Miguel-F Sep 27 '16 at 15:43

1 Answers1

2

I am not sure what exactly fixed this issue overall but if you review my original post including updates the following things seemed to have contributed:

1) Not including clientcert caused ColdFusion to check cacerts for the server certificates

2) Re-adding clientcert caused ColdFusion to complete the handshake

The JVM.config settings also helped in debugging and ensuring the correct protocol was used.

kelseyelayne
  • 115
  • 8