SSL framework

Describes how to set up SSL within your environment, how to view, validate, and test the certificates.

The SSL framework provides support for securing the following Neo4j communication channels using standard SSL/TLS technology:

  • bolt (port - 7687)

  • https (port - 7473)

  • cluster (ports - 5000, 6000, and 7000)

  • backups (port - 6362)

1. SSL providers

The secure networking in Neo4j is provided through the Netty library, which supports both the native JDK SSL provider as well as Netty-supported OpenSSL derivatives.

Follow these steps to use OpenSSL:

  1. Install a suitable dependency into the plugins/ folder of Neo4j. Dependencies can be downloaded from https://netty.io/wiki/forked-tomcat-native.html.

  2. Set dbms.netty.ssl.provider=OPENSSL.

Using OpenSSL can significantly improve performance, especially for AES-GCM-cryptos, e.g. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.

2. Certificates

The SSL configuration requires SSL certificates to be issued by Certificate Authority (CA). All Certificates and the private key must be in PEM format.

If the same certificates are used across all instances of the cluster, make sure that when generating the certificates to include the DNS names of all the cluster instances in the certificates. Multi-host and wildcard certificates are also supported.

The instructions on this page assume that you have already obtained the required certificates from the CA.

2.1. Validate the key and the certificate

If you need, you can validate the key file and the certificate as follows:

Validate the key
openssl rsa -in private.key -check
Validate certificate in the PEM format
PEM - $openssl x509 -in public.crt –text –noout
DER - $openssl x509 -in certificate.der -inform der -text -noout

2.2. Transform the certificates

Neo4j requires all SSL certificates to be in the PEM format. If your certificate is in the DER format, you must transform it into PEM format.

Transform DER format certificate to PEM format
openssl x509 -in cert.crt -inform der -outform pem -out cert.pem
Transform PEM format certificate to DER format
openssl x509 -in cert.crt -outform der -out cert.der

3. Connectors

Before enabling SSL support, you must ensure the following connector configurations to avoid errors:

  • Set dbms.connector.https.enabled to true when using HTTPS.

  • Set dbms.connector.bolt.tls_level to REQUIRED or OPTIONAL when using Bolt.

For more information on configuring connectors, see Configure connectors.

4. Configuration

The SSL policies are configured by assigning values to parameters of the following format:

dbms.ssl.policy.<scope>.<setting-suffix>

  • scope is the name of the communication channel, such as bolt, https, cluster, backup, and fabric.

  • setting-suffix can be any of the following:

    Setting suffix Description Default value

    Basic

    enabled

    Setting this to true enables this policy.

    false

    base_directory

    The base directory under which <term-ssl-cryptographic-objects, cryptographic objects>> are searched for by default.

    certificates/<scope>

    private_key

    The private key used for authenticating and securing this instance.

    private.key

    private_key_password

    The passphrase to decode the private key. Only applicable for encrypted private keys.

    public_certificate

    A public certificate matching the private key signed by a CA.

    public.crt

    trusted_dir

    A directory populated with certificates of trusted parties.

    trusted/

    revoked_dir

    A directory populated with certificate revocation lists (CRLs).

    revoked/

    Advanced

    verify_hostname

    Enabling this setting turns on client-side hostname verification. After receiving the server’s public certificate, the client compares the address it uses against the certificate Common Name (CN) and Subject Alternative Names (SAN) fields. If the address does not match those fields, the client disconnects.

    false

    ciphers

    A comma-separated list of ciphers suits allowed during cipher negotiation. Valid values depend on the current JRE and SSL provider. For Ciphers supported by the Oracle JRE, see the Oracle official documentation.

    Java platform default allowed cipher suites.

    tls_versions

    A comma-separated list of allowed TLS versions.

    TLSv1.2

    client_auth

    Whether or not clients must be authenticated. Setting this to REQUIRE enables mutual authentication for servers. Other possible values are NONE and OPTIONAL.

    OPTIONAL for bolt and https;
    REQUIRE for cluster and backup.

    trust_all

    Setting this to true results in all clients and servers to be trusted and the content of the trusted_dir directory to be ignored. Use this only as a mean of debugging, since it does not offer security.

    false

