You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by KenHall <ha...@dnb.com> on 2016/08/15 09:45:55 UTC
Using Trusted Cert with ActiveMQ SSL
We are trying to use ACtiveMQ SSL with target-only authentication with a
trusted cert from DigiCert. We were able to use SSL with self-signed certs
but we seem to have an issue when we
move to using a commercial trusted cert. Looking at the documentation here:
https://access.redhat.com/documentation/en-US/Fuse_ESB_Enterprise/7.1/html/ActiveMQ_Security_Guide/files/SSLUseCerts.html
It seems that the relevant piece of the documentation is this :
The broker is configured to have its own certificate and private key, which
are both stored in the file, broker.ks. The client is configured to have a
trust store, client.ts, that contains
the certificate that originally signed the broker certificate. Normally, the
trusted certificate is a Certificate Authority (CA) certificate.
We have received two certs from digicert for our server ourmq.ourco.com
which hosts the MQ broker instance that we want to communicate with via SSL.
These certs are ourmq_ourco_com.crt and
digiCertCA.crt.
I have put the broker certificate (ourmq_ourco_com.crt) and the
DigicertCA.crt certificate into broker.ts in the conf directory of the
broker MQ installation:
keytool -import -file /home/myuser/DigiCertCA.crt -keystore broker.ks
-alias "digiCertCA"
keytool -import -file /home/myuser/ourmq_ourco_com.crt -keystore broker.ks
-alias "ourmq.ourco.com"
I have also changed the broker configuration to create the ssl transport
entry on the desired port. I have NOT made any changes with regard to the
SSL context as I am using the default keystore (broker.ts) in the conf
directory of the ActiveMQ installation and therefore believe that I don't
have to create a new SSL context
I believe that the only thing that we should have to do is put the
digiCertCA certificate into the client.ts truststore in the conf directory
of the MQ instance on the client. We will also
have to make sure that our client can see ourmq.ourco.com by putting the
following entry in the /etc/hosts file on our client:
111.222.111.222 ourmq.ourco.com
We are accessing the Broker from the client using Java.
We have tried this and it doesn't work but I believe we have other issues so
I just want to confirm that our approach with regard to the installation of
the certificates is correct.
Thanks
--
View this message in context: http://activemq.2283324.n4.nabble.com/Using-Trusted-Cert-with-ActiveMQ-SSL-tp4715473.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Using Trusted Cert with ActiveMQ SSL
Posted by Tim Bain <tb...@alumni.duke.edu>.
I can add or update content to the ActiveMQ wiki if you're willing to
create it. But I can't put anything into the RedHat Fuse documentation to
which you originally linked...
Tim
On Wed, Aug 17, 2016 at 10:46 AM, KenHall <ha...@dnb.com> wrote:
> Hi Tim
>
> The key was 'the key' and I have resolved the issue now - thanks for your
> help. I have documented the process for our internal use and I would like
> to
> save someone else the pain - is there someone in the community that I can
> submit documentation to so that it can be made part of the ActiveMQ
> documentation?
> Ken
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/Using-Trusted-Cert-with-ActiveMQ-SSL-tp4715473p4715587.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Re: Using Trusted Cert with ActiveMQ SSL
Posted by KenHall <ha...@dnb.com>.
Hi Tim
The key was 'the key' and I have resolved the issue now - thanks for your
help. I have documented the process for our internal use and I would like to
save someone else the pain - is there someone in the community that I can
submit documentation to so that it can be made part of the ActiveMQ
documentation?
Ken
--
View this message in context: http://activemq.2283324.n4.nabble.com/Using-Trusted-Cert-with-ActiveMQ-SSL-tp4715473p4715587.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Using Trusted Cert with ActiveMQ SSL
Posted by Tim Bain <tb...@alumni.duke.edu>.
I personally don't know of a guide that's better than the rest, though I've
always been able to just use keytool from our OpenSSH installs and I've
never had trouble finding tutorials online with a few minutes of Google
searching. But the process for importing keys into a keystore is pretty
far outside the scope of this mailing list, so if you're having trouble
doing it I'd suggest posting a question to StackOverflow, since it's a more
general Q&A site.
Tim
On Wed, Aug 17, 2016 at 7:57 AM, KenHall <ha...@dnb.com> wrote:
> OK - I Have found the key - when I created the Signing Request I ended up
> with two files :
>
> 111_222_111_222.csr
> 111_222_111_222.key
>
> (although this was on ourmq.ourco.com the files seemed to take the IP
> address - I assume this won't matter)
>
> So from what you say 111_222_111_22.key and this should be imported into
> the
> broker.ks and associated with the ourmq_ourco_com.crt that was previously
> imported. Looking at the documentation in this area it seems that in the
> past this process was quite involved - is that still the case and if so can
> you recommend a good guide to doing this,
>
> Thanks for all your help.
> Ken
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/Using-Trusted-Cert-with-ActiveMQ-SSL-tp4715473p4715581.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Re: Using Trusted Cert with ActiveMQ SSL
Posted by KenHall <ha...@dnb.com>.
OK - I Have found the key - when I created the Signing Request I ended up
with two files :
111_222_111_222.csr
111_222_111_222.key
(although this was on ourmq.ourco.com the files seemed to take the IP
address - I assume this won't matter)
So from what you say 111_222_111_22.key and this should be imported into the
broker.ks and associated with the ourmq_ourco_com.crt that was previously
imported. Looking at the documentation in this area it seems that in the
past this process was quite involved - is that still the case and if so can
you recommend a good guide to doing this,
Thanks for all your help.
Ken
--
View this message in context: http://activemq.2283324.n4.nabble.com/Using-Trusted-Cert-with-ActiveMQ-SSL-tp4715473p4715581.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Using Trusted Cert with ActiveMQ SSL
Posted by Tim Bain <tb...@alumni.duke.edu>.
A cert is a wrapper around the public key from a public-private key pair.
Either you created your own keypair and asked the CA to create the cert
using the public key (in which case you just need to go find the private
key) or you asked the CA to generate a new keypair for you and create a
cert from the public key (in which case the CA will have sent you the
public key in addition to the cert). Either way, certs are generated from
keys, not the other way around.
Tim
On Aug 17, 2016 7:31 AM, "KenHall" <ha...@dnb.com> wrote:
> Hi Tim,
>
> I assumed that a key was created in the key store when a cert was added. If
> that's not the case - how do I create a key? and how do I install it?
>
> Is this key related to the Certificate Signing request that I used to get a
> Certificate from the CA?
>
> Ken
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/Using-Trusted-Cert-with-ActiveMQ-SSL-tp4715473p4715576.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Re: Using Trusted Cert with ActiveMQ SSL
Posted by KenHall <ha...@dnb.com>.
Hi Tim,
I assumed that a key was created in the key store when a cert was added. If
that's not the case - how do I create a key? and how do I install it?
Is this key related to the Certificate Signing request that I used to get a
Certificate from the CA?
Ken
--
View this message in context: http://activemq.2283324.n4.nabble.com/Using-Trusted-Cert-with-ActiveMQ-SSL-tp4715473p4715576.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Using Trusted Cert with ActiveMQ SSL
Posted by Tim Bain <tb...@alumni.duke.edu>.
I want to highlight a phrase you quoted from the documentation you
referenced: "The broker is configured to have its own certificate and
private key." I see where you installed the broker's cert (the ourco one),
but i don't see in your description where you installed the private key.
Did that happen?
Tim
On Aug 15, 2016 8:07 AM, "KenHall" <ha...@dnb.com> wrote:
> Hi Tim,
>
> Yes we're using the ourmq.ourco.com address and the certificate common
> name
> is the same.
>
> So my very simplistic piece of java code looks like this:
> System.setProperty("javax.net.debug","ssl");
> ActiveMQSslConnectionFactory connectionFactory = new
> ActiveMQSslConnectionFactory("ssl://ourmq.ourco.com:XXXX");
> connectionFactory.setTrustStore(PATH+"/client.ts");
> connectionFactory.setTrustStorePassword("password");
> Connection connection = connectionFactory.createConnection();
> connection.start();
>
> I have been getting issues which result in an SSL Handshake exception. I
> thought this was related to encryption policy jars and have updated these
> at
> both sides to the higher strength encryption but I still get the same
> errors. So now I get something like this (all I have changed in the output
> is to keep confidentiality). The client is using jdk 1.8 and the broker jdk
> 1.7 but I don't think that should make any difference:
>
> Starting.....
> adding as trusted cert:
> Subject: CN=localhost, OU=broker, O=Unknown, L=Unknown, ST=Unknown,
> C=Unknown
> Issuer: CN=localhost, OU=broker, O=Unknown, L=Unknown, ST=Unknown,
> C=Unknown
> Algorithm: RSA; Serial number: 0x4537c82e
> Valid from Thu Oct 19 19:47:10 BST 2006 until Wed Jan 17 18:47:10 GMT
> 2007
>
> adding as trusted cert:
> Subject: CN=DigiCert SHA2 High Assurance Server CA, OU=www.digicert.com,
> O=DigiCert Inc, C=US
> .......
> Valid from Tue Oct 22 13:00:00 BST 2013 until Sun Oct 22 13:00:00 BST
> 2028
>
> trigger seeding of SecureRandom
> done seeding SecureRandom
> Allow unsafe renegotiation: false
> Allow legacy hello messages: true
> Is initial handshake: true
> Is secure renegotiation: false
> main, setSoTimeout(0) called
> Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
> for TLSv1
> Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
> for
> TLSv1
> Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for
> TLSv1
> Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
> for TLSv1
> Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
> for
> TLSv1
> Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for
> TLSv1
> Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for
> TLSv1
> Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
> for TLSv1.1
> Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
> for
> TLSv1.1
> Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for
> TLSv1.1
> Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
> for TLSv1.1
> Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
> for
> TLSv1.1
> Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for
> TLSv1.1
> Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for
> TLSv1.1
> log4j:WARN No appenders could be found for logger
> (org.apache.activemq.transport.WireFormatNegotiator).
> log4j:WARN Please initialize the log4j system properly.
> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for
> more info.
> %% No cached client session
> *** ClientHello, TLSv1.2
> RandomCookie: GMT: 1454425573 bytes = { 245, 115, 73, 243, 107, 74, 79,
> 221, 236, 153, 89, 128, 222, 149, 200, 153, 84, 140, 5, 103, 248, 24, 111,
> 201, 66, 162, 15, 234 }
> Session ID: {}
> Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256,
> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,
> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,
> TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA,
> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256,
> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,
> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,
> TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA,
> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
> TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_
> GCM_SHA256,
> TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_3DES_EDE_
> CBC_SHA,
> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA,
> TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,
> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,
> TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
> Compression Methods: { 0 }
> Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2,
> secp192r1, secp224r1, sect233k1, sect233r1, sect283k1, sect283r1,
> secp384r1,
> sect409k1, sect409r1, secp521r1, sect571k1, sect571r1, secp160k1,
> secp160r1,
> secp160r2, sect163r1, secp192k1, sect193r1, sect193r2, secp224k1,
> sect239k1,
> secp256k1}
> Extension ec_point_formats, formats: [uncompressed]
> Extension signature_algorithms, signature_algorithms: SHA512withECDSA,
> SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA,
> SHA256withRSA, SHA224withECDSA, SHA224withRSA, SHA1withECDSA, SHA1withRSA,
> SHA1withDSA, MD5withRSA
> ***
> ActiveMQ Transport: ssl://ourmq.ourco.com/111.222.111.222:9999, WRITE:
> TLSv1.2 Handshake, length = 237
> ActiveMQ Transport: ssl://ourmq.ourco.com/111.222.111.222:9999, READ:
> TLSv1.2 Alert, length = 2
> ActiveMQ Transport: ssl://ourmq.ourco.com/111.222.111.222:9999, RECV
> TLSv1.2
> ALERT: fatal, handshake_failure
> ActiveMQ Transport: ssl://ourmq.ourco.com/111.222.111.222:9999, called
> closeSocket()
> ActiveMQ Transport: ssl://ourmq.ourco.com/111.222.111.222:9999, handling
> exception: javax.net.ssl.SSLHandshakeException: Received fatal alert:
> handshake_failure
> main, handling exception: javax.net.ssl.SSLHandshakeException: Received
> fatal alert: handshake_failure
> ActiveMQ Task-1, called close()
> ActiveMQ Task-1, called closeInternal(true)
> Exception in thread "main" javax.jms.JMSException: Could not connect to
> broker URL: ssl://ourmq.ourco.com:9999. Reason:
> javax.net.ssl.SSLHandshakeException: Received fatal alert:
> handshake_failure
> at
> org.apache.activemq.util.JMSExceptionSupport.create(
> JMSExceptionSupport.java:35)
> at
> org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(
> ActiveMQConnectionFactory.java:293)
> at
> org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(
> ActiveMQConnectionFactory.java:238)
> at
> org.apache.activemq.ActiveMQConnectionFactory.createConnection(
> ActiveMQConnectionFactory.java:184)
> at RunSSLTest.main(RunSSLTest.java:26)
> Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert:
> handshake_failure
> at sun.security.ssl.Alerts.getSSLException(Unknown Source)
> at sun.security.ssl.Alerts.getSSLException(Unknown Source)
> at sun.security.ssl.SSLSocketImpl.recvAlert(Unknown Source)
> at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
> at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown
> Source)
> at sun.security.ssl.SSLSocketImpl.readDataRecord(Unknown Source)
> at sun.security.ssl.AppInputStream.read(Unknown Source)
> at
> org.apache.activemq.transport.tcp.TcpBufferedInputStream.
> fill(TcpBufferedInputStream.java:50)
> at
> org.apache.activemq.transport.tcp.TcpTransport$2.fill(
> TcpTransport.java:604)
> at
> org.apache.activemq.transport.tcp.TcpBufferedInputStream.
> read(TcpBufferedInputStream.java:58)
> at
> org.apache.activemq.transport.tcp.TcpTransport$2.read(
> TcpTransport.java:589)
> at java.io.DataInputStream.readInt(Unknown Source)
> at
> org.apache.activemq.openwire.OpenWireFormat.unmarshal(
> OpenWireFormat.java:275)
> at
> org.apache.activemq.transport.tcp.TcpTransport.readCommand(
> TcpTransport.java:221)
> at
> org.apache.activemq.transport.tcp.TcpTransport.doRun(
> TcpTransport.java:213)
> at
> org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196)
> at java.lang.Thread.run(Unknown Source)
>
>
>
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/Using-Trusted-Cert-with-ActiveMQ-SSL-tp4715473p4715482.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Re: Using Trusted Cert with ActiveMQ SSL
Posted by KenHall <ha...@dnb.com>.
Hi Tim,
Yes we're using the ourmq.ourco.com address and the certificate common name
is the same.
So my very simplistic piece of java code looks like this:
System.setProperty("javax.net.debug","ssl");
ActiveMQSslConnectionFactory connectionFactory = new
ActiveMQSslConnectionFactory("ssl://ourmq.ourco.com:XXXX");
connectionFactory.setTrustStore(PATH+"/client.ts");
connectionFactory.setTrustStorePassword("password");
Connection connection = connectionFactory.createConnection();
connection.start();
I have been getting issues which result in an SSL Handshake exception. I
thought this was related to encryption policy jars and have updated these at
both sides to the higher strength encryption but I still get the same
errors. So now I get something like this (all I have changed in the output
is to keep confidentiality). The client is using jdk 1.8 and the broker jdk
1.7 but I don't think that should make any difference:
Starting.....
adding as trusted cert:
Subject: CN=localhost, OU=broker, O=Unknown, L=Unknown, ST=Unknown,
C=Unknown
Issuer: CN=localhost, OU=broker, O=Unknown, L=Unknown, ST=Unknown,
C=Unknown
Algorithm: RSA; Serial number: 0x4537c82e
Valid from Thu Oct 19 19:47:10 BST 2006 until Wed Jan 17 18:47:10 GMT 2007
adding as trusted cert:
Subject: CN=DigiCert SHA2 High Assurance Server CA, OU=www.digicert.com,
O=DigiCert Inc, C=US
.......
Valid from Tue Oct 22 13:00:00 BST 2013 until Sun Oct 22 13:00:00 BST 2028
trigger seeding of SecureRandom
done seeding SecureRandom
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
main, setSoTimeout(0) called
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for
TLSv1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for
TLSv1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for
TLSv1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for
TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for
TLSv1.1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for
TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for
TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for
TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for
TLSv1.1
log4j:WARN No appenders could be found for logger
(org.apache.activemq.transport.WireFormatNegotiator).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for
more info.
%% No cached client session
*** ClientHello, TLSv1.2
RandomCookie: GMT: 1454425573 bytes = { 245, 115, 73, 243, 107, 74, 79,
221, 236, 153, 89, 128, 222, 149, 200, 153, 84, 140, 5, 103, 248, 24, 111,
201, 66, 162, 15, 234 }
Session ID: {}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,
TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods: { 0 }
Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2,
secp192r1, secp224r1, sect233k1, sect233r1, sect283k1, sect283r1, secp384r1,
sect409k1, sect409r1, secp521r1, sect571k1, sect571r1, secp160k1, secp160r1,
secp160r2, sect163r1, secp192k1, sect193r1, sect193r2, secp224k1, sect239k1,
secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Extension signature_algorithms, signature_algorithms: SHA512withECDSA,
SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA,
SHA256withRSA, SHA224withECDSA, SHA224withRSA, SHA1withECDSA, SHA1withRSA,
SHA1withDSA, MD5withRSA
***
ActiveMQ Transport: ssl://ourmq.ourco.com/111.222.111.222:9999, WRITE:
TLSv1.2 Handshake, length = 237
ActiveMQ Transport: ssl://ourmq.ourco.com/111.222.111.222:9999, READ:
TLSv1.2 Alert, length = 2
ActiveMQ Transport: ssl://ourmq.ourco.com/111.222.111.222:9999, RECV TLSv1.2
ALERT: fatal, handshake_failure
ActiveMQ Transport: ssl://ourmq.ourco.com/111.222.111.222:9999, called
closeSocket()
ActiveMQ Transport: ssl://ourmq.ourco.com/111.222.111.222:9999, handling
exception: javax.net.ssl.SSLHandshakeException: Received fatal alert:
handshake_failure
main, handling exception: javax.net.ssl.SSLHandshakeException: Received
fatal alert: handshake_failure
ActiveMQ Task-1, called close()
ActiveMQ Task-1, called closeInternal(true)
Exception in thread "main" javax.jms.JMSException: Could not connect to
broker URL: ssl://ourmq.ourco.com:9999. Reason:
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
at
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:35)
at
org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:293)
at
org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:238)
at
org.apache.activemq.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:184)
at RunSSLTest.main(RunSSLTest.java:26)
Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert:
handshake_failure
at sun.security.ssl.Alerts.getSSLException(Unknown Source)
at sun.security.ssl.Alerts.getSSLException(Unknown Source)
at sun.security.ssl.SSLSocketImpl.recvAlert(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readDataRecord(Unknown Source)
at sun.security.ssl.AppInputStream.read(Unknown Source)
at
org.apache.activemq.transport.tcp.TcpBufferedInputStream.fill(TcpBufferedInputStream.java:50)
at
org.apache.activemq.transport.tcp.TcpTransport$2.fill(TcpTransport.java:604)
at
org.apache.activemq.transport.tcp.TcpBufferedInputStream.read(TcpBufferedInputStream.java:58)
at
org.apache.activemq.transport.tcp.TcpTransport$2.read(TcpTransport.java:589)
at java.io.DataInputStream.readInt(Unknown Source)
at
org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:275)
at
org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:221)
at
org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:213)
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196)
at java.lang.Thread.run(Unknown Source)
--
View this message in context: http://activemq.2283324.n4.nabble.com/Using-Trusted-Cert-with-ActiveMQ-SSL-tp4715473p4715482.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Using Trusted Cert with ActiveMQ SSL
Posted by Tim Bain <tb...@alumni.duke.edu>.
How do your clients address the broker when they connect to it? Do they
address it as ourmq.ourco.com, or as ourmq? The cert needs to match
whatever method they use to connect, though if you're not self-signing your
certs, FQDN is about to become the only option per this article:
https://www.godaddy.com/help/can-i-request-a-certificate-for-an-intranet-name-or-ip-address-6935
On Aug 15, 2016 3:46 AM, "KenHall" <ha...@dnb.com> wrote:
>
> We are trying to use ACtiveMQ SSL with target-only authentication with a
> trusted cert from DigiCert. We were able to use SSL with self-signed certs
> but we seem to have an issue when we
>
> move to using a commercial trusted cert. Looking at the documentation here:
>
> https://access.redhat.com/documentation/en-US/Fuse_ESB_
> Enterprise/7.1/html/ActiveMQ_Security_Guide/files/SSLUseCerts.html
>
> It seems that the relevant piece of the documentation is this :
>
> The broker is configured to have its own certificate and private key, which
> are both stored in the file, broker.ks. The client is configured to have a
> trust store, client.ts, that contains
>
> the certificate that originally signed the broker certificate. Normally,
> the
> trusted certificate is a Certificate Authority (CA) certificate.
>
> We have received two certs from digicert for our server ourmq.ourco.com
> which hosts the MQ broker instance that we want to communicate with via
> SSL.
> These certs are ourmq_ourco_com.crt and
>
> digiCertCA.crt.
>
> I have put the broker certificate (ourmq_ourco_com.crt) and the
> DigicertCA.crt certificate into broker.ts in the conf directory of the
> broker MQ installation:
>
>
> keytool -import -file /home/myuser/DigiCertCA.crt -keystore broker.ks
> -alias "digiCertCA"
> keytool -import -file /home/myuser/ourmq_ourco_com.crt -keystore
> broker.ks
> -alias "ourmq.ourco.com"
>
>
> I have also changed the broker configuration to create the ssl transport
> entry on the desired port. I have NOT made any changes with regard to the
> SSL context as I am using the default keystore (broker.ts) in the conf
> directory of the ActiveMQ installation and therefore believe that I don't
> have to create a new SSL context
>
> I believe that the only thing that we should have to do is put the
> digiCertCA certificate into the client.ts truststore in the conf directory
> of the MQ instance on the client. We will also
>
> have to make sure that our client can see ourmq.ourco.com by putting the
> following entry in the /etc/hosts file on our client:
>
> 111.222.111.222 ourmq.ourco.com
>
> We are accessing the Broker from the client using Java.
>
> We have tried this and it doesn't work but I believe we have other issues
> so
> I just want to confirm that our approach with regard to the installation of
> the certificates is correct.
>
> Thanks
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/Using-Trusted-Cert-with-ActiveMQ-SSL-tp4715473.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>