I have configured Neo4j to use encrypted connections bith with https in browser and bolt protocol. I have a valid certificate signed with a CA and the browser works fine accessing and runnign queries. Then problem comes with the cypher shell through bolt protocol. I'm getting this error:
cypher-shell --encryption true -d database -a bolt://ip_address:7687 -u user -p password--debug
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
at java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
at java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297)
at java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:380)
... 42 more
Both https and bolt use the same certificate and private key. The TLS configuration is:
# Bolt SSL configuration
dbms.ssl.policy.bolt.enabled=true
dbms.ssl.policy.bolt.base_directory=certificates/bolt
dbms.ssl.policy.bolt.private_key=neo4j.key
dbms.ssl.policy.bolt.public_certificate=neo4j.crt
# Https SSL configuration dbms.ssl.policy.https.enabled=true
dbms.ssl.policy.https.base_directory=certificates/https
dbms.ssl.policy.https.private_key=neo4j.key
dbms.ssl.policy.https.public_certificate=neo4j.crt
# Bolt connector
dbms.connector.bolt.enabled=true
dbms.connector.bolt.tls_level=REQUIRED
#dbms.connector.bolt.listen_address=0.0.0.0:7687
# HTTP Connector. There can be zero or one HTTP connectors. dbms.connector.http.enabled=false
#dbms.connector.http.listen_address=:7474
# HTTPS Connector. There can be zero or one HTTPS connectors.
dbms.connector.https.enabled=true
#dbms.connector.https.listen_address=0.0.0.0:7473
I'm using Neo4j 4.0.3 community version.
How can I solve thsi problem to use bolt protocol?
Use either
cypher-shell -u user -p password --debug -a host --encryption true
Or
cypher-shell -u user -p password --debug -a bolt+s://host
Related
I ran a WSO2 service using docker and I followed all instructions according to the WSO2's document and everything worked fine including it's own Hello-world API. Next I have created my own Hello World API on my local machine on port :8082. I have set both Production Endpoint and Sanbox Endpoint to http://localhost:8082 but everytime I try to test the api it gives the following error:
Failed to fetch.
Possible Reasons:
CORS
Network Failure
URL scheme must be "http" or "https" for CORS request.
Update:
I replaced localhost with my machine IP and used netcat on my local and telnet on the container to check it and it was okay. I don't know what is my next step.Is there anything specific that I should consider for developing my Hello World that I'm missing?
I assume both your API GW and Backend API run with the same hostname, which creates SSL failure, so I recommend you create a new key store for your backend and export the key store as a certificate and import it into the trust store of API GW.
keytool -keystore backend.jks -genkey -alias backend
keytool -export -keystore backend.jks -alias backend -file backend.crt
keytool -import -file backend.crt -alias backend -keystore <APIM_HOME>/repository/resources/security/client-truststore.jks
This enables the Gateway to trust the backend server (host) and enables you to communicate seamlessly.
Thanks.
I have an OpenLDAP Docker instance from Osixia and am trying to query it securely from the client using TLS. The query works without encryption using $ ldapwhoami -H ldap://localhost -x and does not work when using the -ZZ flag to start TLS operation $ ldapwhoami -H ldap://localhost -x -ZZ - it returns ldap_start_tls: Can't contact LDAP server (-1). How can i make this work? Below are all the steps i took:
Run LDAP server in docker:
$ docker run -p 389:389 -p 636:636 --name ldap-service --hostname ldap-service \
--env LDAP_ADMIN_PASSWORD="password" --env LDAP_BASE_DN="dc=example,dc=org" --detach osixia/openldap:1.4.0
Test Connectivity - shows success, it returns anonymous
$ ldapwhoami -H ldap://localhost -x
anonymous
Preparations for TLS connectivity - Configure client to trust SERVER Certificate Authority (CA)
SERVER DOCKER CONTAINER: TLS certs are autoconfigured upon runtime in the osixia/openldap image. Copy contents of CA in /container/service/slapd/assets/certs/ca.crt
CLIENT: Paste the copied SERVER ca.crt into CLIENT folder /usr/local/share/ca-certificates/ca.crt , then run sudo update-ca-certificates to add it. Confirm success of adding by checking that the CA is inside /etc/ssl/certs/ca-certificates.crt
CLIENT: In file/etc/ldap/ldap.conf I added the line TLS_CACERT /etc/ssl/certs/ca-certificates.crt
Test TLS connectivity from CLIENT via -ZZ flag to start TLS operation:
$ ldapwhoami -H ldap://localhost -x -ZZ
ldap_start_tls: Can't contact LDAP server (-1)
additional info: The TLS connection was non-properly terminated.
Further logs from inside LDAP docker:
5ff42195 conn=1079 fd=12 ACCEPT from IP=172.17.0.1:39420 (IP=0.0.0.0:636)
TLS: can't accept: No certificate was found..
5ff42195 conn=1079 fd=12 closed (TLS negotiation failure)
Test TLS connectivity from CLIENT via LDAP Secure URI scheme ldaps://
$ ldapwhoami -H ldaps://localhost -x
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
Things i tried out:
I read through https://www.openldap.org/doc/admin24/tls.html and subsequently installed the Server CA on the client.
I read through this post: ldapsearch over ssl/tls doesn't work, I changed the settings in /etc/ldap/ldap.conf to include the below items, but to no avail.
TLS_CACERT /etc/ssl/certs/ca-certificates.crt
TLS_REQCERT ALLOW
PORT 636
HOST localhost // i also tried 'ldap-service'
I found the solution:
Add --env LDAP_TLS_VERIFY_CLIENT=try to the docker run command. Source
For Googlers,
Presto does not supply client certificates (client certificate verification, two-way verification) when connecting to LDAP service, so you will need --env LDAP_TLS_VERIFY_CLIENT=tryor never if you use osixia/openldap, or, edit ldap.conf and set TLS_REQCERT never and restart the LDAP service.
Background
I setup and configured VerneMQ Broker. Broker is in docker container and I start it using docker-compose.yml. This is how my docker-compose file looks:
version: '3.3'
services:
db:
image: erlio/docker-vernemq
container_name: vernemq1
network_mode: docker_mysql_default
restart: always
environment:
DOCKER_VERNEMQ_ALLOW_ANONYMOUS: 'off'
DOCKER_VERNEMQ_PLUGINS.vmq_diversity: 'on'
DOCKER_VERNEMQ_PLUGINS.vmq_passwd: 'off'
DOCKER_VERNEMQ_PLUGINS.vmq_acl: 'off'
DOCKER_VERNEMQ_VMQ_DIVERSITY.auth_mysql.enabled: 'on'
DOCKER_VERNEMQ_VMQ_DIVERSITY.mysql.host: 'docker_mysql'
DOCKER_VERNEMQ_VMQ_DIVERSITY.mysql.port: '3306'
DOCKER_VERNEMQ_VMQ_DIVERSITY.mysql.user: 'vernemq'
DOCKER_VERNEMQ_VMQ_DIVERSITY.mysql.password: 'vernemq'
DOCKER_VERNEMQ_VMQ_DIVERSITY.mysql.database: 'vernemq_db'
DOCKER_VERNEMQ_VMQ_DIVERSITY.mysql.password_hash_method: 'md5'
DOCKER_VERNEMQ_LISTENER__SSL__CAFILE: '/vernemq/etc/ssl/chain.pem'
DOCKER_VERNEMQ_LISTENER__SSL__CERTFILE: '/vernemq/etc/ssl/cert.pem'
DOCKER_VERNEMQ_LISTENER__SSL__KEYFILE: '/vernemq/etc/ssl/privkey.pem'
DOCKER_VERNEMQ_LISTENER__SSL__DEFAULT: '0.0.0.0:8081'
DOCKER_VERNEMQ_LISTENER__SSL__DEFAULT__USE_IDENTITY_AS_USERNAME: 'off'
DOCKER_VERNEMQ_LISTENER__SSL__DEFAULT__REQUIRE_CERTIFICATE: 'off'
ports:
# <Port exposed> : <Port running inside container>
- '1883:1883'
- '8081:8081'
expose:
# Opens port 1883 on the container
- '1883'
- '8081'
# Where our data will be persisted
volumes:
- /var/lib/
- /home/ubuntu/etc/ssl:/vernemq/etc/ssl
# Name our volume
volumes:
my-db:
I am using MySQL database for authentication
I am trying to use TLS certificates, based on the provided documentation ( https://docs.vernemq.com/configuration/listeners#sample-ssl-config )
This setup is fully functional when I'm not trying to accept SSL connections (this means, when I remove the following lines from docker-compose.yml):
DOCKER_VERNEMQ_LISTENER__SSL__CAFILE: '/vernemq/etc/ssl/chain.pem'
DOCKER_VERNEMQ_LISTENER__SSL__CERTFILE: '/vernemq/etc/ssl/cert.pem'
DOCKER_VERNEMQ_LISTENER__SSL__KEYFILE: '/vernemq/etc/ssl/privkey.pem'
DOCKER_VERNEMQ_LISTENER__SSL__DEFAULT: '0.0.0.0:8081'
DOCKER_VERNEMQ_LISTENER__SSL__DEFAULT__USE_IDENTITY_AS_USERNAME: 'off'
DOCKER_VERNEMQ_LISTENER__SSL__DEFAULT__REQUIRE_CERTIFICATE: 'off'
I tested/verified the TLS connection using openssl client:
openssl s_client -connect 172.18.0.4:8081 -key privkey.pem -cert cert.pem
I executed this from server localhost, 172.18.0.4 is the IP Address of vernemq docker container, 8081 is the expected SSL default port (listener) and key/cert are provided
and this is the outcome (I suppose it means the TLS listener works):
Question
How can I test this using mosquitto client or any other mqtt client?
I want to use TLS based connection when publishing and subscribing.
When I don't use TLS, this is how I execute mosquitto_sub (subscription client):
mosquitto_sub -h <ip_address> -p 1883 -t topic -d -u user -P password -i client-id
This is the response:
VerneMQ Subscription
When I try to use TLS, I add the --key and --cert options to use private key and certificate:
mosquitto_sub -h <ip_address> -p 1883 -t topic -d -u user -P password -i client-id --key privkey.pem --cert cert.pem
I only get
Client user sending CONNECT
repeatedly. What am I doing wrong?
some things you need to do give correct permissions to your certificate directory you need to ensure the permission set to the user running verneMQ in my case its "vernemq" now next things is to setup the permissions to certificate folder
chown -R vernemq:vernemq /etc/letsencrypt/live
All the configurations files should be in .pem format
listener.ssl.cafile = /etc/letsencrypt/live/mqtts.domain.com/chain.pem
listener.ssl.certfile = /etc/letsencrypt/live/mqtts.domain.com/cert.pem
listener.ssl.keyfile = /etc/letsencrypt/live/mqtts.domain.com/privkey.pem
Client must use Fullchain.pem to connect to Server if you do not have
The domain certificate is issued by intermediate “Let’s Encrypt Authority X3”, this intermediate is cross-signed by “DST Root CA X3” (from IdenTrust). IdenTrust is widely trusted by most OSes and applications, we will “DST Root CA X3” as root CA.
if you are not on too old OS then you could use this from your local machine
cat /etc/ssl/certs/DST_Root_CA_X3.pem /etc/letsencrypt/live/$domain/chain.pem > ca.pem
From the mosquitto_sub man page:
Encrypted Connections
mosquitto_sub supports TLS encrypted connections. It is strongly
recommended that you use an encrypted connection for anything more
than the most basic setup.
To enable TLS connections when using x509 certificates, one of either
--cafile or --capath must be provided as an option.
--capath
Define the path to a directory containing PEM encoded CA certificates that are trusted. Used to enable SSL communication.
For --capath to work correctly, the certificate files must have ".crt" as the file ending and you must run "openssl rehash " each time you add/remove a certificate.
To use the mosquitto_sub command you must supply either a file with the trusted CA certificate or a directory holding a collection of trusted CA certificates
I have this setup
in Remote server. I tried
mosquitto_sub -h 127.0.0.1 -t 'myTopic' -i 'myId'
in My computer I tried
mosquitto_pub -h 'remote_ip_here' -t 'myTopic' -m 'the message'
the remote server was able to get the message I published from my computer
the remote server has these keys
certificate file = cert.pem
certificate key file = privkey.pem
certification chain file = chain.pem
If I want to have a ssl/tls communication between my computer and the remote computer.
- How do I use those keys ?
- Am I suppose to copy those keys from the remote computer and put them also in my computer ?
- can someone please help what's the proper command to execute in order to have an ssl and tls communication.
In the remote server I tried
mosquitto_sub -h 127.0.0.1 -t 'myTopic' -i 'myId' --capath /etc/myPemPath -p 1883
While in my computer, I tried
mosquitto_pub -h remote_ip -t 'myTopic' -m 'the message' --capath /etc/localPemPath -p 1883
it didn't work, so how ?
You seem to have miss understood how MQTT works. Both mosquitto_sub and mosquitto_pub are MQTT clients which communicate with a MQTT broker (mosquitto). It is not a direct client/server relationship.
In order to have TLS secured MQTT connection you first need to configure the broker to use the certificates to identify it's self, then configure the clients to verify that certificate as part of the TLS handshake.
The mosquitto documentation on how to configure TLS is available here. You need to add either a cafile or capath and certfile and keyfile options to your mosquitto.conf file. Be aware that TLS settings apply to the last listener configured, so you will probably need to set up a new listener on a different port to 1883.
As for the clients, assuming you are not doing mutual authenticated TLS then you only need to pass the -cafile/-capath option to mosquitto_pub and mosquitto_sub to enable a TLS session.
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0 "Internal error/check (Not system error)"
· The OS is debian 8.
· Cloud SQL and Compute Engine are identical projects.
· The Compute Engine instance has full API access rights.
· We also set up Cloud SQL Admin.
sudo apt-get update
sudo apt-get install mysql-client
wget https://dl.google.com/cloudsql/cloud_sql_proxy.linux.amd64 -O cloud_sql_proxy
chmod +x cloud_sql_proxy
Connection is OK.
mysql --host=[INSTANCE_IP_ADDR] --user=root --password
TCP socket
./cloud_sql_proxy -instances==tcp:3306
The following error occurs.
$ mysql -u root -p --host 127.0.0.1 --port 3306
Enter password:
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0 "Internal error/check (Not system error)"
2018/07/24 06:57:43 Listening on 127.0.0.1:3306 for xxxxxx:asia-east1:xxxxxx
2018/07/24 06:57:43 Ready for new connections
2018/07/24 06:59:16 New connection for "xxxxxxx:asia-east1:xxxxxx"
2018/07/24 06:59:17 couldn't connect to "xxxxxxx:asia-east1:xxxxx": x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "Google Cloud SQL Server CA")
I can not solve the connection error, I am in trouble.
Help me.
Thank you for your instruction.
I tried using the credential_file option, but a similar error occurs.
sudo vi xxxxx917672.json
./cloud_sql_proxy -instances=xxxxxx:asia-east1:xxxxxx:3306 -credential_file=xxxxxxxxx917672.json
$ ./cloud_sql_proxy -instances=xxxxxx:asia-east1:xxxxxxx=tcp:3306 -credential_file=xxxxxxx917672.json
2018/07/24 09:23:48 using credential file for authentication; email=xxxxxxxxx#developer.gserviceaccount.com
2018/07/24 09:23:48 Listening on 127.0.0.1:3306 for v
$ mysql -u root -p --host 127.0.0.1 --port 3306
Enter password:
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0
2018/07/24 09:25:57 New connection for "xxxxxx:asia-east1:xxxxxxx"
2018/07/24 09:25:58 couldn't connect to "xxxxx:asia-east1:xxxxxxx": x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "Google Cloud SQL Server CA")
Compute Engine default service account, because the key was not created, the key is created and executed by json.
Also, from the details of Compute Engine's VM instance, we confirm permission to service account and full access right to all Cloud APIs.
Is there anything wrong with the setting?
It's necessary to provide credentials to the proxy. Take a look at:
https://cloud.google.com/sql/docs/mysql/sql-proxy#authentication-options
I've had the same problem with "certificate signed by unknown authority" after MySQL update in GCP.
What helped in my case was to reset SSL configuration (Google Cloud Console -> SQL -> choose instance -> CONNECTIONS (tab) -> Reset SSL configuration). After that everything was as before the update.
Before I've tried that, I had also generated a new certificate for service account used to connect to the instance but this single change alone did not helped.
Change the timeout connection in haproxy.cfg from 3500ms to 5s.