Develop Reference

Securing Neo4J with TLS through bolt protocol

Neo4J server configuration allows to set up a server-side policy to secure both HTTPS and BOLT connections.
In my installation I secured the BOLT connection by setting up a policy with PEM public and private key and settings:
dbms.connector.bolt.enabled=true
dbms.connector.bolt.tls_level=REQUIRED
bolt.ssl_policy=my_policy
dbms.ssl.policy.my_policy..base_directory=...
...
The set up works with a browser client. When I connect to the server through HTTPS, I am able to log in using ":server connect" command and use Neo4J browser with my server.
What I cannot do is figure out how other client can connect to Neo4J with secure BOLT protocol. Specifically, I tried connecting from cypher-shell and from a Java client (using Java Driver v 1.6). When TLS for BOLT is disabled, both connect without a hitch. Enabling TLS causes bad_certificate error in both clients.
I tried starting both cypher-shell and my Java client by passing JVM properties pointing to my trust store and key store
(-Djavax.net.ssl.keyStore=...
-Djavax.net.ssl.keyStorePassword=...
-Djavax.net.ssl.trustStore=...
-Djavax.net.ssl.trustStorePassword=...)
These properties have no effect on either Neo4J client. I am getting a bad_certificate exception.
I tried enabling SSL debugging (-Djavax.net.debug=ssl,handshake). Calling the Java client or cypher-shell with keystore and truststore parameters has no effect on the SSL debug output.
How do I connect to the server with TLS for BOLT enabled from cypher-shell or a Java client?
Thank you.

java application running on tomcat. Unable to access over ajp.

Application is accessible over tomcat http port.
Application when accessed from web server(Apache http server) gives bad gateway error.
worker.properties(apache http server) & server.xml(tomcat) are tuned well. Socket/connection timeout is 20 sec on both sides.
Jk.log shows below error.
enter image description here
The error says tomcat is not accepting any connections. But how come at the same time, application is accessible over http.
On tomcat side I dont see any errors in the log.

You use different ports for HTTP connection (default is 8080) and for AJP connection (default is 8009). You can check exact values in conf/server.xml.
Your error indicates that there are some problems between httpd and client (firewall, slow connection etc.). Try to remove timeouts, like worker.ajp13.socket_timeout=3. (https://tomcat.apache.org/connectors-doc/common_howto/timeouts.html)
Make sure that ports are not blocked by possible firewalls. For Ubuntu, UFW (Uncomplicated Firewall) could be used to open AJP connections: ufw enable && ufw allow 8009.

Client connection to IBM MQ unauthorized

I'm trying to setup a Client connection to IBM MQ and test this using the samples application wmqjava.
I am able to connect in binding mode but I'm getting a 2035 unauthorised error when using client mode.
The steps I've taken to set this up are:
Create / run a queue manager
Create a listener
Create a SVRConn channel (multiple attempts)
I think I'm missing something with authorisation?
DEF CHL('TEST2.CHANNEL') CHLTYPE(SVRCONN) TRPTYPE(TCP) MCAUSER(' ')
I'm trying to connect to this on the same machine that the MQ server is running on.

Depending on the version of IBM MQ you are using, you could be being blocked by the default CHLAUTH rule which bans client connections which assert privileged user ids, or the default CONNAUTH rule which demands a password is provided for such a client connection.
Read Getting going without turning off MQ Security for instructions on how to turn both off, or use both correctly.
FYI: Your queue manager error log will tell you the reason you were blocked from accessing it.

You can put the user "mqm" in MCAUSER Field to bypass all the authorisation.
DEF CHL('TEST2.CHANNEL') CHLTYPE(SVRCONN) TRPTYPE(TCP) MCAUSER('mqm')
This will use all the authorities of mqm user (Default MQ admin user) to connect to Queue Manager.
Alternatively you can authorize the user to allow to connect, put, get messages.
setmqauth or getmqauth commands can help you.

Missing ServerHelloDone while SSL Hanshake

I try to connect to a wss (Secure Websocket) server with a java applet but the ssl handshake fails without any helpfull log entrys.
If I connect to wss://echo.websocket.org the handshake works fine, so I think it's not a general java code error.
If I try to connect to my own server, the HelloDone bit is sent (verified by wireshark) but the connections ends in a hang-up and it's not in the log. Normally there should be the following message in the log: "*** ServerHelloDone"
See my java console log of "javax.net.debug=sll"
http://pastebin.com/ZuvKww4J
It is not truncated, it simply ends there.
After a couple of seconds the tcp connection timeout message is added to the log.
I use the following example of java code:
https://github.com/TooTallNate/Java-WebSocket/blob/master/src/main/example/SSLClientExample.java
But instead of keystore I use:
sslContext.init( null, null, null );
For the server I have two different test systems:
At port 443 a ha-proxy
at port 8443 a stunnel.
I tried to isolate the error with different methods. First I forced with stunnel the same cipher as echo.websocket.org "SSL_RSA_WITH_RC4_128_SHA" but no success.
Second I checked if the ssl certificate itself is still valid. But as web browser and normal https connection by my java applet, are accepted from the server (Same server. ha-proxy orstunnel) everything is working at that point to.

Problem was solved by maintainer of Java-WebSocket.
Big thans

Connecting JMS to MQ using MQClient java and MQExplorer error JMSWMQ2013

I am using MQexplorer to handle queue manager, and when I connect to MQ using JMS with JNDI lookup, using qcf.createQueueConnection(); I am getting JMSWMQ2013: The security authentication was not valid that was supplied for QueueManager error. All posts/blogs mention about this error, but they say to remove CHAUTH for queuemanager and so on... How do I work this out using MQExplorer? Please help me on this!
I am using MQ client(with JNDI on LDAP) connection which can connect remote machine(not bindings).

Actually disabling CHLAUTH is NOT advised as doing so opens up your queue manager to the world. It's OK if this is a test queue manager. Using runmqsc you can disable channel authentication. In runmqsc issue "ALTER QMGR CHLAUTH(DISABLED)" command to disable channel authentication.
Please read WMQ InfoCenter or Chapter 20 of this redbook or just search for T.Rob's posts in this forum on CHLAUTH. Few links here, this one