0

MobileFirst 7.1.0.00-20150807-0630 Java 1.7.0_80

I have a Java adapter that connects to a backend service using REST. at macm.saas.ibmcloud.com:443. All works fine from a Development server. But when I deploy it to a production server (both on-prem and a Bluemix Container), I get the following error when the adapter attempts to connect to the server:

javax.net.ssl.SSLHandshakeException: No negotiable cipher suite

I would think the problem is related to how the keystore is configured, but I don't understand why it would be different on a prod server than the dev server.

Running openssl s_client -connect macm.saas.ibmcloud.com:443 gives me:

> CONNECTED(00000003)
depth=2 /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/C=US/ST=New York/L=Armonk/O=International Business Machines Corporation/CN=macm.saas.ibmcloud.com
   i:/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA
 1 s:/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
 2 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGWzCCBUOgAwIBAgIQATFWvLyURadTLNafH0mf0zANBgkqhkiG9w0BAQsFADBN
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMScwJQYDVQQDEx5E
aWdpQ2VydCBTSEEyIFNlY3VyZSBTZXJ2ZXIgQ0EwHhcNMTUxMDA3MDAwMDAwWhcN
MTgxMDExMTIwMDAwWjCBiDELMAkGA1UEBhMCVVMxETAPBgNVBAgTCE5ldyBZb3Jr
MQ8wDQYDVQQHEwZBcm1vbmsxNDAyBgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5l
c3MgTWFjaGluZXMgQ29ycG9yYXRpb24xHzAdBgNVBAMTFm1hY20uc2Fhcy5pYm1j
bG91ZC5jb20wggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCrxABCsOK4
8j1lshwGxBWJSVXSR1sM4PvyLo0v2p7LMVmsX81jWV67P6+NxvnfQFRr4WqpUbxZ
SPtx37ykO9Non4dFry6USvt22RwA31yveSlpzKaicdZqK8zr5DiQs5SSGvt+6tHb
KgNjwPRWjphaT6C3V2s1yUfwPSQvcrnv9jIgx3dvpFgfJ4SyJ8cBxyGZnp1MsVZX
4hgNgLeFRXdoq6708leLPI9x/f+uQvzUqPZqPOIz3piUzncCSQVE9WkGAQkU2BCe
9xR9hFuIcPgHoiEfHozHPOcg/fKChWwSb3FBJIVOXvoVSPADnzNxqSOA84B3PYNP
T9iJ7Mu5qSOMZLo+JBknKQXUdTxh/yUw0E2QikkgE1DBOSjnVPTNgqveR/CHr67N
1S/pvXVpYUAxmfxt2XFc9Qqo7cMJDTBvoR/93tkIUOevyAhcLbkS8QH+Yn/u7WWp
1h13OtYudtnPDUAElRrf5nty2j01u6uH7jF/ZkMeZbNjjV56Rrwh3uWwe05fgRGV
MeTEc4ccq9b/BUb5K0BCI0AFd2B2ZYOqOnfnvKuQybIrUNpHf+A5su6mzM14FdQY
lJ6vXRa7rzKT4/UH3xiYf7qzpi3h3iBFJ9EcEk6F1W+9I/X6bfbXqjJU8QHGWpYR
ceMXdKLZWuLxQC3+g7pqep5bGjxGye1LGwIDAQABo4IB+TCCAfUwHwYDVR0jBBgw
FoAUD4BhHIIxYdUvKOeNRji0LOHG2eIwHQYDVR0OBBYEFE8uz2MkSduo1sHr/F43
PRBkscnPMD0GA1UdEQQ2MDSCFm1hY20uc2Fhcy5pYm1jbG91ZC5jb22CGnd3dy5t
YWNtLnNhYXMuaWJtY2xvdWQuY29tMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAU
BggrBgEFBQcDAQYIKwYBBQUHAwIwawYDVR0fBGQwYjAvoC2gK4YpaHR0cDovL2Ny
bDMuZGlnaWNlcnQuY29tL3NzY2Etc2hhMi1nNC5jcmwwL6AtoCuGKWh0dHA6Ly9j
cmw0LmRpZ2ljZXJ0LmNvbS9zc2NhLXNoYTItZzQuY3JsMEwGA1UdIARFMEMwNwYJ
YIZIAYb9bAEBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv
bS9DUFMwCAYGZ4EMAQICMHwGCCsGAQUFBwEBBHAwbjAkBggrBgEFBQcwAYYYaHR0
cDovL29jc3AuZGlnaWNlcnQuY29tMEYGCCsGAQUFBzAChjpodHRwOi8vY2FjZXJ0
cy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyU2VjdXJlU2VydmVyQ0EuY3J0MAwG
A1UdEwEB/wQCMAAwDQYJKoZIhvcNAQELBQADggEBAIWJCItCBT0mE53OjwMdJsq0
nGgrMfb7LbF+5exdtqqaKyq8Zuke3yEbFv4nRg3LUcmh8HMLn8gSDTCnVRH0BCLx
OBmxgRVRm7eXTVSiE8tbdMOHbUEdu96MUSppSCW8CfLMAr3kPnyMWlCPgg215fn2
72CM6m3n9AKEJXcwFRmhriNiSsVeKlTqW+5efqHUig8QOmzqJTo03M2gH/jRY1Au
Dr2nPzyVYxoztBWtlC1ECfSCUbiF0URYXCJbI+UbyQCB8C+k+ikn5H/95Ingvg2v
pmLquKDFH9iH022wA/UaVeQ+AqzXcEQZgfEq+U4ZQNIRJ+ae5KDFwQS+E7OpmR4=
-----END CERTIFICATE-----
subject=/C=US/ST=New York/L=Armonk/O=International Business Machines Corporation/CN=macm.saas.ibmcloud.com
issuer=/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA
---
No client certificate CA names sent
---
SSL handshake has read 3919 bytes and written 712 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES128-SHA
    Session-ID: 21D5000057760A8FE4AB39A6388838B6F38A523A58585858079454560000F4B0
    Session-ID-ctx: 
    Master-Key: 82C926729FA56D9FD83E357C3B6FD372D587D73E8FC28E3721BE053A4CD6CDA45949AD4F03EF2759DEE882B1FFEF257E
    Key-Arg   : None
    Start Time: 1448383495
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
DSchultz_mo
  • 143
  • 1
  • 1
  • 8
  • What do you mean by "a development server" and "a production server"? Are these just different server environments that you have? Are you referring to the development server used by the MFP CLI/MFP Studio? – Andrew Ferrier Nov 24 '15 at 17:30
  • Have you checked the JDK version(s) used by all three servers? Normally SSL checking is a JDK-level concept. – Andrew Ferrier Nov 24 '15 at 17:31
  • Yes, by "a development server", I mean the "MobileFirst Development Server" provided with, in my case, Studio and by "a production server", I mean an MobileFirst Platform Server installed in an instance of Liberty. The JDK used by the development server is Oracle 1.7.0_80. Bluemix Containers run the IBM jre 1.7-3.10. I have also tried a production server running Oracle jdk 1.8.0 (jdk8u51-b15). – DSchultz_mo Nov 24 '15 at 17:50
  • OK, thanks for clarifying. I tend not to use that terminology, it's more confusing than not, since most real-world scenarios have a "development server" which is actually a full production server install. – Andrew Ferrier Nov 24 '15 at 17:58
  • Reading the error more carefully, I would guess that part of the problem here is the self-signed certificate that's being used: `verify error:num=19:self signed certificate in certificate chain`. Normally that would require you to bypass SSL cert checking in some way, although admittedly I can't explain why that would behave differently in the MFP development server. – Andrew Ferrier Nov 24 '15 at 18:00
  • I think the self-signed certificate message is a red herring - see: http://stackoverflow.com/questions/4103472/ssl-handshake-fails-with-a-verisign-chain-certificate-that-contains-two-ca-s. The error mentioned originally in the question indicates that the client and server aren't able to agree on a cipher to use. – patbarron Nov 24 '15 at 18:19
  • My next step here would be to add (on the Liberty server) a trace specification for "SSL=all:SSLChannel=all", and add "-Djavax.net.debug=ssl" in the jvm.options file, restart the server, and then look in the logs to see what happens during the SSL negotiation. – patbarron Nov 24 '15 at 18:24
  • @DSchultz_mo, any progress here? – Idan Adar Jan 07 '16 at 23:23
  • I eventually rewrote the Java connection code using a different set of libraries that worked for an app written by another team. I never did determine what it was about my code that did not work, but it appears to have been specific to the way I attempted to implement it. – DSchultz_mo Jan 12 '16 at 16:38
  • Can you provide the above as an Answer? – Idan Adar Feb 19 '16 at 13:02
  • Well, it isn't much of an answer but I guess it is something – DSchultz_mo Feb 20 '16 at 14:37

1 Answers1

0

I eventually rewrote the Java connection code using a different set of libraries that worked for an app written by another team. I never did determine what it was about my code that did not work, but it appears to have been specific to the way I attempted to implement it.

DSchultz_mo
  • 143
  • 1
  • 1
  • 8