Enabling SSL configuration issue - neo4j

I am having issues enabling SSL configuration.
I walked through the guide provided on docs and searched through the other peoples posts but still cannot make it work. Therefore I kindly ask for your help :)
I am using neo4j 4.1.0 Enterprise on macOS Catalina ver. 10.15.5
When starting server I receive following error:
2020-07-06 16:54:16.837+0000 INFO Starting...
2020-07-06 16:54:24.804+0000 INFO ======== Neo4j 4.1.0 ========
2020-07-06 16:54:25.162+0000 ERROR Failed to start Neo4j on dbms.connector.http.listen_address, a socket address. If missing port or hostname it is acquired from dbms.default_listen_address. Error starting Neo4j database server at /Users/xxx/Library/Application Support/Neo4j Desktop/Application/neo4jDatabases/database-abc65513-dd91-4140-b69c-201fc2ec2aa8/installation-4.1.0/data/databases
java.lang.RuntimeException: Error starting Neo4j database server at /Users/xxx/Library/Application Support/Neo4j Desktop/Application/neo4jDatabases/database-abc65513-dd91-4140-b69c-201fc2ec2aa8/installation-4.1.0/data/databases
at org.neo4j.graphdb.facade.DatabaseManagementServiceFactory.startDatabaseServer(DatabaseManagementServiceFactory.java:198)
at org.neo4j.graphdb.facade.DatabaseManagementServiceFactory.build(DatabaseManagementServiceFactory.java:158)
at com.neo4j.server.enterprise.EnterpriseManagementServiceFactory.createManagementService(EnterpriseManagementServiceFactory.java:38)
at com.neo4j.server.enterprise.EnterpriseBootstrapper.createNeo(EnterpriseBootstrapper.java:20)
at org.neo4j.server.NeoBootstrapper.start(NeoBootstrapper.java:117)
at org.neo4j.server.NeoBootstrapper.start(NeoBootstrapper.java:87)
at com.neo4j.server.enterprise.EnterpriseEntryPoint.main(EnterpriseEntryPoint.java:25)
Caused by: org.neo4j.kernel.lifecycle.LifecycleException: Component 'org.neo4j.bolt.BoltServer#29dcdd1c' failed to initialize. Please see the attached cause exception "io.netty.internal.tcnative.SSLPrivateKeyMethod".
at org.neo4j.kernel.lifecycle.LifeSupport$LifecycleInstance.init(LifeSupport.java:424)
at org.neo4j.kernel.lifecycle.LifeSupport.init(LifeSupport.java:65)
at org.neo4j.kernel.lifecycle.LifeSupport.start(LifeSupport.java:101)
at org.neo4j.graphdb.facade.DatabaseManagementServiceFactory.startDatabaseServer(DatabaseManagementServiceFactory.java:189)
... 6 more
Caused by: java.lang.NoClassDefFoundError: io/netty/internal/tcnative/SSLPrivateKeyMethod
at io.netty.handler.ssl.SslContext.newServerContextInternal(SslContext.java:471)
at io.netty.handler.ssl.SslContextBuilder.build(SslContextBuilder.java:571)
at org.neo4j.ssl.SslPolicy.nettyServerContext(SslPolicy.java:82)
at org.neo4j.bolt.BoltServer.createSslContext(BoltServer.java:286)
at org.neo4j.bolt.BoltServer.createExternalProtocolInitializer(BoltServer.java:252)
at org.neo4j.bolt.BoltServer.init(BoltServer.java:154)
at org.neo4j.kernel.lifecycle.LifeSupport$LifecycleInstance.init(LifeSupport.java:403)
... 9 more
Caused by: java.lang.ClassNotFoundException: io.netty.internal.tcnative.SSLPrivateKeyMethod
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
... 16 more
2020-07-06 16:54:25.162+0000 INFO Neo4j Server shutdown initiated by request
Server fails to start when line dbms.connector.bolt.tls_level=OPTIONAL is uncommented.
If I am not mistaken it is related to io/netty/internal/tcnative/SSLPrivateKeyMethod
I spent much time trying to figure out what is the problem and I have no clue how to proceed anymore.
I generated self-signed certificate with command:
openssl req \
-newkey rsa:2048 -nodes -keyout private.key \
-x509 -days 365 -out public.crt
certificate folder structure is following
└── default
├── private.key
├── public.crt
├── revoked
└── trusted
plugins are following:
netty-all-4.1.50.Final-sources.jar
netty-all-4.1.50.Final.jar
My configuration neo4j.conf is following:
#*****************************************************************
# Neo4j configuration
#
# For more details and a complete list of settings, please see
# https://neo4j.com/docs/operations-manual/current/reference/configuration-settings/
#*****************************************************************
# This setting constrains all `LOAD CSV` import files to be under the `import` directory. Remove or comment it out to
# allow files to be loaded from anywhere in the filesystem; this introduces possible security problems. See the
# `LOAD CSV` section of the manual for details.
dbms.directories.import=import
# Whether requests to Neo4j are authenticated.
# To disable authentication, uncomment this line
dbms.security.auth_enabled=true
#********************************************************************
# Memory Settings
#********************************************************************
# Java Heap Size: by default the Java heap size is dynamically calculated based
# on available system resources. Uncomment these lines to set specific initial
# and maximum heap size.
dbms.memory.heap.initial_size=512m
dbms.memory.heap.max_size=1G
# The amount of memory to use for mapping the store files.
# The default page cache memory assumes the machine is dedicated to running
# Neo4j, and is heuristically set to 50% of RAM minus the Java heap size.
dbms.memory.pagecache.size=512m
# Transaction state location. It is recommended to use ON_HEAP.
dbms.tx_state.memory_allocation=ON_HEAP
#*****************************************************************
# Network connector configuration
#*****************************************************************
# With default configuration Neo4j only accepts local connections.
# To accept non-local connections, uncomment this line:
dbms.default_listen_address=0.0.0.0
# Bolt connector
dbms.connector.bolt.enabled=true
dbms.connector.bolt.tls_level=OPTIONAL
#dbms.connector.bolt.listen_address=:7687
#dbms.connector.bolt.advertised_address=localhost:9000
# HTTP Connector. There can be zero or one HTTP connectors.
dbms.connector.http.enabled=true
#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=:7473
#*****************************************************************
# SSL policy configuration
#*****************************************************************
# Bolt SSL configuration
dbms.ssl.policy.bolt.enabled=true
dbms.ssl.policy.bolt.base_directory=certificates/default
dbms.ssl.policy.bolt.private_key=private.key
dbms.ssl.policy.bolt.public_certificate=public.crt
dbms.ssl.policy.bolt.client_auth=NONE
dbms.ssl.policy.bolt.trust_all=true
# Https SSL configuration
dbms.ssl.policy.https.enabled=true
dbms.ssl.policy.https.base_directory=certificates/default
dbms.ssl.policy.https.private_key=private.key
dbms.ssl.policy.https.public_certificate=public.crt
dbms.ssl.policy.https.client_auth=NONE
dbms.ssl.policy.https.trust_all=true
#*****************************************************************
# Miscellaneous configuration
#*****************************************************************
# A comma separated list of procedures and user defined functions that are allowed
# full access to the database through unsupported/insecure internal APIs.
dbms.security.procedures.unrestricted=apoc.*
#********************************************************************
# JVM Parameters
#********************************************************************
# G1GC generally strikes a good balance between throughput and tail
# latency, without too much tuning.
dbms.jvm.additional=-XX:+UseG1GC
# Have common exceptions keep producing stack traces, so they can be
# debugged regardless of how often logs are rotated.
dbms.jvm.additional=-XX:-OmitStackTraceInFastThrow
# Make sure that `initmemory` is not only allocated, but committed to
# the process, before starting the database. This reduces memory
# fragmentation, increasing the effectiveness of transparent huge
# pages. It also reduces the possibility of seeing performance drop
# due to heap-growing GC events, where a decrease in available page
# cache leads to an increase in mean IO response time.
# Try reducing the heap memory, if this flag degrades performance.
dbms.jvm.additional=-XX:+AlwaysPreTouch
# Trust that non-static final fields are really final.
# This allows more optimizations and improves overall performance.
# NOTE: Disable this if you use embedded mode, or have extensions or dependencies that may use reflection or
# serialization to change the value of final fields!
dbms.jvm.additional=-XX:+UnlockExperimentalVMOptions
dbms.jvm.additional=-XX:+TrustFinalNonStaticFields
# Disable explicit garbage collection, which is occasionally invoked by the JDK itself.
dbms.jvm.additional=-XX:+DisableExplicitGC
#Increase maximum number of nested calls that are can be inlined from 9 (default) to 15
dbms.jvm.additional=-XX:MaxInlineLevel=15
# Restrict size of cached JDK buffers to 256 KB
dbms.jvm.additional=-Djdk.nio.maxCachedBufferSize=262144
# More efficient buffer allocation in Netty by allowing direct no cleaner buffers.
dbms.jvm.additional=-Dio.netty.tryReflectionSetAccessible=true
# Expand Diffie Hellman (DH) key size from default 1024 to 2048 for DH-RSA cipher suites used in server TLS handshakes.
# This is to protect the server from any potential passive eavesdropping.
dbms.jvm.additional=-Djdk.tls.ephemeralDHKeySize=2048
# This mitigates a DDoS vector.
dbms.jvm.additional=-Djdk.tls.rejectClientInitiatedRenegotiation=true
# Increase the default flight recorder stack sampling depth from 64 to 256, to avoid truncating frames when profiling.
dbms.jvm.additional=-XX:FlightRecorderOptions=stackdepth=256
# Allow profilers to sample between safepoints. Without this, sampling profilers may produce less accurate results.
dbms.jvm.additional=-XX:+UnlockDiagnosticVMOptions
dbms.jvm.additional=-XX:+DebugNonSafepoints
#********************************************************************
# Wrapper Windows NT/2000/XP Service Properties
#********************************************************************
# WARNING - Do not modify any of these properties when an application
# using this configuration file has been installed as a service.
# Please uninstall the service before modifying this section. The
# service can then be reinstalled.
# Name of the service
dbms.windows_service_name=neo4j
#********************************************************************
# Other Neo4j system properties
#********************************************************************
dbms.netty.ssl.provider=OPENSSL
Does anyone have clue what is the reason for my issues?

