Dropwizard SSL service keep on returning error - Server aborted the SSL handshake

Question

When I try to connect to my server remotely I get the following error.

$ curl -k --verbose https://myserver.com:9010/test
* Adding handle: conn: 0x7f8bfb801a00
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7f8bfb801a00) send_pipe: 1, recv_pipe: 0
* About to connect() to myserver.com port 9010 (#0)
*   Trying <myserver ip>...
* Connected to myserver.com (myserver ip) port 9010 (#0)
* Server aborted the SSL handshake
* Closing connection 0
curl: (35) Server aborted the SSL handshake

However, if I run this very command from within the server where the service is running then the connection completes successfully.

I am using a self-signed certificate. I used the guide at codeproject.com to create my certificate. And my Dropwizard server config is:-

server:
    requestLog:
        timeZone: UTC
        appenders:
        - type: file
          currentLogFilename: logs/requests.log
          archivedLogFilenamePattern: logs/requests-%d.log
          archivedFileCount: 3
          threshold: ALL
    applicationConnectors:
    - type: https
      port: 9010
      keyStorePath: myserver.keystore
      keyStorePassword: password
      certAlias: myserverAlias
      validateCerts: false
      trustStorePath: /etc/pki/java/cacerts
    adminConnectors:
    - type: https
      port: 9011
      keyStorePath: myserver.keystore
      keyStorePassword: password
      certAlias: myserverAlias
      validateCerts: false
      trustStorePath: /etc/pki/java/cacerts

Also I see no error in the logs.

Additional details

The successful connection from within the server looks like this.

$  curl -k --verbose https://myserver.com:9010/test
*   Trying <myserver ip>...
* Connected to myserver.com (myserver ip) port 9010 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* skipping SSL peer certificate verification
* SSL connection using TLS_DHE_DSS_WITH_AES_128_CBC_SHA
* Server certificate:
*   subject: CN=myserver.com,OU=TECH,O=AppleGrew,L=HYD,ST=TS,C=IN
*   start date: Apr 05 06:16:32 2015 GMT
*   expire date: Apr 04 06:16:32 2018 GMT
*   common name: myserver.com
*   issuer: CN=myserver.com,OU=TECH,O=AppleGrew,L=HYD,ST=TS,C=IN
> GET /test HTTP/1.1
> User-Agent: curl/7.40.0
> Host: myserver.com:9010
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Mon, 06 Apr 2015 06:01:23 GMT
< Content-Type: application/json
< Vary: Accept-Encoding
< Content-Length: 99
< 
* Connection #0 to host myserver.com left intact
{"status":"OK","message_type":"INFO","message_recipient":"SYSTEM","testMsg":"The service is live!"}

However, the version of curl running server-side and remote client-side are different.

Server-side it is:

curl 7.40.0 (x86_64-redhat-linux-gnu) libcurl/7.40.0 NSS/3.16.2 Basic ECC zlib/1.2.8 libidn/1.18 libssh2/1.4.2
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz UnixSockets

Client-side it is:

curl 7.30.0 (x86_64-apple-darwin13.0) libcurl/7.30.0 SecureTransport zlib/1.2.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp 
Features: AsynchDNS GSS-Negotiate IPv6 Largefile NTLM NTLM_WB SSL libz 

Update

I was able to connect to the server from a remote Linux system. The curl version on that system is:-

curl 7.19.7 (i686-pc-linux-gnu) libcurl/7.19.7 NSS/3.12.6.2 zlib/1.2.3 libidn/1.18 libssh2/1.2.2
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp 
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

Solution

Just a guess because your question lacks the necessary details:

• you have a different version of curl on your client and on the server
• your server setup triggers any of the differences between your curl versions, like:
  • support for RC4 disabled in newer versions
  • support for SSL 3.0 disabled in newer versions
  • no ciphers overlap
  • ...

To get more help you should provide the versions and SSL stacks of curl you are using (curl -V), server side settings and maybe debug output (curl -v) for successful and unsuccessful connections.

• Server aborted the SSL handshake

Because of this you should also have a look at the logs on the server side. It might even be that a firewall is blocking the connections, so you might check if the server gets he connection at all.