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.
Related
I have a raspberry running a mqtt broker and a java backend. I can't establish a connection from backend to broker since I've implemented ssl. I can connect the backend to the broker on raspberry from my IDE running on my MacBook like:
client = new MqttAsyncClient(
"ssl://my-domain.com:1883", "backend");
if the backend is on the raspberry I tried:
client = new MqttAsyncClient(
"ssl://localhost:1883", "backend");
client = new MqttAsyncClient(
"ssl://127.0.0.1:1883", "backend");
No success. I´ve never used a ssl connection in this context. did I oversee something?
Error:
Exception in thread "main" No connection to client (32104)
at org.eclipse.paho.client.mqttv3.internal.ExceptionHelper.createMqttException(ExceptionHelper.java:31)
at org.eclipse.paho.client.mqttv3.internal.ClientComms.sendNoWait(ClientComms.java:143)
at org.eclipse.paho.client.mqttv3.MqttAsyncClient.subscribe(MqttAsyncClient.java:721)
at org.eclipse.paho.client.mqttv3.MqttAsyncClient.subscribe(MqttAsyncClient.java:681)
at com.cdh.Service.mqttManager.subscribe(mqttManager.java:243)
at com.cdh.main.main(main.java:14)
EDIT:
I changed the port to 8883. It works if I run the backend on an other device but not if the broker and the backend are on the raspberry. I also tried to use the domain name from my cert.
The hostname you use to connect needs to match the CN or SAN entries in the certificate presented by the broker or else it will fail validation.
Unless you included 127.0.0.1 or localhost in the certificate the the client will reject the connection because the certificate doesn't validate for that address.
p.s. you should probably use a different port for MQTT of TLS rather than 1883 as that is the standard port for MQTT without TLS.
I am trying to connect to elastic search (7.8) securely through Java transport client. I have used x-pack to secure elastic search connectivity. I am not able to create an object of Client due to below error.
2020-08-13 17:43:24 [main] DEBUG XPackSettings:199 - TLSv1.3 is not supported
java.security.NoSuchAlgorithmException: TLSv1.3 SSLContext not available
at sun.security.jca.GetInstance.getInstance(GetInstance.java:159) ~[?:1.8.0_251]
at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156) ~[?:1.8.0_251]
at org.elasticsearch.xpack.core.XPackSettings.<clinit>(XPackSettings.java:196) [x-pack-core-7.8.1.jar:7.8.1]
I am using Java 1.8 and supporting jars along with version listed below.
elasticsearch-7.8.0.jar r
elasticsearch-cli-7.8.0.jar
elasticsearch-core-7.8.0.jar
elasticsearch-geo-7.8.0.jar
elasticsearch-nio-7.8.1.jar
elasticsearch-rest-client-7.8.1.jar
elasticsearch-secure-sm-7.8.0.jar
elasticsearch-ssl-config-7.8.1.jar
elasticsearch-x-content-7.8.0.jar
x-pack-core-7.8.1.jar
x-pack-transport-7.8.1-1.0.jar
Connection code that I am using to connect to elastic search through transport port 9300 are below.
Client client = new PreBuiltXPackTransportClient(Settings.builder().put("cluster.name",esClusterName)
.put("node.name", esNodeName)
.put("xpack.security.transport.ssl.enabled", true)
.put("request.headers.X-Found-Cluster",esClusterName)
.put("xpack.security.user", elasticSerachCred)
.put("xpack.security.transport.ssl.key", elasticSearchSSLKeyLocation)
.put("xpack.security.transport.ssl.certificate", elasticSearchSSLCertificateLocation)
.put("client.transport.sniff", false)
.build()).addTransportAddress(new TransportAddress(InetAddress.getByName(transportServerName), transportPort));
elastic search key and certificate I am using same which I have added in elasticsearch.yml file to enable security.
Note:- When I am running this connection code without through tomcat server, connection is working perfectly fine but with tomcat server it is giving this error.
So, I am confuse either I need to do some changes in tomcat side or Is there any elastic search supporting jars version mismatch causing this.
Can anyone guide me here?
Thanks
Consider this HAProxy configuration here:
global
chroot /var/lib/haproxy
user haproxy
group haproxy
defaults
timeout connect 10s
timeout client 50s
timeout server 50s
frontend fe_https_tomcat
mode tcp
bind *:443 ssl crt /path/cert.pem alpn h2,http/1.1
default_backend be_tomcat
backend be_tomcat
mode tcp
server localhost localhost:8081 check
The issue I have is that WebSocket do not seem to get through. My guess was that in tcp mode everything would pass through. Looks like it doesn't ... :-)
The server responds with an error 403 when the WebSocket connection is getting established.
Note that with the following http-mode setup, the WebSocket just works:
frontend fe_http_8080
mode http
bind *:8080
default_backend be_tomcat_8080
backend be_tomcat_8080
mode http
server localhost localhost:8081 check
Note that I need tcp-mode to have http/2 working.
The issue was not related to HAProxy at the end, but to the WebSocket setup in Spring.
This fixed it:
-registry.addHandler(webSocketHandler, "/ws");
+registry.addHandler(webSocketHandler, "/ws").setAllowedOrigins("*");
I am using haproxy for port forwarding to Bitbucket server ssh. Here's haproxy config:
frontend sshd
bind *:7999
default_backend ssh
timeout client 1h
backend ssh
mode tcp
server localhost-bitbucket-ssh 127.0.0.1:7999 check port 7999
However if i do:
sudo haproxy -f haproxy.cfg
i am getting the following error:
[ALERT] 305/201411 (4168) : http frontend 'sshd' (haproxy.cfg:38) tries to use incompatible tcp backend 'ssh' (haproxy.cfg:43) as its default backend (see 'mode').
[ALERT] 305/201411 (4168) : Fatal errors found in configuration.
But i was referring to an official atlassian guide: https://confluence.atlassian.com/bitbucketserver/setting-up-ssh-port-forwarding-776640364.html are they wrong?
Also if i start haproxy before bitbucket server, bitbucket server cannot start on port 7999. I am totally confused. I have paid for that software and now i need to figure it out myself how to configure it for more than 2 days...
UPDATE
It was UFW as Thomj mentioned. But for what purposes do i need haproxy? If i can't bind Bitbucket's ssh to 22 port? I don't like to set port number.
The frontend configuration is defaulting to a mode of http which can't use a backend that's configured for tcp. Try adding 'mode tcp' to the frontend:
frontend sshd
bind *:7999
default_backend ssh
timeout client 1h
mode tcp
I had the following error when calling a service that requests at least TLS (no SSL3 for you Poodle!).
com.ibm.websphere.sca.ServiceUnavailableException: Could not obtain a connection to the destination or Exception was happened on the connection. Failed to process the request. Unsupported record version Unknown-0.0
at com.ibm.ws.http.imprt.handler.HTTPImportService.sendHTTPRequest(HTTPImportService.java:254)
at com.ibm.ws.http.imprt.handler.HTTPImportHandler.processMessage(HTTPImportHandler.java:261)
at com.ibm.ws.sca.internal.message.impl.MessageDispatcherImpl.processMessageWithPCI(MessageDispatcherImpl.java:785)
at com.ibm.ws.sca.internal.message.impl.MessageDispatcherImpl.processMessage(MessageDispatcherImpl.java:1626)
at com.ibm.ws.sca.internal.message.impl.ManagedMessageImpl.process(ManagedMessageImpl.java:999)
at com.ibm.ws.sca.uow.handler.UOWNativeWASStrategyImpl.transactionImportExport(UOWNativeWASStrategyImpl.java:455)
at com.ibm.ws.sca.uow.handler.JoinUOWNativeHandler.processMessage(JoinUOWNativeHandler.java:168)
at com.ibm.ws.sca.internal.message.impl.MessageDispatcherImpl.processMessageWithPCI(MessageDispatcherImpl.java:785)
at com.ibm.ws.sca.internal.message.impl.MessageDispatcherImpl.processMessage(MessageDispatcherImpl.java:1626)
at com.ibm.ws.sca.internal.message.impl.ManagedMessageImpl.process(ManagedMessageImpl.java:990)
at com.ibm.ws.sibx.mediation.flowaction.impl.sca.SCAInvocationAction.invokeSync(SCAInvocationAction.java:554)
at com.ibm.ws.sibx.mediation.flowaction.impl.sca.RetryControl.invokeByStyle(RetryControl.java:379)
at com.ibm.ws.sibx.mediation.flowaction.impl.sca.RetryControl.invokeWithRetry(RetryControl.java:253)
at com.ibm.ws.sibx.mediation.flowaction.impl.sca.ServiceInvocation.complete(ServiceInvocation.java:127)
at com.ibm.ws.sibx.mediation.flowaction.impl.sca.FlowActionFactoryImpl.create(FlowActionFactoryImpl.java:750)
at com.ibm.ws.sibx.mediation.primitives.serviceinvoke.ServiceInvokeMediation.invokeFlowAction(ServiceInvokeMediation.java:651)
at com.ibm.ws.sibx.mediation.primitives.serviceinvoke.ServiceInvokeMediation.mediate(ServiceInvokeMediation.java:564)
at com.ibm.ws.sibx.scax.mediation.engine.JavaMediationPrimitive.performInvocation(JavaMediationPrimitive.java:741)
at com.ibm.ws.sibx.scax.mediation.engine.JavaMediationPrimitive.performInvocationWithCatch(JavaMediationPrimitive.java:577)
at com.ibm.ws.sibx.scax.mediation.engine.JavaMediationPrimitive.invoke(JavaMediationPrimitive.java:397)
at com.ibm.ws.sibx.scax.mediation.engine.SIBXJavaMediationPrimitive.invoke(SIBXJavaMediationPrimitive.java:108)
at com.ibm.ws.sibx.scax.mediation.engine.MediationPrimitive.invokeConnections(MediationPrimitive.java:344)
at com.ibm.ws.sibx.scax.mediation.engine.JavaMediationPrimitive.fireOutputTerminals(JavaMediationPrimitive.java:843)
at com.ibm.ws.sibx.scax.mediation.engine.JavaMediationPrimitive.performInvocation(JavaMediationPrimitive.java:763)
at com.ibm.ws.sibx.scax.mediation.engine.JavaMediationPrimitive.performInvocationWithCatch(JavaMediationPrimitive.java:577)
at com.ibm.ws.sibx.scax.mediation.engine.JavaMediationPrimitive.invoke(JavaMediationPrimitive.java:397)
at com.ibm.ws.sibx.scax.mediation.engine.MediationPrimitive.invokeConnections(MediationPrimitive.java:344)
at com.ibm.ws.sibx.scax.mediation.engine.JavaMediationPrimitive.fireOutputTerminals(JavaMediationPrimitive.java:843)
at com.ibm.ws.sibx.scax.mediation.engine.JavaMediationPrimitive.performInvocation(JavaMediationPrimitive.java:763)
at com.ibm.ws.sibx.scax.mediation.engine.JavaMediationPrimitive.performInvocationWithCatch(JavaMediationPrimitive.java:577)
at com.ibm.ws.sibx.scax.mediation.engine.JavaMediationPrimitive.invoke(JavaMediationPrimitive.java:397)
at com.ibm.ws.sibx.scax.mediation.engine.MediationPrimitive.invokeConnections(MediationPrimitive.java:344)
at com.ibm.ws.sibx.scax.mediation.engine.Input.invoke(Input.java:245)
The config was Websphere 8.0.0.7 with Websphere Process Server 8.0.1.2 and I was calling to an HTTP service using an HTTP import through https, the WAS was already using a SSL configuration with TLS (tried several options, all same error) and the ssl.client.props file is already following the IBM recommendations (tried several combinations).
Then we moved to FIPS with transitional support but another issue appeared
com.ibm.websphere.sca.ServiceUnavailableException: Could not obtain a
connection to the destination or Exception was happened on the
connection. Failed to process the request. SSL protocol cannot be
enabled in FIPS/SP800_131/suiteb mode
at com.ibm.ws.http.imprt.handler.HTTPImportService.sendHTTPRequest(HTTPImportService.java:254)
at com.ibm.ws.http.imprt.handler.HTTPImportHandler.processMessage(HTTPImportHandler.java:261)
at com.ibm.ws.sca.internal.message.impl.MessageDispatcherImpl.processMessageWithPCI(MessageDispatcherImpl.java:785)
at com.ibm.ws.sca.internal.message.impl.MessageDispatcherImpl.processMessage(MessageDispatcherImpl.java:1626)
at com.ibm.ws.sca.internal.message.impl.ManagedMessageImpl.process(ManagedMessageImpl.java:999)
at com.ibm.ws.sca.uow.handler.UOWNativeWASStrategyImpl.transactionImportExport(UOWNativeWASStrategyImpl.java:455)
at com.ibm.ws.sca.uow.handler.JoinUOWNativeHandler.processMessage(JoinUOWNativeHandler.java:168)
The problem was within the HTTP import internal component (was using SSL as a hardcoded configuration) so I wrote my own HTTP client in a custom Java and called it a day. No fix pack at that moment.