The error log is saying that the class SSLPrivateKeyMethod is not found. The error is not related to the content of the certificate.
Check the classpath that Neo4j Server refers to. For example, check if netty-all-4.1.50.Final.jar contains the SSLPrivateKeyMethod class.

What worked for me was replacing
netty-all-4.1.50.Final-sources.jar
netty-all-4.1.50.Final.jar
with
netty-tcnative-2.0.31.Final-osx-x86_64.jar
netty-tcnative-2.0.31.Final-sources.jar

Related

WampServer Hosts file not exit

There is a problem with my wamp server after i install it. However, my wamp server still as normal but may i know how to correct this errors?
errors as below:
The file: C:/WINDOWS/system32/drivers/etc/hosts is not writable
The file C:/WINDOWS/system32/drivers/etc/hosts does not exists
May i know how to correct it ?
Check this C:/WINDOWS/system32/drivers/etc path, your hosts file is probably missing. Just follow these steps to fix the problem.
Create new text file on desktop and rename it to "hosts". Don't add extension.
Open it with any text editor, paste the following code and save it.
# Copyright (c) 1993-2006 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host
# localhost name resolution is handle within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
Now move the file to C:/WINDOWS/system32/drivers/etc folder.
Exit WAMP if its running and start it again. The error will be gone.
for more detail checkout Microsoft support article here: https://support.microsoft.com/en-us/help/972034/how-to-reset-the-hosts-file-back-to-the-default

