[SERVER-67008] Cannot user client certificate in cluster when "tlsClusterCAFile" is used Created: 03/Jun/22 Updated: 27/Oct/23 Resolved: 10/Jun/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 5.0.9 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Wernfried Domscheit | Assignee: | Chris Kelly |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | TLS/SSL, cluster, replica-set | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Operating System: | ALL | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Steps To Reproduce: | This is the relevant part of the config file:
Relevant information of the certificates:
Certificates are valid:
Start Replica Set members. When the second member starts then I get this error on the first one:
and member remains in SECONDARY state. Apparently the replica set considers the member connection as a normal client connection, which is not the case. (I am not try to connect with any client)
I tied with different certificates (matching O and OU):
With these certificates the ReplicaSet starts up as expected:
However, I get this warning which actually no problem - but it is not true. The client is another mongod repliaset member, thus this warning should not appear:
Anyway, I tried several client certificates, none of them is working:
I cannot use the client certificate, neither for TLS/SSL nor for authentication:
Note, the same works fine on a Standalone MongoDB, it only fails on a cluster/replica set:
It also works fine if I use a common CA for cluster and client, i.e.
works fine. However, I like to have different CA for cluster and client certificates. Is this a bug or do I anything wrong?
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: |
| Description |
|
I am running some tests with TLS/SSL certificates. I like to use client certificates (for TLS/SSL and authentication) in a ReplicaSet / Sharded Cluster. It works fine when I run it on standalone MongoDB It works fine when I use a common CA for cluster and client, i.e.
works fine. However, I like to have different CA for cluster and client certificates. |
| Comments |
| Comment by Chris Kelly [ 10/Jun/22 ] | ||||||||||||||||||||||||||||||||
|
Hi Wernfried, Thanks for taking the time to come back and share the extra information on that. I'll go ahead and close this ticket. Regards, | ||||||||||||||||||||||||||||||||
| Comment by Wernfried Domscheit [ 08/Jun/22 ] | ||||||||||||||||||||||||||||||||
|
After creating dozens of different certificates combinations I got it. clusterCAFile is used to verify certificates provided by the client - "normal" client as well as "membership" client connections. In my opinion the name is a bit misleading, I was thinking it is related to clusterFile, i. e.
Obviously, my assumption was wrong (although I don't see any use-case for the way it is implemented) You can close this ticket.
Kind Regards
| ||||||||||||||||||||||||||||||||
| Comment by Wernfried Domscheit [ 08/Jun/22 ] | ||||||||||||||||||||||||||||||||
|
Made a few more test. Obviously the client-certificate ( --tlsCertificateKeyFile=mongo.client.pem ) is verified by Cluster-CA ( clusterCAFile: mongo.member-ca.cer )
I read carefully the documentation: "The .pem file that contains the root certificate chain from the Certificate Authority used to validate the certificate presented by a client establishing a connection. {{}} net.tls.clusterCAFile lets you use separate Certificate Authorities to verify the client to server and server to client portions of the TLS handshake."
What does it mean? I don't understand. For "server to client portions of the TLS handshake" the CA is defined at client side ( mongosh --tls --tlsCAFile=... ), so what is then the difference between net.tls.clusterCAFile and net.tls.CAFile?
I also tried the opposite
But this does not work either, the replica set member cannot connect, the node remains in SECONDARY state.
|