For organisations having an internal certificate authority (such as Microsoft Active Directory Certificate Services), the process for requesting a key and certificate usually involves submitting a request on a web form.

Whilst these systems may offer the standard PEM format certificates required by Neo4j deployments, often, the certificates provided are in a PKCS#12 format.

This is a bundled format which usually contains the server certificate and the private key together, and often with the CA chain included. With some corporate CA systems, this bundle is protected with a passphrase during the export system.

Extracting certificate and key from PFX

This certificate bundle is easy to work with as it usually contains the various parts required, but it must be converted for use with Neo4j Server which requires PEM format certificates.

Whilst the exported filename may vary, in the following examples we will simply call this BUNDLE.pfx in this example.

Whilst optional, we will also pipe the extracted output through openssl rsa and openssl x509, as appropriate, as this can help ensure the resulting files are cleaned of any metadata, and are in the default formats.

We may then upload the files to a temporary directory on the server to perform the extraction and processing.

First, we need to export the private key, where we will also remove any private key encryption through using the -nodes option to ensure that the exported key is not DES protected. If your security policy requires you to keep the private keys encrypted, then this option may be omitted.

We can export and format the private key in one go with the following command line chain:

openssl pkcs12 -in BUNDLE.pfx -nocerts -nodes | openssl rsa -out private.key

If the PFX file was created using an export passphrase, a prompt would appear.

Likewise, we can take the top-most certificate from the chain and export this in a similar fashion, but with openssl x509:

openssl pkcs12 -in BUNDLE.pfx -nokeys | openssl x509 -out public.crt

At this point we will have a private.key and public.crt file.

We would want to ensure that this is the correct server certificate, which can be achieved using the -noout -text flags and feeding that certificate back in:

openssl x509 -in public.crt -noout -text

Checking the details there should match the certificate we expect.

Extracting the CA certificate from PFX

It might be prudent to first take a copy of the intermediate CA certificate. For example, when we want to specify the CA that will be used to authenticate clients.

To extract the CA certificate, we can use the -cacerts option:

openssl pkcs12 -in BUNDLE.pfx -cacerts | openssl x509 -out ca.crt

And we can check this in the same way:

openssl x509 -in ca.crt -noout -text

Structuring your SSL Certificate Directory

Once prepared, the files can be placed within the Neo4j home directory. There might only be a `trusted` and `revoked` structure for the certificate-based client authentication:

/var
└── lib
    └── neo4j
        └── certificates
              ├── backup
              │   ├── private.key
              │   ├── public.crt
              │   ├── revoked
              │   └── trusted
              │   └── ca.crt
              ├── bolt
              │   ├── private.key
              │   ├── public.crt
              │   ├── revoked
              │   └── trusted
              │   └── ca.crt
              ├── cluster
              │   ├── private.key
              │   ├── public.crt
              │   ├── revoked
              │   └── trusted
              │   └── ca.crt
              └── https
                  ├── private.key
                  └── public.crt

In deployments involving multiple SSL policies, these can point to a "common" set of certificates, if preferred.
There may be a single $NEO4J_HOME/certificates/common/ directory structure:

/var
└── lib
    └── neo4j
        └── certificates
                └── https
                    ├── private.key
                    └── public.crt

In such case, the base_directory would be configured with the same set of certificates.

For example:

dbms.ssl.policy.bolt.base_directory=/var/lib/neo4j/certificates/common
dbms.ssl.policy.https.base_directory=/var/lib/neo4j/certificates/common
dbms.ssl.policy.cluster.base_directory=/var/lib/neo4j/certificates/common

Intra-Cluster Encryption

If setting up intra-cluster encryption as part of a causal clustering configuration, do ensure that the certificates used on the cluster endpoint supports both Server and Client usage. This is because when connecting between the Neo4j instances for clustering, each instance will use its own certificate to authenticate as a client on the connection to another server.

This could be verified from within the certificate details:

openssl x509 -in public.crt -noout -text

We should see that the X509v3 Extended Key Usage section shows both the usages listed:

X509v3 Extended Key Usage:
    TLS Web Server Authentication, TLS Web Client Authentication