Introduction

I want to write a series of posts describing a walk-through of deploying and running Neo4j with Certificates.
This isn't to say that this is the only way, or even the best way, to deploy - but hopefully this series can serve as an introduction and signpost to getting your own deployment going the way you want.

I also want to keep this fairly version-neutral, talking about the concepts that we need to cover, rather than the syntax we need to write. I am in fact, going to try to keep Neo4j as far out of this as possible (at least until we configure it later) and discuss more conceptually about securing applications with certificates.

When troubleshooting SSL configurations, we often find misunderstandings about essential concepts, resulting in admins following documented processes to the word, without a deeper understanding of reason. I hope that this series of guides can help bridge this knowledge gap.

Quick Terms

There are better, and more correct, descriptions of these terms online, but I would like to introduce some of the major characters in our story. Hopefully, these quick descriptions can aid a better conceptual understanding.

Certificate

Sometimes called a public certificate, or public key, this is a file which contains the public side of a public-private keypair (the basis of our SSL/TLS story).
Your SSL certificate is public and can be distributed as far and wide as you like, without compromising security - in fact certificates being sent on the wire is how the authenticity is checked between clients and servers.
Certificates are usually signed by a Certificate Authority, an entity discussed later.
You can have self-signed certificates, but their use is limited to single-instance test setups.

Private Key

Or often simply called the "key". This is the other half of the private key and is responsible for the secret stuff.
Again, we usually use the term to mean the file rather than the contents within it, but it is somewhat interchangeable.
We need to protect access to these keys and should never provide them to "third-parties", be that sending server keys to clients, random strangers, or even your friendly Technical Support Engineers.

Certificate Authority

Generally shortened to "CA". This is an entity that signs, or produces, your certificates.
This could be something you set up, something managed by your IT Security Team, or an external or online entity. More on this point in a moment!

Root & Intermediate Certificate Authority

At the top of a certificate trust chain is a Root Certificate Authority that is authorised to sign its own certificate.
It has to be this way, because if their certificate was signed by a different authority, they'd not be at the root.
Any CA that sits between the Root CA and your server certificate is referred to as an Intermediate CA.

Initial Considerations

Certificate Source

The first step is to decide where we're sourcing certificates from, i.e. which Certificate Authority are we going to use?

We could generate our own CA for our own PKI (certificate hierarchy), which is ok for testing internal projects, but we generally want something more robust for bigger deployments or production environments.
Which CA is selected, does not really matter to the strength of the TLS connection, but it is relevant in terms of the level of trust we can place on the certificate it signs.

In another respect, your locally-built CA is fully customisable, you can set it up however you want.
At the other end of this scale, a commercial CA that you'd purchase certificates from online might be the most restrictive in terms of configuration.
Your IT Security Team's CA will hopefully be a good blend, well managed and supported, but most receptive to your needs and standards.

Multi-Server Certificates

The next thing I would advise for consideration, is to determine how many certificates (and associated keys) do we want to use? All of your server instances could share a private key and certificate, or they could each have unique certificates.

There is no major difference in security in either case, but some organisations may have rules for or against using a single certificate across multiple servers.
I would go for individual instance certificates each time, unless I find myself spinning up new nodes in an ad-hoc (containerised?) fashion.

There is a some more work involved in making individual certificates for each server instance, but it is fairly straightforward process, which can be performed quicker with automation.
In most environments, your database servers will not disappear and be recreated at random, so including a quick certificate creation step as part of the set up work should be quick, and would not be performed very often.

Server Names

A major step (or, mis-step) is getting the names of the server instances set up according to what is supported for your deployment.
From the outset, I would suggest that you create a canonical hostname for your server instances, if they don't have one already, and you use this name exclusively.

It is generally not possible to get an SSL certificate for an IP address, although, you can have an IP address listed as a subjectAlternativeName (SAN) on a certificate.
For simplicity we'll always use fully qualified domain names (server1.neo4j.myorg.test), and never the short names (server1) or the IP addresses they map to. IP addresses might change, but well thought out fully qualified domain names can live forever!

If using wildcard certificates to cover multiple server instances, you can only put the wildcard at the leaf-end of the fully qualified domain name (FQDN). For example, you can have a wildcard for *.neo4j.myorg.test, but not neo4j.*.myorg.test.

This fully qualified domain name needs to be used everywhere. In your browser URL address bar, your application connection strings, and all the instances in the configuration file such as advertised address and initial discovery addresses.

If you know how, and have the ability to add them, feel free to use SANs to add any short names or aliases, and even the server's IP addresses, if you must!

Do not forget to include the primary FQDN in the SAN address list if using SANs, the subject CN may not be checked if a SAN list is present.

What's Next?

By now, we have covered some initial considerations for getting your SSL certificate deployment off to a good start.

In short:

• Determine which CA we're going to be working with. Are we building the PKI from scratch in a greenfield deployment, or leveraging an existing internal or external commercial CA.
• Decide on one-certificate for each instance, or a master certificate that needs to be copied to all the instances.
• Produce a logical server naming scheme that matches up with your DNS records, and is logical in its hierarchical structure.

What would I do?

In my lab environment I have:

• An internal, private CA, like the one you might use in an organisation
• Structured hostnames within a dedicated DNS zone
• Unique certificates on each server that match each server's FQDN, along with any service-related domain name included in the SAN list. There are some with an IP address or two in there, just in case!
  But server A and server B do not appear on each others' certificate. It is not a multi-server SAN certificate.

In the next part, we can look at generating these certificates with either a local test PKI system like OpenSSL or EasyRSA, and get them configured in Neo4j Server.

 

Next: Deploying Neo4j with Certificates: Using EasyRSA