Update the ssl config for backup #2610
Conversation
renetapopova
force-pushed
the
dev-backup-ssl
branch
from
d16d56b to
695ea41
Compare
renetapopova
added
auto-cherry-pick-to-main
auto-cherry-pick-to-5.x
clustering
and removed
WIP
labels
renetapopova
force-pushed
the
dev-backup-ssl
branch
from
695ea41 to
522b951
Compare
renetapopova
added
cherry-pick-this-to-5.x
cherry-pick-this-to-main
and removed
auto-cherry-pick-to-main
auto-cherry-pick-to-5.x
labels
renetapopova
force-pushed
the
dev-backup-ssl
branch
from
522b951 to
7b76645
Compare
renetapopova
requested review from
rhysemmas and
thelonelyvulpes
and removed request for
rhysemmas
renetapopova
force-pushed
the
dev-backup-ssl
branch
from
477121b to
61e7f49
Compare
| === Configure the backup client for SSL | ||
| When using `neo4j-admin backup` command, you need to specify the SSL policy to be used by the backup client. |
There was a problem hiding this comment.
I think this doesn't make it entirely clear that you can back up against the cluster endpoint(6000 default) and its SSL policy dbms.ssl.policy.cluster.*, or the backup endpoint(6362 default) and its SSL policy dbms.ssl.policy.backup.*, but regardless of which you do back up against, the admin client will use the SSL policy specified for backups dbms.ssl.policy.backup.*
| === Configure the backup client for SSL | ||
| When using `neo4j-admin backup` command, you need to specify the SSL policy to be used by the backup client. | ||
| You can do this by setting a matching SSL configuration in the _neo4j.conf_ and _neo4j-admin.conf_ files. |
There was a problem hiding this comment.
It is not entirely true that they must match, but be sympathetic of/mirror one another.
i.e., if they want mutualTLS with self-signed certificates, the server must have the client's certificate in its trusted_dir, and the client must have the server's certificate in its trusted_dir
There was a problem hiding this comment.
However, when they use a certificate authority to signs both the client's and server's certificates, the trusted_dir only needs to contain an intermediate CA cert.
renetapopova
force-pushed
the
dev-backup-ssl
branch
from
baacd84 to
8130ff3
Compare
|
This PR includes documentation updates Updated pages: |
| If you want mutual TLS with self-signed certificates, the server must have the client's certificate in its _trusted_dir_, and the client must have the server's certificate in its _trusted_dir_. | ||
| If you use a certificate authority (CA) to signs both the client's and server's certificates, the _trusted_dir_ must contain only the CA or intermediate certificates. | ||
|
|
||
| Furthermore, Neo4j does not validate the certificates. |
There was a problem hiding this comment.
Sorry, I think we got our wires crossed, we do do certificate validation. When I said we do not validate config, I meant in the sense that SSL config group configs are validated as being a correct config key.
There was a problem hiding this comment.
If I understand you correctly, you are saying that we don't validate the SSL configuration itself, so they should make sure that they have used the correct keys and certificates. And you're also saying that we validate the keys and certificates themselves. Does that mean that we don't need the manual step in this section, then https://neo4j.com/docs/operations-manual/current/security/ssl-framework/#_validate_the_key_and_the_certificate?
| [NOTE] | ||
| ==== | ||
| If the backup client is on a different machine from the Neo4j server, you must install sympathetic SSL certificates and keys on the backup client machine as well, so that the backup client can authenticate the server and vice versa. |
There was a problem hiding this comment.
I don't know the correct way phrase this bit, but if we can use a more verbose way of writing this to avoid any ambiguity that "sympathetic" creates.
There are a few ways to configure SSL.
- You can use the same key pair on both the client and the server if you put the same cert in both, (it needs to be their public cert and trusted cert)
- You can use CA chains by doing a typical chain of trust with CA
- You can also have mirrored certs (server trusts the client's cert, client trusts the server's cert)
No description provided.