Can I have 2 independent installations of InfluxDB?

I want to run two separate and independent instances/installations of InfluxDB on the same machine (running on ubuntu). They should have different endpoints.
Is it possible? How do you do it?
Yes you can, just provide required configuration in corresponding influxdb.conf for each installation. The following attributes must be reconfigured to reference different targets:
Different data, wal and meta storage directories:
[data]
# The directory where the TSM storage engine stores TSM files.
dir = "/var/lib/influxdb/data"
# The directory where the TSM storage engine stores WAL files.
wal-dir = "/var/lib/influxdb/wal"
[meta]
# Where the metadata/raft database is stored
dir = "/var/lib/influxdb/meta"
Different HTTP (UDP) ports:
[http]
# Determines whether HTTP endpoint is enabled.
enabled = true
# The bind address used by the HTTP service.
bind-address = ":8086"
[[udp]]
enabled = false
bind-address = ":8089"
Also take a look, at other configuration settings to see if they not conflict.

Disable SSLv3 on Orbix 6.3 services

What is the correct way to disable SSLv3 on Orbix 6.3 services? I am new to Orbix and I was recently given an environment to support on one of our servers. My task is to disable SSLv3 which is still supported on the environment.
Per the documentation on the linkbelow, I have updated the .cfg files within our domains to include the following lines:
policies:iiop_tls:mechanism_policy:protocol_version = ["TLS_V1_2"];
policies:https:mechanism_policy:protocol_version = ["TLS_V1_2"];
Our environment consists of two configuration domains.
When I make the changes to the first domain, for the config_rep, the changes work and SSLv3 is disabled as expected.
When I make the changes to the second domain, for the locator, node_daemon and naming services. SSLv3 is still enabled.
Verified with the command line: openssl s_client -connect localhost:3077 -ssl3 reports back with Secure Renegotiation IS supported
The .cfg domain files are nearly identical.
https://community.microfocus.com/microfocus/corba/visibroker_-_world_class_middleware/w/knowledge_base/28339/best-practices-for-implementing-security-using-micro-focus-corba-products
I was eventually able to figure this out.
It turns out that Orbix can have configurations that are already loaded into their database. In my example, one of the configuration files wasn't being loaded. If the configuration file isn't being used. you can update the TLS value of your Orbix service with the following Orbix command:
./itadmin variable modify -type string -value "1.1" policies:iiop:server_version_policy
Once this command is entered, it will force your Orbix service to TLS 1.1 and higher

