Thank you Ganesh, I actually got it working using self-signed certificate and the "--ssl-certificate" and the "--ssl-key" params for qdmanage. Do you think using "--ssl-trustfile" is better security wise?
One more question, do I have to use the same certificate between Consumer/Producers --> Dispatchers --> Brokers? Sorry but security is not yet a domain I master. Regards, Adel > Date: Mon, 20 Jun 2016 16:11:14 -0400 > From: [email protected] > To: [email protected] > Subject: Re: [Qpid-dispatch] Duplication between sslProfile and connector > options > > Hi Adel, > It was not clear from your email if you got SSL working on your dispatch > router. Here are the steps I used to create the ca certs/server certs using > openssl and use them in the dispatch router - > > # Create the root CA private key for the CA cert, this key is password > protected > openssl genrsa -out ca_privatekey.pem 4096 > > # Use the root key (ca_privatekey.pem) to create a root CA certificate > (ca.cert.pem) > # (-x509 option puts out a self signed certificate instead of a certificate > request > openssl req -key ca_privatekey.pem -new -x509 -days 7300 -sha256 -out > ca.cert.pem > > # I did not create an intermediate certificate authority (CA), I am using the > root CA to sign my server and/or client certificates > # Create a server private key (non-password protected) which will be used to > create the server certificate > openssl genrsa -out server_private_key.pem 4096 > > # Create a CSR using the private key created from the previous step > openssl req -new -key server_private_key.pem -out server.csr > > # Now the CSR has been created and must be sent to the CA. > # The root CA receives the CSR and runs this command to create a server > certificate (server_cert.pem) > openssl x509 -req -in server.csr -CA ca.cert.pem -CAkey ca_privatekey.pem > -CAcreateserial -days 9999 -out server_cert.pem > > Here is my dispatch router config - > > sslProfile { > name: server-ssl-profile > certFile: > /home/gmurthy/opensource/dispatch/etc/ssl-my-certs/root/ca/server_cert.pem > keyFile: > /home/gmurthy/opensource/dispatch/etc/ssl-my-certs/root/ca/server_private_key.pem > certDb: > /home/gmurthy/opensource/dispatch/etc/ssl-my-certs/root/ca/ca.cert.pem > } > > listener { > ssl-profile: server-ssl-profile > authenticatePeer: no > requireEncryption: yes > saslMechanisms: ANONYMOUS > role: normal > addr: 127.0.0.1 > port: amqp > } > > Now, I ran qdstat client with the --ssl-trustfile option (the client have to > provide the trusted ca db to the server) > > [gmurthy@localhost dispatch]$ qdstat -b www.hellower.com:5672 -c > --ssl-trustfile=/home/gmurthy/opensource/dispatch/etc/ssl-my-certs/root/ca/ca.cert.pem > Connections > Id host container role > dir security authentication > > ============================================================================================================================================ > 1 localhost.localdomain:39984 f2a9a5a5-c721-481f-8046-c2ef86c86dc1 > normal in TLSv1/SSLv3(DHE-RSA-AES256-GCM-SHA384) anonymous-user > [gmurthy@localhost dispatch]$ > > (thanks kgiusti for help) > > Thanks. > > ----- Original Message ----- > > From: "Adel Boutros" <[email protected]> > > To: [email protected] > > Sent: Monday, June 20, 2016 12:37:45 PM > > Subject: RE: [Qpid-dispatch] Duplication between sslProfile and connector > > options > > > > We find the issue. It was a cached configuration file in our system. > > Apologies for the inconvenience caused. > > Regards,Adel > > > > > From: [email protected] > > > To: [email protected] > > > Subject: RE: [Qpid-dispatch] Duplication between sslProfile and connector > > > options > > > Date: Mon, 20 Jun 2016 16:54:11 +0200 > > > > > > I have debugged the python management part which gets the attribute and it > > > seems to be not reading them from the json config file as it is supposed > > > to. Am I missing something? > > > > > > python/qpid_dispatch/management/entity.py (Added code to print attributed > > > to file) > > > class EntityBase(object): > > > """ > > > A collection of named attributes. > > > > > > Attribute access: > > > - via index operator: entity['foo'] > > > - as python attributes: entity.foo (only if attribute name is a legal > > > python identitfier > > > after replacing '-' with '_') > > > > > > @ivar attributes: Map of attribute values for this entity. > > > > > > NOTE: EntityBase does not itself implement the python map protocol > > > because map > > > methods (in particular 'update') can clash with AMQP methods and > > > attributes. > > > """ > > > > > > def __init__(self, attributes=None, **kwargs): > > > self.__dict__['attributes'] = {} > > > if attributes: > > > file = open("py.log", "a") > > > for k, v in attributes.iteritems(): > > > file.write("Attribute: %s = %s\n" %(k,v)) > > > self.attributes[k] = v > > > self.__dict__[self._pyname(k)] = v > > > file.close() > > > for k, v in kwargs.iteritems(): > > > self._set(k, v) > > > > > > > > > py.log > > > Attribute: stripAnnotations = both > > > Attribute: requireSsl = 0 > > > Attribute: idleTimeoutSeconds = 16 > > > Attribute: host = 127.0.0.1 > > > Attribute: cost = 1 > > > Attribute: port = 10399 > > > Attribute: addr = 0.0.0.0 > > > Attribute: saslMechanisms = ANONYMOUS > > > Attribute: maxFrameSize = 16384 > > > Attribute: requireEncryption = False > > > Attribute: role = normal > > > Attribute: authenticatePeer = 0 > > > Attribute: type = org.apache.qpid.dispatch.listener > > > > > > > > > Regards, > > > Adel > > > > > > > From: [email protected] > > > > To: [email protected] > > > > Subject: RE: [Qpid-dispatch] Duplication between sslProfile and > > > > connector > > > > options > > > > Date: Mon, 20 Jun 2016 15:02:01 +0200 > > > > > > > > I found something which might be interesting. Actually the config of the > > > > Listener is not taken into consideration. > > > > With the config you proposed, if you check the below log in the > > > > dispatcher, the parameters are not taken into consideration. For > > > > example, the requiresSSL is always False although we have set it to > > > > "yes" > > > > > > > > Log line: > > > > Mon Jun 20 14:59:10 2016 AGENT (debug) Add entity: > > > > ListenerEntity(addr=0.0.0.0, authenticatePeer=False, cost=1, > > > > host=127.0.0.1, identity=listener/127.0.0.1:10399, > > > > idleTimeoutSeconds=16, maxFrameSize=16384, port=10399, > > > > requireEncryption=False, requireSsl=False, role=normal, > > > > saslMechanisms=ANONYMOUS, stripAnnotations=both, > > > > type=org.apache.qpid.dispatch.listener) > > > > > > > > Regards, > > > > Adel > > > > > > > > > From: [email protected] > > > > > To: [email protected] > > > > > Subject: RE: [Qpid-dispatch] Duplication between sslProfile and > > > > > connector options > > > > > Date: Mon, 20 Jun 2016 12:56:02 +0200 > > > > > > > > > > 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: [email protected] > > > > > > To: [email protected] > > > > > > 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: [email protected] > > > > > > > > To: [email protected] > > > > > > > > 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" <[email protected]> > > > > > > > > > To: [email protected] > > > > > > > > > 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: [email protected] > > > > > > > > > > To: [email protected] > > > > > > > > > > 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: [email protected] > > > > > > > > > > > To: [email protected] > > > > > > > > > > > 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" <[email protected]> > > > > > > > > > > > > To: [email protected] > > > > > > > > > > > > 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: [email protected] > > > > > > > > > > > For additional commands, e-mail: > > > > > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----------------------------------------------------------------- > > > > > > > > ---- > > > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
