If i have a cluster where all the nodes share a single certificate and private key does it count as mutual TLS? Technically both parties in the communication have a certificate and present it to each other.
New contributor
Sechkin Cholak is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
-
1Does the client send the certificate to the server when it initiates a connection?– schroeder ♦Commented Sep 5 at 11:39
-
Why are all the nodes sharing the same certificate?– schroeder ♦Commented Sep 5 at 11:40
-
1This all sounds very strange. If all nodes that communicate share the same certificate (and therefore the same public key), then the certificate is entirely pointless. Each node already knows the peer's public key -- it's their own. You either want different private keys (highly recommended) or TLS-PSK with a single pre-shared key.– Ja1024Commented Sep 5 at 12:19
-
@Ja1024 but if there is mtls, then it would identify interlopers even if there is a shared certificate. You don't end up authenticating the known/trusted nodes, but non-trusted nodes would get highlighted.– schroeder ♦Commented Sep 5 at 12:23
-
@schroeder: TLS-PSK does the same -- it requires both parties to know the shared key. Except it's more efficient, because it skips the superfluous certificate checks.– Ja1024Commented Sep 5 at 12:27
|
Show 2 more comments
2 Answers
Mutual TLS requires that both systems are presenting certificates and verifying the peer's certificate within a single connection.
So if ServerA makes a normal TLS connection to ServerB, and then ServerB makes a subsequent normal TLS connection to ServerA that would not be considered mutual TLS; because in both of those individual connections the client is not presenting a certificate.
It makes no sense to share a certificate among nodes which communicate with each other. The certificate doesn't convey any useful information in this case, because every node already knows the public key of every other node – it's always its own key.
There are two options.
The recommended solution would be generate a different key pair on each node, obtain node-specific certificates and then set up classical mTLS. Using different keys drastically reduces both the risk and the effect of a key compromise, because an attacker has to attack each node individually, and if they succeed, they can only impersonate a single node.
If you insist on a shared key, then use TLS-PSK. Certificates are not needed in this case, because the peers can simply authenticate with the shared key. Note that TLS-PSK can and should still be combined with an (EC)DHE key exchange to ensure forward secrecy.
-
It does convey a useful property: it identifies the other party as one of the nodes, and not a third party. Still better to use one certificate per node, though.– ÁngelCommented Sep 5 at 17:25
-
@Ángel: There’s exactly zero point in performing a certificate exchange when both parties present the same certificate. Again, each party already knows what the correct public key of the other party is: It’s their own. Putting the known correct key into a certificate structure and having a CA sign it doesn’t make it “more correct”. This is why the concept of pre-shared keys exist: Each node can prove to the other that it’s part of the group and not a third party. Because the nodes and only the nodes know the PSK.– Ja1024Commented Sep 5 at 17:44
-
I was thinking they were compared to a local copy of the certificate, not going through the unneeded hassle of being signed by a CA. I was focusing in a different kind of useful. I agree, you can do the same with a PSK. You might still prefer using certificates in order to use existing programs / APIs expecting that, though. Probably the main benefit or doing it as certificates would be an easier path for moving to different certificates per host.– ÁngelCommented Sep 6 at 1:03