APOC: unavailable namespaces

Just added apoc to a neo4j installation. As a result, got access to the namespaces apoc.coll and apoc.load only. Can't even do basic stuff like RETURN apoc.version().
The jar in the plugins directory contains much more than that, but in the localhost browser, I can't see anything but the above. Both apoc and neo4j version 3.3.
Before editing the config file, apoc was totally unavailable. Additions to config:
dbms.security.procedures.whitelist=apoc.coll.*,apoc.load.*
dbms.security.procedures.unrestricted=apoc.coll.*,apoc.load.*
dbms.security.procedures.whitelist=apoc.algo.*,apoc.atomic.*
dbms.security.procedures.unrestricted=apoc.algo.*,apoc.atomic.*
dbms.security.procedures.whitelist=apoc.trigger.*,apoc.meta.*
dbms.security.procedures.unrestricted=apoc.trigger.*,apoc.meta.*
dbms.security.procedures.whitelist=apoc.*
dbms.security.procedures.unrestricted=apoc.*
apoc.trigger.enabled=true
apoc.ttl.enabled=true
apoc.ttl.schedule=5
apoc.import.file.use_neo4j_config=true
apoc.import.file.enabled=true
apoc.export.file.enabled=true
# apoc.jdbc.<key>.uri=jdbc-url-with-credentials
# apoc.es.<key>.uri=es-url-with-credentials
# apoc.mongodb.<key>.uri=mongodb-url-with-credentials
# apoc.couchbase.<key>.uri=couchbase-url-with-credentials
apoc.jobs.scheduled.num_threads=number-of-threads
apoc.jobs.default.num_threads=number-of-threads
I added 'algo' and 'atomic' as an experiment, as I was thinking that I could see 'load' and 'coll' simply because they were declared in the config. But no - didn't help.
Restarted neo4j and rebooted the machine repeatedly.

jetty 9: setting up the most basic SSL / https

