I'm trying a set up a secure websocket in activemq using CA certs, but I keep getting this message in the browser:
SSL received a weak ephemeral Diffie-Hellman key in Server Key Exchange handshake message. (Error code: ssl_error_weak_server_ephemeral_dh_key)
I believe this is related to the cipher suite, but I'm A) not finding using the right cipher suite or B) configuring it in the wrong area of Apache Activemq. Currently, I've been adjusting the configuration of ssl in transport connector in activemq.xml( http://activemq.apache.org/ssl-transport-reference.html). However, I know that activemq uses a jetty server and i'm wondering if I should be configuring the suite in jetty.xml a la How to config local Jetty ssl to avoid weak phermeral DH key error?.
So, my questions are, is this the right approach? If so, what's the correct cipher suite for activemq?
The Java JDK version 1.7.0_79
Alright, I was able to create a work around by reading the activemq-apollo guide and then matching it to closed JIRA's in activemq:
http://activemq.apache.org/apollo/documentation/user-manual.html#Working_Around_Java_7_SSL_Bugs
https://issues.apache.org/jira/browse/AMQ-4520
Related
I'm trying to enable SSL on a Artemis broker and always get this exception when trying to connect:
Exception in thread "main" ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT message=AMQ219013: Timed out waiting to receive cluster topology. Group:null]
at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:743)
The code I use to connect is just this:
ActiveMQClient.createServerLocator("tcp://localhost:5500").createSessionFactory();
This is from a fresh install of Artemis 2.23.1 and the only thing I changed from the default broker configuration was to add this acceptor in broker.xml:
<acceptor name="netty-ssl-acceptor">tcp://localhost:5500?sslEnabled=true;keyStorePath=server-keystore.jks;keyStorePassword=securepass</acceptor>
I generated the keystore and truststore using the script provided in this example.
I had first tried a keystore with a cert that is valid for my domain (using a domain-qualified host name in createServerLocator()) but that also gave me the timeout. That is when I went back to fresh installs and tried going through the SSL example.
Various attempts with invalid paths/passwords/certs threw exceptions that led me to what to fix, but so far haven't been able to see what I did wrong with a generic timeout discovering cluster topology.
Anybody have ideas?
You need to specify sslEnabled=true on the client's URL as well so it knows to use SSL, e.g.:
ActiveMQClient.createServerLocator("tcp://localhost:5500?sslEnabled=true").createSessionFactory();
This is done for the JMS connection in the ssl-enabled example which you cited here.
Also, if you're using self-signed certificates then you'll need a truststore for your client as well and you'll need to configure those settings on the client's URL (just like in the example).
I am using AWS ELB as entry point (in Proxy mode) to load balance among 2 HAProxy-es behind it from where traffic goes further to MQTT broker.
Those 2 HAProxies are responsible for client TLS termination (2 way TLS).
Certificates kind of work. I've tested on local setup between 2 servers. I've been able to publish with 2-way TLS, properly terminate it, and publish message to mqtt. Problem arise when moving everything to AWS.
I am using self signed root CA, intermediate CA, server certificate and client certificates. Using Elliptic Curve...
Problem might be due to a servers CN. I think it has to be the same as hostname connecting to with tools like mosquitto_pub.
Error that I get is TLS error, whith debug -> ssl handshake failure. Somehow I am not able to produce more verbose errors. Using openssl with s_client and debug for max debug output. Which produce me ssl handshake failure.
I would really appreciate any hint/suggestion.
Thanks in advance.
Tomaz
I solved this by using subjectAltName feature. I edited openssl.cnf and add new section [alt_names] and reference it later on in configuration. Under alt_names I added 1 DNS key, and 2 IPs. Found with man x509v3_config.
Best,
Tomaz
I am trying to install IHS certs in Websphere Application Server 8.5
and after I install the IHS WebServer certs I am getting
javax.net.ssl.SSLHandshakeException: no cipher suites in common.
I did not even touch the application server or go into the Cell Level
but both the IHS and the app server are on the same box.
Please help me resolve this and point out where and why is the root
cause for all this.
I don't know Websphere but you can get this kind of error if the server side has no certificates configured and thus falls back to the ADH ciphers (anonymous authentication). These ciphers are usually not supported by the clients, at least not by default and thus you get "no shared ciphers". Just a guess because of lack of more information in the question.
A client installed on jBOSS is trying to access a secured website configured on DataPower xi50v6.0.0.2 appliance. The connection is getting failed at SSL handshake.
I have taken a packet capture at DataPower and observed that SSL Handshake is failing with the Description:Handshake failure(40).
However, at the Client Hello step, I have observed that, only one Cipher Suite is specified which is : TLS_EMPTY_RENEGOTIATION_INFO_SCSV.
The TLS protocol used ( as per packet capture) is TLS1.1. Can this Cipher Suite be a problem?
In the DataPower system logs I can see below error:
Request processing failed: Connection terminated before request headers read because of the connection error occurs
Update:
The client application is running on jBOSS7.I have asked our jBOSS administrator to check the configuration at jBOSS end. I somehow got the access to server where jBOSS instance is installed and checked domain.xml where the ssl is configured. Where exactly in domain.xml, ths configuration related to cipher suites can be found?
I have observed that, only one Cipher Suite is specified which is : TLS_EMPTY_RENEGOTIATION_INFO_SCSV
This is no real cipher. If no other ciphers are specified then the client does not offer any ciphers at all which means that no shared ciphers can be found and thus the handshake will fail. It looks like the client is buggy. Reason might be a failed attempt to fight POODLE attack by disabling all SSL3.0 ciphers, which in effect disables all ciphers for TLS1 1.0 and TLS 1.1.
I'm using django-celery do connect to a RabbitMQ broker through SSL (with the BROKER_USE_SSL setting). Is there a way to:
Verify the certificate of the broker when the connection is established.
Configure a client certificate to us to establish the connection.
The RabbitMQ side is working correctly, but I don't know how to configure Celery for this and I haven't found anything in Celery's documentation either. The settings CELERY_SECURITY_KEY, CELERY_SECURITY_CERTIFICATE and CELERY_SECURITY_CERT_STORE look like they could do this, but it seems that they're only used for message signing.
kombu.Connection accepts ssl argument as a dictionary of SSL configuration (ssl=False by default). I suppose it is applicable for BROKER_USE_SSL too.
BROKER_USE_SSL={
'ca_certs': '/etc/pki/tls/certs/something.crt',
'keyfile': '/etc/something/system.key',
'certfile': '/etc/something/system.cert',
'cert_reqs': ssl.CERT_REQUIRED,
}