For security reasons, Neo4j does not automatically create any of these directories. Therefore, the creation of an SSL policy requires the appropriate file system structure to be set up manually. Note that the existence of the directories, the certificate file, and the private key are mandatory. Ensure that only the Neo4j user can read the private key.

Each policy needs to be explicitly enabled by setting:

dbms.ssl.policy.<scope>.enabled=true

4.1. Configure SSL over Bolt

Bolt protocol is based on the PackStream serialization and supports the Cypher type system, protocol versioning, authentication, and TLS via certificates. For Neo4j clusters, Bolt provides smart client routing with load balancing and failover. Bolt connector is used by Cypher Shell, Neo4j Browser, and by the officially supported language drivers. Bolt connector is enabled by default but its encryption is disabled. To enable the encryption over Bolt, create the folder structure and place the key file and the certificates under those. Then, you need to configure the SSL Bolt policies in the neo4j.conf file.

  1. Enable the Bolt connector to enable SSL over Bolt:

    dbms.connector.bolt.enabled=true (default is true)
  2. Set up the bolt folder under certificates.

    1. Create a directory bolt under <neo4j-home>/certificates folder:

      mkdir certificates/bolt
    2. Create a directory trusted and revoked under <neo4j-home>/certificates/bolt folder:

      mkdir certificates/bolt/trusted
      mkdir certificates/bolt/revoked
  3. Place the certificates private.key and the public.crt files under <neo4j-home>/certificates/bolt folder:

    cp /path/to/certs/private.key certificates/bolt
    cp /path/to/certs/public.crt certificates/bolt
  4. Place the public.crt file under the <neo4j-home>/certificates/bolt/trusted folder.

    cp /path/to/certs/public.crt certificates/bolt/trusted
  5. (Optional) If a particular certificate is revoked, then place it under <neo4j-home>/certificates/bolt/revoked folder.

    cp /path/to/certs/public.crt certificates/bolt/revoked

    The folder structure should look like this with the right file permissions and the groups and ownerships:

    Path Directory/File Owner Group Permission Unix/Linux View

    /data/neo4j/certificates/bolt

    Directory

    neo4j

    neo4j

    0755

    drwxr-xr-x

    /data/neo4j/certificates/bolt/public.crt

    File

    neo4j

    neo4j

    0644

    -rw-r—​r--

    /data/neo4j/certificates/bolt/private.key

    File

    neo4j

    neo4j

    0400

    -r--------

    /data/neo4j/certificates/bolt/trusted

    Directory

    neo4j

    neo4j

    0755

    drwxr-xr-x

    /data/neo4j/certificates/bolt/trusted/public.crt

    File

    neo4j

    neo4j

    0644

    -rw-r—​r--

    /data/neo4j/certificates/bolt/revoked

    Directory

    neo4j

    neo4j

    0755

    drwxr-xr-x

    The owner/group should be configured to the user/group that will be running the neo4j service. Default user/group is neo4j/neo4j.

  6. Set the Bolt SSL configuration in neo4j.conf.

    1. Set the SSL Bolt policy to true:

      dbms.ssl.policy.bolt.enabled=true
    2. Set the appropriate certificates path and the right key and cert files:

      dbms.ssl.policy.bolt.base_directory=certificates/bolt
      dbms.ssl.policy.bolt.private_key=private.key
      dbms.ssl.policy.bolt.public_certificate=public.crt

      If the certificate is a different path outside of NEO4J_HOME, then set the absolute path for the certificates directory.

    3. Set the Bolt client authentication to NONE to disable the mutual authentication:

      dbms.ssl.policy.bolt.client_auth=NONE
    4. Set the Bolt TLS level to allow the connector to accept encrypted and/or unencrypted connections:

      dbms.connector.bolt.tls_level=REQUIRED (default is DISABLED)

      In Neo4j version 3.5, the default value is OPTIONAL. In the Neo4j 4.x versions, the default value is DISABLED, where only unencrypted client connections are to be accepted by this connector, and all encrypted connections will be rejected. Use REQUIRED when only encrypted client connections are to be accepted by this connector, and all unencrypted connections will be rejected. Use OPTIONAL where either encrypted or unencrypted client connections are accepted by this connector.

  7. Test the SSL connection to the specified host and Bolt port and view the certificate:

    openssl s_client -connect my_domain.com:7687

4.2. Connect with SSL over Bolt