NOTE: If you want to see the behaviour of this demo app, just go to www.collaborativepowernowinternational.us. Here, select the testssl.PersonController, and you may create a person. Then go and edit the person, where the SSL channel is designated, which will give a redirect loop.
It seems like with Jetty 9 more configuration items went into the start.ini file, I have version 9.05.
In order to test the most basic SSL/https, I am uncommenting the following lines in start.ini:
#===========================================================
# SSL Context
# Create the keystore and trust store for use by
# HTTPS and SPDY
#-----------------------------------------------------------
jetty.keystore=etc/keystore
jetty.keystore.password=OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4
jetty.keymanager.password=OBF:1u2u1wml1z7s1z7a1wnl1u2g
jetty.truststore=etc/keystore
jetty.truststore.password=OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4
jetty.secure.port=8443
etc/jetty-ssl.xml
#===========================================================
# HTTPS Connector
# Must be used with jetty-ssl.xml
#-----------------------------------------------------------
jetty.https.port=8443
etc/jetty-https.xml
No other Jetty configuration changes. I then built the most basic Grails app (has a Person class) where I set certain controller actions to secure, which works fine on my development machine using an older built in Jetty version (that Grails includes). This is done simply by including spring-security-core and then adding the following lines to a configuration file:
grails.plugins.springsecurity.secureChannel.definition = [
'/person/list': 'REQUIRES_INSECURE_CHANNEL',
'/person/delete/**': 'REQUIRES_SECURE_CHANNEL',
'/person/edit/**': 'REQUIRES_SECURE_CHANNEL',
'/person/show': 'REQUIRES_INSECURE_CHANNEL'
]
grails.plugins.springsecurity.portMapper.httpPort=80
grails.plugins.springsecurity.portMapper.httpsPort=443
When I access the person/edit action I get a redirect loop in the browser (using deployed WAR file to Jetty 9 on dedicated CentOs 6 machine). This is using the provided keystore that comes with Jetty 9, just uncommenting the lines in start.ini to use it.
The main Jetty SSL configuration page I'm reading is here. What isn't clear to me is, is updating the start.ini file enough? If not, how exactly does one add the lines in jetty-https.xml described in this previous link, i.e. the lines:
<New id="sslContextFactory" class="org.eclipse.jetty.util.ssl.SslContextFactory">
<Set name="KeyStorePath"><Property name="jetty.home" default="." />/etc/keystore</Set>
<Set name="KeyStorePassword">OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4</Set>
<Set name="KeyManagerPassword">OBF:1u2u1wml1z7s1z7a1wnl1u2g</Set>
<Set name="TrustStorePath"><Property name="jetty.home" default="." />/etc/keystore</Set>
<Set name="TrustStorePassword">OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4</Set>
</New>
Not sure how to add them, but they also seem a duplicate of the start.ini file lines above.
Can you please help help me get the most basic Jetty SSL running? Thanks much.
If not familiar with Grails, one can simply download it, then create a domain class -- there is a command line option for this. Then give it fields String firstName, String lastName. Then there are commands to generate a controller and views for it -- this is all totally automatic. Then one adds the plugin, spring-security-core. In chapter 16/17 of this doc and as I have shown, when lists which controller actions are secure, such as person/edit.
You actually have enough here for just the Jetty portion of this to be working using the default trial keystore we ship in Jetty 9.0.6 distribution.
Simply the blurb you have above is enough to make SSL work within Jetty. I downloaded the 9.0.6 distribution and uncommented those lines and it works. Well, I had to go into the start.d/demo.ini file and remove the last two lines with etc/jetty-ssl.xml and etc/jetty-https.xml because they would get run twice...but I digress.
If you start up Jetty you can navigate to https://localhost:8443 and it will complain about being an untrusted certificate and then load up the jetty distribution page.
Based on that I would say this is likely some sort of grails configuration issue that I sadly don't know the answer too, sorry.
Starting Jetty 9.1, things have changed, and you have to follow the instructions in here for things to look correct, per Jetty developers. Moreover, you are not supposed to change/delete/edit anything in ${jetty.home}'s directories. Here's what you need to do for a self-signed certificate based SSL/HTTPS on Jetty 9.1+:
(a) set up your environment variable $JETTY_HOME to point to where you installed your jetty tar bundle, say /opt/jetty/.
(b) Create a new directory, /tmp/myJettyApp, point it to $JETTY_BASE in your environment.
(c) cd to $JETTY_BASE
(d) Follow instructions in here:
/home/sonny $ cd $JETTY_BASE
/tmp/myJettyApp/ $ java -jar $JETTY_HOME/start.jar --add-to-startd=https,http2
(e) Set your port if you'd like:
/home/sonny $ cd $JETTY_BASE;
/tmp/myJettyApp/ $ java -jar $JETTY_HOME/start.jar jetty.ssl.port=8444
(f) And now, run jetty:
/tmp/myJettyApp/ $ java -jar $JETTY_HOME/start.jar
you will see that HTTPS is running at port 8444. Now, if you want to make jetty listen in the traditional HTTPS port, you have to use sudo to run:
/tmp/myJettyApp/ $ java -jar $JETTY_HOME/start.jar jetty.ssl.port=443
/tmp/myJettyApp/ $ sudo java -jar $JETTY_HOME/start.jar
Note that this already does the self-signed certs etc. automagically.
Now, if you want to generate your own self-signed certificate (say, because you want to modify the validity to an arbitrary large or small value, depending on your needs), follow the instructions in here, generate a new self-signed cert using keytool and then place it in $JETTY_BASE/etc/ and modify the $JETTY_BASE/start.d/ssl.ini for jetty.sslContext.keyStorePassword and jetty.sslContext.keyManagerPassword respectively. BTW, for the last two ssl.ini passwords, you can use the obfuscated plain text password you used when you ran keytool or use the plain text ones. If you want to obfuscate them, run {jetty.home} $ java -cp lib/jetty-util-9.3.6.v20151106.jar org.eclipse.jetty.util.security.Password "MyInterestingAndAwesomePassword"
Hope this helps someone.

Resources