Hello, I took the latest available dispatcher version (0.6.0-RC4) and replayed my test and tried to send a message using a JMS producer. The connection is failing at the level of the handshake. I also have the SSL debug output java side. On the dispatcher side, I can see that it is receiving an incomming connection.
PS: I can still connect using plain AMQP which works correctly. Shouldn't requireSsl prohibit access using amqp connctions and only allow amqps connection? Dispatcher config container { worker-threads: 4 containerName: qpid.dispatch.router1 } ssl-profile { name: ssl-profile-name certFile: cert_lx.pem keyFile: key_lx.pem } listener { host: 0.0.0.0 port: 10399 sasl-mechanisms: ANONYMOUS ssl-profile: ssl-profile-name authenticatePeer: no requireSsl: yes } router { mode: interior routerId: router1 helloInterval: 60 helloMaxAge: 180 } log { module: DEFAULT enable: debug+ source: false output: dispatch.10399.log } JMS Client code System.setProperty("javax.net.ssl.trustStore", "qpidJavaBrokerTrustStore_linux"); System.setProperty("javax.net.debug", "ssl"); ConnectionFactory connectionFactory = new JmsConnectionFactory("amqps://my_host:10399"); Connection connection = connectionFactory.createConnection();Dispatcher log Mon Jun 20 12:52:45 2016 SERVER (debug) Accepting incoming connection from HOSTNAME:63045 to 0.0.0.0:10399 JMS Client log with SSL debug ... *** ClientHello, TLSv1.2 RandomCookie: GMT: 1466354171 bytes = { 248, 170, 229, 244, 118, 59, 153, 155, 21, 89, 4, 185, 137, 154, 73, 114, 21, 226, 79, 55, 146, 199, 75, 60, 207, 41, 22, 42 } Session ID: {} Cipher Suites: [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_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, 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, SSL_RSA_WITH_RC4_128_MD5, 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 *** nioEventLoopGroup-2-1, WRITE: TLSv1.2 Handshake, length = 193 20 juin 2016 12:52:43,925 DEBUG ResourceLeakDetector - -Dio.netty.leakDetectionLevel: simple nioEventLoopGroup-2-1, called closeOutbound() nioEventLoopGroup-2-1, closeOutboundInternal() nioEventLoopGroup-2-1, SEND TLSv1 ALERT: warning, description = close_notify nioEventLoopGroup-2-1, WRITE: TLSv1 Alert, length = 2 nioEventLoopGroup-2-1, called closeInbound() nioEventLoopGroup-2-1, fatal error: 80: Inbound closed before receiving peer's close_notify: possible truncation attack? javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack? nioEventLoopGroup-2-1, SEND TLSv1 ALERT: fatal, description = internal_error nioEventLoopGroup-2-1, Exception sending alert: java.io.IOException: writer side was already closed. 20 juin 2016 12:52:43,941 DEBUG SslHandler - Failed to complete handshake java.nio.channels.ClosedChannelException 20 juin 2016 12:52:43,942 ERROR JmsConnectionFactory - Failed to create JMS Provider instance for: amqps Regards, Adel > Subject: Re: [Qpid-dispatch] Duplication between sslProfile and connector > options > From: acon...@redhat.com > To: users@qpid.apache.org > Date: Tue, 14 Jun 2016 13:53:35 -0400 > > On Fri, 2016-06-10 at 16:47 +0200, Adel Boutros wrote: > > > > > > The page you provided suits my needs. > > FYI, the real authority for dispatch configuration is: > > python/qpid_dispatch/management/qdrouter.json > > The man pages and configuration chapter are generated from that and are > easier to read, but they have some hand-written sections that are out > of date (all fixed or being fixed I think.) > > > However, I have a problem running SSL. I have configured the > > dispatcher (0.6.0 RC 4) as follows: > > ssl-profile { > > name: ssl-profile-name certFile: > > CERTIFICATE_DIR/cert_lx.pem keyFile: PRIVATE_KEY_DIR/key_lx.pem} > > listener { host: 0.0.0.0 port: 10399 sasl-mechanisms: > > ANONYMOUS ssl-profile: ssl-profile-name requirePeerAuth: > > no requireSsl: yes} > > Yet, I cannot even cannot using qdmanage: > > qdmanage --ssl-certificate=CERTIFICATE_DIR/cert_lx.pem --ssl- > > key=PRIVATE_KEY_DIR/key_lx.pem -b amqps://0.0.0.0:10399 create -- > > type=autoLink addr=queue dir=out connection=localhost.5672.connector > > name=localhost.5672.queue > > > > Exception client-side: > > SSLUnavailable: > > > > Weird incomplete message, no? > > > > Regards, > > Adel > > > > > > > > Date: Fri, 10 Jun 2016 10:11:25 -0400 > > > From: gmur...@redhat.com > > > To: users@qpid.apache.org > > > Subject: Re: [Qpid-dispatch] Duplication between sslProfile and > > > connector options > > > > > > Hi Adel, > > > You can find the entire list of entities and attributes here - > > > > > > http://qpid.apache.org/releases/qpid-dispatch-master/man/qdrouterd. > > > conf.html > > > > > > I will purge the book of dashed entity/attribute names on the > > > master branch. I have entered a JIRA for this so it can be tracked > > > - > > > > > > https://issues.apache.org/jira/browse/DISPATCH-377 > > > > > > Thanks. > > > > > > ----- Original Message ----- > > > > > > > > From: "Adel Boutros" <adelbout...@live.com> > > > > To: users@qpid.apache.org > > > > Sent: Friday, June 10, 2016 9:43:38 AM > > > > Subject: RE: [Qpid-dispatch] Duplication between sslProfile and > > > > connector options > > > > > > > > One last section, where in the book can I find the fields for > > > > ssl-profile > > > > configuration? I searched in Configuration Entities and found > > > > everything > > > > except "ssl-profile" fields. > > > > > > > > > > From: adelbout...@live.com > > > > > To: users@qpid.apache.org > > > > > Subject: RE: [Qpid-dispatch] Duplication between sslProfile and > > > > > connector > > > > > options > > > > > Date: Fri, 10 Jun 2016 15:39:13 +0200 > > > > > > > > > > Thank you Ganesh, > > > > > Is this documented somewhere? Will the dashed properties be > > > > > removed from > > > > > the Book to avoid such confusion in the future? > > > > > Regards,Adel > > > > > > > > > > > > > > > > > Date: Fri, 10 Jun 2016 08:30:15 -0400 > > > > > > From: gmur...@redhat.com > > > > > > To: users@qpid.apache.org > > > > > > Subject: Re: [Qpid-dispatch] Duplication between sslProfile > > > > > > and connector > > > > > > options > > > > > > > > > > > > Hi Adel, > > > > > > Going forward please use the camelCase and abandon using > > > > > > dashed > > > > > > properties (like cert-file). Following is an example of > > > > > > the *correct* > > > > > > way to use certFile > > > > > > > > > > > > sslProfile { > > > > > > certFile: /home/gmurthy/opensource/server-certificate.pem > > > > > > keyFile: /home/gmurthy/opensource//server-private-key.pem > > > > > > password: some-password > > > > > > name: client-ssl-profile > > > > > > certDb: /home/gmurthy/opensource/ca-certificate.pem > > > > > > } > > > > > > > > > > > > connector { > > > > > > addr: 127.0.0.1 > > > > > > role: inter-router > > > > > > sslProfile: client-ssl-profile # This connector will use > > > > > > the > > > > > > sslProfile with the name client-ssl-profile > > > > > > port: 24976 > > > > > > } > > > > > > > > > > > > Notice above that we specified certFile in only one place > > > > > > (inside the > > > > > > sslProfile) > > > > > > > > > > > > Thanks. > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > From: "Adel Boutros" <adelbout...@live.com> > > > > > > > To: users@qpid.apache.org > > > > > > > Sent: Friday, June 10, 2016 6:32:06 AM > > > > > > > Subject: [Qpid-dispatch] Duplication between sslProfile and > > > > > > > connector > > > > > > > options > > > > > > > > > > > > > > Hello guys, > > > > > > > In the ssl-profile, we can define some options such as > > > > > > > "cert-file". > > > > > > > When we > > > > > > > define a connector, we can provide the name of ssl-profile > > > > > > > and we can > > > > > > > set > > > > > > > "certFile". What is the behavior if we defined a cert-file > > > > > > > in the > > > > > > > ssl-profile and set the certFile property? > > > > > > > Is setting one of them enough? Or do we really need to set > > > > > > > both? > > > > > > > Regards,Adel > > > > > > ----------------------------------------------------------- > > > > > > ---------- > > > > > > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > > > > > > For additional commands, e-mail: users-h...@qpid.apache.org > > > > > > > > > > > > > > ----------------------------------------------------------------- > > > ---- > > > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > > > For additional commands, e-mail: users-h...@qpid.apache.org > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org >