3

This is a long shot, but has anyone here gotten Ready Shipper 7.3 working with a Magento SOAP HTTPS (that's S, as in secure) endpoint? If so, how?

That is, I've downloaded the ReadyShipper 7.3 desktop client for OS X. I can connect this desktop client to local Magento servers running over HTTP. However, if I try to connect to an HTTPS endpoint, the UI says my credentials are invalid.

I know my credentials are correct. I can make connections to this SOAP endpoint using PHP's SOAP client, and do so from my local machine to a remote endpoint, so I know the problem isn't networking related.

When I check ReadyShipper's logs, I see the following added when the application attempts to connect to my SOAP endpoint

javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair
    at org.apache.axis.AxisFault.makeFault(AxisFault.java:101)
    at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:154)
    at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
    at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)

My assumption is there's something in ReadyShipper's HTTPS connecting code that prevents it from working. I've added logging to Magento's index.php bootstrap (which routes all requests), and nothing is logged when the ReadyShipper application should be requesting the SOAP WSDL, and making a SOAP request. (this logging works for non-secure HTTP endpoints)

Short of turning off HTTPS (which is a non-starter) is there anything I can do on my end (i.e. I control the Magento server, not the application) to fix this?

(yes, I'm escalating with vendor support -- just covering my bases here)

2
  • 1
    Are you using a self signed certificate? Some applications tend to be very finicky when it comes to working with self-signed certs (in this case you might be dealing with java's keystore). You could also log all network requests on your system to try and monitor the network communication. I'd start by giving Charles proxy a shot then wireshark or tcpdump.
    – beeplogic
    Oct 10, 2014 at 16:51
  • @beeplogic Proper, valid cert's in use, but that's always a good thing to check. Connecting through a proxy fails as well with the same handshake error. I'm 99% convinced that the application can't even start the request (but a lot happens in that 1%) Oct 10, 2014 at 16:53

1 Answer 1

2

ReadyShipper is a Java application and Java is finicky about SSL. Java 6, which is the standard installed on a Mac, has a Diffie-Hellman key size limit of 1024 bits, but your server wants to use a larger one.

Try some of the solutions listed in the Apache documentation: Why do I get handshake failures with Java-based clients when using a certificate with more than 1024 bits?

Java 8 might resolve this situation whenever it becomes the standard version on the Mac.

Update: Alan here, updating this answer with the solution I cam up for with an nginx server.

In nginx's ssl.conf file, there's a

ssl_dhparam /etc/nginx/ssl.d/dh_param.pem

configuration entry. This is the Diffie-Hellman key. This key is not your public or private key, it's a key used in the SSL handshake. Java can't talk to an SSL server if this key is over 1024 bits. I needed to regenerate this file with the following command.

openssl dhparam -outform PEM -out /etc/nginx/ssl.d/dh_param_1024.pem 1024

And then change the nginx configuration to point at this file.

This will make your server "less" secure. My recommendation for users finding this page and thinking about create a smaller key would be

  1. Talk to a security expert

  2. If you must do it, don't do it for your public facing website. Do it for a website with an IP and/or password restriction so that only the computers that need to talk to your less secure server can.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.