Each of the neo4j and bolt URI schemes permit variants that contain extra encryption and trust information. The +s variants enable encryption with a full certificate check. The +ssc variants enable encryption with no certificate check. This latter variant is designed specifically for use with self-signed certificates.

URI Scheme Routing Description

neo4j

Yes

Unsecured

neo4j+s

Yes

Secured with full certificate

neo4j+ssc

Yes

Secured with self-signed certificate

bolt

No

Unsecured

bolt+s

No

Secured with full certificate

bolt+ssc

No

Secured with self-signed certificate

Once SSL is enabled over Bolt, you can connect to the Neo4j DBMS using neo4j+s or bolt+s:

Cypher Shell
cypher-shell -a neo4j+s://<Server DNS or IP>:<Bolt port>

or

cypher-shell -a bolt+s://<Server DNS or IP>:<Bolt port>
Neo4j Browser

From the Connect URL dropdown menu, select the URI scheme you want to use (neo4j+s or bolt+s).

URI schemes ending +ssc are not supported by Neo4j Browser since the browser’s OS handles certificate trust. If it is necessary to connect to a Neo4j instance using a self-signed certificate from Neo4j Browser, first visit a web page that uses the self-signed certificate in order to prompt the browser to request that certificate trust be granted. Once that trust has been granted, you can connect with URI schemes ending +s.

4.3. Configure SSL over HTTPS

HTTP(s) is used by the Neo4j Browser and the HTTP API. HTTPS (secure HTTP) is set to encrypt network communications. To enable the encryption over HTTPS, create the folder structure and place the key file and the certificates under those. Then, you need to configure the SSL HTTPS policies in the neo4j.conf file and disable the HTTP connector.

  1. Enable the HTTPS connector to enable SSL over HTTPS:

    dbms.connector.https.enabled=true (default is false)
  2. Set up the https folder under certificates.

    1. Create a directory https under <neo4j-home>/certificates folder:

      mkdir certificates/https
    2. Create a directory trusted and revoked under <neo4j-home>/certificates/https folder:

      mkdir certificates/https/trusted
      mkdir certificates/https/revoked
  3. Place the certificates private.key and the public.crt files under <neo4j-home>/certificates/https folder:

    cp /path/to/certs/private.key certificates/https
    cp /path/to/certs/public.crt certificates/https
  4. Place the public.crt file under the <neo4j-home>/certificates/https/trusted folder.

    cp /path/to/certs/public.crt certificates/https/trusted
  5. (Optional) If a particular certificate is revoked, then place it under <neo4j-home>/certificates/https/revoked folder.

    cp /path/to/certs/public.crt certificates/https/revoked

    The folder structure should look like this with the right file permissions and the groups and ownerships:

    Path Directory/File Owner Group Permission Unix/Linux View

    /data/neo4j/certificates/https

    Directory

    neo4j

    neo4j

    0755

    drwxr-xr-x

    /data/neo4j/certificates/https/public.crt

    File

    neo4j

    neo4j

    0644

    -rw-r—​r--

    /data/neo4j/certificates/https/private.key

    File

    neo4j

    neo4j

    0400

    -r--------

    /data/neo4j/certificates/https/trusted

    Directory

    neo4j

    neo4j

    0755

    drwxr-xr-x

    /data/neo4j/certificates/https/trusted/public.crt

    File

    neo4j

    neo4j

    0644

    -rw-r—​r--

    /data/neo4j/certificates/https/revoked

    Directory

    neo4j

    neo4j

    0755

    drwxr-xr-x

    The owner/group should be configured to the user/group that will be running the neo4j service. Default user/group is neo4j/neo4j.

  6. Set the HTTPS SSL configuration in neo4j.conf.

    1. Set the SSL HTTPS policy to true:

      dbms.ssl.policy.https.enabled=true
    2. Set the appropriate certificates path and the right key and cert files:

      dbms.ssl.policy.https.base_directory=certificates/https
      dbms.ssl.policy.https.private_key=private.key
      dbms.ssl.policy.https.public_certificate=public.crt

      If the certificate is a different path outside of NEO4J_HOME, then set the absolute path for the certificates directory.

    3. Set the HTTPS client authentication to NONE to disable the mutual authentication:

      dbms.ssl.policy.https.client_auth=NONE
    4. Disable HTTP connector:

      dbms.connector.http.enabled=false
  7. Test the SSL connection to the specified host and HTTPS port and view the certificate:

    openssl s_client -connect my_domain.com:7473

