Error calling Elastic Search over SSL due to "no cipher suites in common"

[dfinzer]

Bug report

Encountering an error when using Telegraf with an Elastic Search SSL plugin, despite being able to successfully curl the server from the host.

Relevant telegraf.conf:

[[inputs.elasticsearch]]
   ## specify a list of one or more Elasticsearch servers
   servers = ["https://admin:testing@localhost:9200"]

   ## set local to false when you want to read the indices stats from all nodes
   ## within the cluster
   local = true

   ## set cluster_health to true when you want to also obtain cluster level stats
   cluster_health = false

#   ## Optional SSL Config
#   # ssl_ca = "/etc/telegraf/ca.pem"
#   # ssl_cert = "/etc/telegraf/cert.pem"
#   # ssl_key = "/etc/telegraf/key.pem"
#   ## Use SSL but skip chain & host verification
    insecure_skip_verify = true

System info:

Telegraf - version 1.0.1, on mac

Steps to reproduce:

1. Spin up Elastic Search with SSL configured using the SearchGuard plugin
2. Verify that SSL is working by curling the server: curl -k https://admin:admin@localhost:9200
3. Launch Telegraf with the above config.

Expected behavior:

Actual behavior:

Telegraf encounters an error calling Elasticsearch

2016/11/10 15:56:10 ERROR in input [elasticsearch]: Errors encountered: [Get https://admin:testing@localhost:9200/_nodes/_local/stats: remote error: tls: handshake failure]

On Elasticsearch's side, we see the following error:

javax.net.ssl.SSLHandshakeException: no cipher suites in common
	at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1431)
	at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
	at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:813)
	at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781)
	at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
	at org.jboss.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1218)
	at org.jboss.netty.handler.ssl.SslHandler.decode(SslHandler.java:852)
	at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:425)
	at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:303)
	at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559)
	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
	at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88)
	at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:108)
	at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337)
	at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89)
	at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
	at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
	at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

[sparrc]

this is some sort of Oracle/OpenJDK Java politics issue, see #1126 & IBM/sarama#643