4.4. Configure SSL for intra-cluster communications

Intra-cluster encryption is the security solution for the cluster communication. The Neo4j cluster communicates on 3 ports:

  • 5000 - Discovery management

  • 6000 - Transactions

  • 7000 - Raft communications

To set up intra-cluster encryption, on each server create the folder structure and place the key file and the certificates under those. Then, you need to configure the SSL cluster policies in the neo4j.conf file and test that the intra-cluster communication is encrypted.

  1. Set up the cluster folder under certificates.

    1. Create a directory cluster under_<neo4j-home>/certificates_ folder:

      mkdir certificates/cluster
    2. Create a directory trusted and revoked under <neo4j-home>/certificates/cluster folder:

      mkdir certificates/cluster/trusted
      mkdir certificates/cluster/revoked
  2. Place the certificates private.key and the public.crt files under <neo4j-home>/certificates/cluster folder:

    cp /path/to/certs/private.key certificates/cluster
    cp /path/to/certs/public.crt certificates/cluster
  3. Place the public.crt file under the <neo4j-home>/certificates/cluster/trusted folder.

    cp /path/to/certs/public.crt certificates/cluster/trusted

    If each server has a certificate of its own, signed by a CA, then each server’s public certificate has to be put in the trusted folder on each instance of the cluster. Thus, the servers are able to establish trust relationships with each other.

  4. (Optional) If a particular certificate is revoked, then place it under <neo4j-home>/certificates/cluster/revoked folder.

    cp /path/to/certs/public.crt certificates/cluster/revoked

    The folder structure should look like this with the right file permissions and the groups and ownerships:

    Path Directory/File Owner Group Permission Unix/Linux View

    /data/neo4j/certificates/cluster

    Directory

    neo4j

    neo4j

    0755

    drwxr-xr-x

    /data/neo4j/certificates/cluster/public.crt

    File

    neo4j

    neo4j

    0644

    -rw-r—​r--

    /data/neo4j/certificates/cluster/private.key

    File

    neo4j

    neo4j

    0400

    -r--------

    /data/neo4j/certificates/cluster/trusted

    Directory

    neo4j

    neo4j

    0755

    drwxr-xr-x

    /data/neo4j/certificates/cluster/trusted/public.crt

    File

    neo4j

    neo4j

    0644

    -rw-r—​r--

    /data/neo4j/certificates/cluster/revoked

    Directory

    neo4j

    neo4j

    0755

    drwxr-xr-x

    The owner/group should be configured to the user/group that will be running the neo4j service. Default user/group is neo4j/neo4j.

  5. Set the cluster SSL configuration in neo4j.conf.

    1. Set the cluster SSL policy to true:

      dbms.ssl.policy.cluster.enabled=true
    2. Set the appropriate certificates path and the right key and cert files:

      dbms.ssl.policy.cluster.base_directory=certificates/cluster
      dbms.ssl.policy.cluster.private_key=private.key
      dbms.ssl.policy.cluster.public_certificate=public.crt

      If the certificate is a different path outside of NEO4J_HOME, then set the absolute path for the certificates directory.

    3. Set the cluster client authentication to REQUIRE to enable the mutual authentication, which means that both ends of a channel have to authenticate:

      dbms.ssl.policy.cluster.client_auth=REQUIRE

      The policy must be configured on every server with the same settings. The actual cryptographic objects installed will be mostly different since they do not share the same private keys and corresponding certificates. The trusted CA certificate will be shared however.

    4. Verify that the intra-cluster communication is encrypted. You may use an external tooling, such as Nmap (https://nmap.org/download.html):

      nmap --script ssl-enum-ciphers -p <port> <hostname>

      The hostname and port have to be adjusted according to your configuration. This can prove that TLS is in fact enabled and that only the intended cipher suites are enabled. All servers and all applicable ports should be tested. If the intra-cluster encryption is enabled, the output should indicate the port is open and it is using TLS with the ciphers used.

For more details on securing the comunication between the cluster servers, see Intra-cluster encryption.

4.5. Configure SSL for backup communication

In a single instance, by default the backup communication happens on port 6362. In a cluster topology, it is possible to take a backup from any server, and each server has two configurable ports capable of serving a backup. These ports are configured by dbms.backup.listen.address (port 6362) and causal_clustering.transaction_listen_address (port 6000) respectively. If the intra-cluster encryption is enabled and the backup communication is using port 6000, then your communication channels are already encrypted. The following steps assumes that your backup is set up on a different port.

To set up SSL for backup communication, create the folder structure and place the key file and the certificates under those. Then, you need to configure the SSL backup policies in the neo4j.conf file.

  1. Set up the backup folder under certificates.

    1. Create a directory backup under <neo4j-home>/certificates folder:

      mkdir certificates/backup
    2. Create a directory trusted and revoked under <neo4j-home>/certificates/backup folder:

      mkdir certificates/backup/trusted
      mkdir certificates/backup/revoked
  2. Place the certificates private.key and the public.crt files under <neo4j-home>/certificates/backup folder:

    cp /path/to/certs/private.key certificates/backup
    cp /path/to/certs/public.crt certificates/backup
  3. Place the public.crt file under the <neo4j-home>/certificates/backup/trusted folder.

    cp /path/to/certs/public.crt certificates/backup/trusted
  4. (Optional) If a particular certificate is revoked, then place it under <neo4j-home>/certificates/backup/revoked folder.

    cp /path/to/certs/public.crt certificates/backup/revoked

    The folder structure should look like this with the right file permissions and the groups and ownerships:

    Path Directory/File Owner Group Permission Unix/Linux View

    /data/neo4j/certificates/backup

    Directory

    neo4j

    neo4j

    0755

    drwxr-xr-x

    /data/neo4j/certificates/backup/public.crt

    File

    neo4j

    neo4j

    0644

    -rw-r—​r--

    /data/neo4j/certificates/backup/private.key

    File

    neo4j

    neo4j

    0400

    -r--------

    /data/neo4j/certificates/backup/trusted

    Directory

    neo4j

    neo4j

    0755

    drwxr-xr-x

    /data/neo4j/certificates/backup/trusted/public.crt

    File

    neo4j

    neo4j

    0644

    -rw-r—​r--

    /data/neo4j/certificates/backup/revoked

    Directory

    neo4j

    neo4j

    0755

    drwxr-xr-x

    The owner/group should be configured to the user/group that will be running the neo4j service. Default user/group is neo4j/neo4j.

  5. Set the backup SSL configuration in neo4j.conf.

    1. Set the backup SSL policy to true:

      dbms.ssl.policy.backup.enabled=true
    2. Set the appropriate certificates path and the right key and cert files:

      dbms.ssl.policy.backup.base_directory=certificates/backup
      dbms.ssl.policy.backup.private_key=private.key
      dbms.ssl.policy.backup.public_certificate=public.crt

      If the certificate is a different path outside of NEO4J_HOME, then set the absolute path for the certificates directory.

    3. Set the backup client authentication to REQUIRE to enable the mutual authentication, which means that both ends of a channel have to authenticate:

      dbms.ssl.policy.backup.client_auth=REQUIRE

4.6. Other configurations for SSL

4.6.1. Using encrypted private key

To use an encrypted private key, configure the following settings. The private key password must be clear text format without any quotes.

Bolt
dbms.ssl.policy.bolt.private_key_password=<clear text password>
HTTPS
dbms.ssl.policy.https.private_key_password=<password>
Intra-cluster encryption
dbms.ssl.policy.cluster.private_key_password=<password>
Backup
dbms.ssl.policy.backup.private_key_password=<password>

If hardcoding of clear text private key password is not feasible due to security constraints, it can be set up to use dynamic password pickup:

dbms.ssl.policy.bolt.private_key_password=$(openssl aes-256-cbc -a -d -in /opt/neo4j/etc/neo4j/neo4j_cert_pwd.enc -kfile  /opt/neo4j/var/lib/neo4j/certificates/bolt/neo4j.cert)

Using a dynamic command requires Neo4j to be started with the --expand-commands option. For more information, see Command expansion.

4.6.2. Using specific cipher

There are cases where Neo4j Enterprise requires the use of specific ciphers for encryptions. One can set up a Neo4j configuration by specifying the list of cipher suits that will be allowed during cipher negotiation. Valid values depend on the current JRE and SSL provider. For Oracle JRE here is the list of supported ones - https://docs.oracle.com/en/java/javase/11/docs/specs/security/standard-names.html#jsse-cipher-suite-names.

Bolt
dbms.ssl.policy.bolt.ciphers=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
HTTPS
dbms.ssl.policy.https.ciphers=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
Intra-cluster encryption
dbms.ssl.policy.cluster.ciphers=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
Backup
dbms.ssl.policy.backup.ciphers=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

4.7. Using OCSP stapling

From version 4.2, Neo4j supports OCSP stapling, which is implemented on the server side, and can be configured in the neo4j.config file. OCSP stapling is also available for Java Bolt driver and HTTP API.

On the server side in the neo4j.conf file, configure the following settings:

  1. Set the SSL Bolt policy to true:

    dbms.ssl.policy.bolt.enabled=true
  2. Enable the OCSP stapling for Bolt:

    dbms.connector.bolt.ocsp_stapling_enabled=true (default = false)

5. SSL logs

All information related to SSL can be found in the debug.log file. You can also enable additional debug logging for SSL by adding the following configuration to the neo4j.conf file and restarting Neo4j.

dbms.jvm.additional=-Djavax.net.debug=ssl:handshake

This will log additional information in the neo4j.log file. In some installations done using rpm based installs, neo4j.log is not created. To get the contents of this, since neo4j.log just contains STDOUT content, look for the neo4j service log contents using journalctl:

neo4j@ubuntu:/var/log/neo4j$ journalctl -u neo4j -b > neo4j.log
neo4j@ubuntu:/var/log/neo4j$ vi neo4j.log

6. Terminology

The following terms are relevant to SSL support within Neo4j:

Certificate Authority (CA)

A trusted entity that issues electronic documents that can verify the identity of a digital entity. The term commonly refers to globally recognized CAs, but can also include internal CAs that are trusted inside of an organization. The electronic documents are digital certificates. They are an essential part of secure communication, and play an important part in the Public Key Infrastructure.

Certificate Revocation List (CRL)

In the event of a certificate being compromised, that certificate can be revoked. This is done by means of a list (located in one or several files) spelling out which certificates are revoked. The CRL is always issued by the CA which issues the corresponding certificates.

cipher

An algorithm for performing encryption or decryption. In the most general implementation of encryption of Neo4j communications, we make implicit use of ciphers that are included as part of the Java platform. The configuration of the SSL framework also allows for the explicit declaration of allowed ciphers.

communication channel

A means for communicating with the Neo4j database. Available channels are:

  • Bolt client traffic

  • HTTPS client traffic

  • intra-cluster communication

  • backup traffic

cryptographic objects

A term denoting the artifacts private keys, certificates and CRLs.

configuration parameters

These are the parameters defined for a certain ssl policy in neo4j.conf.

certificate

SSL certificates are issued by a trusted certificate authority (CA). The public key can be obtained and used by anyone to encrypt messages intended for a particular recipient. The certificate is commonly stored in a file named <file name>.crt. This is also referred to as the public key.

SAN

SAN is an acronym for Subject Alternative Names. It is an extension to certificates that one can include optionally. When presented with a certificate that includes SAN entries, it is recommended that the address of the host is checked against this field. Verifying that the hostname matches the certificate SAN helps prevent attacks where a rogue machine has access to a valid key pair.

SSL

SSL is an acronym for Secure Sockets Layer, and is the predecessor of TLS. It is common to refer to SSL/TLS as just SSL. However, the modern and secure version is TLS, and this is also the default in Neo4j.

SSL policy

An SSL policy in Neo4j consists of a a digital certificate and a set of configuration parameters defined in neo4j.conf.

private key

The private key ensures that encrypted messages can be deciphered only by the intended recipient. The private key is commonly stored in a file named <file name>.key. It is important to protect the private key to ensure the integrity of encrypted communication.

Public Key Infrastructure (PKI)

A set of roles, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates and manage public-key encryption.

public key

The public key can be obtained and used by anyone to encrypt messages intended for a particular recipient. This is also referred to as the certificate.

TLS protocol

The cryptographic protocol that provides communications security over a computer network. The Transport Layer Security (TLS) protocol and its predecessor, the Secure Sockets Layer (SSL) protocol are both frequently referred to as "SSL".

TLS version

A version of the TLS protocol.