[SERVER-11025] Adding a user with x509 certificate = server certificate appears to work Created: 03/Oct/13  Updated: 14/Feb/20  Resolved: 22/Oct/13

Status: Closed
Project: Core Server
Component/s: Security
Affects Version/s: 2.5.2
Fix Version/s: 2.5.4

Type: Bug Priority: Major - P3
Reporter: Luke Lovett Assignee: Andreas Nilsson
Resolution: Done Votes: 0
Labels: X.509
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File invalid_cert.log    
Issue Links:
Depends
Problem/Incident
causes SERVER-45938 Allow matching O/OU/DC in client x509... Closed
Operating System: ALL
Steps To Reproduce:

1. For each node in the replica set, I set up sslClusterFile and sslPEMKeyFile to be "server.pem":

mongod --replSet testReplSet --sslOnNormalPorts --sslClusterFile jstests/libs/server.pem --clusterAuthMode x509 --sslPEMKeyFile jstests/libs/server.pem --sslCRLFile jstests/libs/crl_client_revoked.pem --sslCAFile jstests/libs/ca.pem --auth

2. I connect with mongo using the same certificate:

mongo --ssl --sslPEMKeyFile jstests/libs/server.pem

3. Create the user & authenticate:

> db.getSiblingDB("$external").addUser(
...    { user:"CN=client,OU=kerneluser,O=10Gen,L=New York City,ST=New York,C=US",
...      roles: [
...          {name: 'clusterAdmin', source: 'admin', hasRole: true, 'canDelegate': true},
...          {name: 'userAdminAnyDatabase', source: 'admin', hasRole: true, 'canDelegate': true},
...          {name: 'readWriteAnyDatabase', source: 'admin', hasRole: true, 'canDelegate': true},
...          {name: 'dbAdminAnyDatabase', source: 'admin', hasRole: true, 'canDelegate': true}]
...    });
> db.getSiblingDB("$external").auth({ user:"emailAddress=root@lazarus,CN=server,OU=Kernel,O=10Gen,L=New York City,ST=New York,C=US",
...          mechanism:"MONGODB-X509"});
1

4. Check in the system.users collection:

> db.getSiblingDB("admin").system.users.findOne()
{
	"_id" : "$external.emailAddress=root@lazarus,CN=server,OU=Kernel,O=10Gen,L=New York City,ST=New York,C=US",
	"name" : "emailAddress=root@lazarus,CN=server,OU=Kernel,O=10Gen,L=New York City,ST=New York,C=US",
	"source" : "$external",
	"roles" : [
		{
			"name" : "clusterAdmin",
			"source" : "admin",
			"hasRole" : true,
			"canDelegate" : true
		},
		{
			"name" : "userAdminAnyDatabase",
			"source" : "admin",
			"hasRole" : true,
			"canDelegate" : true
		},
		{
			"name" : "readWriteAnyDatabase",
			"source" : "admin",
			"hasRole" : true,
			"canDelegate" : true
		},
		{
			"name" : "dbAdminAnyDatabase",
			"source" : "admin",
			"hasRole" : true,
			"canDelegate" : true
		}
	]
}

Participants:

 Description   

Adding a user with a username equal to the subject of the x509 certificate of a mongod instance in a replica set or sharded cluster appears to be successful as does the authentication of this user. This is in appearance only, as when I take a look at the system.users collection, there is nothing there. I would expect there to be some message that notifies the user that something has gone wrong while trying to add the user with the invalid username and certificate, and then not allow the user to authenticate.



 Comments   
Comment by auto [ 22/Oct/13 ]

Author:

{u'username': u'agralius', u'name': u'Andreas Nilsson', u'email': u'andreas.nilsson@10gen.com'}

Message: SERVER-11025 Prevent adding users with username = server's subjectname
Branch: master
https://github.com/mongodb/mongo/commit/75135b965a7d9af110bd42bc40e9ad6dfac254ab

Comment by Luke Lovett [ 03/Oct/13 ]

That makes sense and sounds like the way to go.

Comment by Andreas Nilsson [ 03/Oct/13 ]

Thx Luke. I don't want to block auth for that but we can block adding a user with an identical subject name as the server.

Comment by Luke Lovett [ 03/Oct/13 ]

schwerin, thanks for pointing out my mistake in step 4. After running my test this way, I see that the user is in fact added to the system.users collection. I've modified the ticket now to make note of this. I'm also attaching my log output from my javascript ReplSetTest to the ticket. The logs seem to indicate that the addUser command succeeds, as far as I can tell. andreas.nilsson@10gen.com, perhaps instead of blocking auth with the certificate altogether, there could be some way to block doing an addUser with the subject of the server certificate? Perhaps this is just a superficial change. I just think it's confusing from the user's perspective to be able to add a user that doesn't actually do anything, and there should be some kind of message about that similar to the error message when trying to authenticate this way against a standalone mongod instance; perhaps:

Failed to authenticate emailAddress=root@lazarus,CN=server,OU=Kernel,O=10Gen,L=New York City,ST=New York,C=US@$external with mechanism MONGODB-X509: AuthenticationFailed The provided certificate can only be used for cluster authentication, not client authentication.

Comment by Andreas Nilsson [ 03/Oct/13 ]

luke.lovett can you check the server logs to see what it says about the success of the addUser command.

With regards to authentication I'm not sure we want to block authentication with the same certificate. That would mean that two servers who are configured to use the same certificate (some orgs might do this) will not be able to use x.509 cluster auth. schwerin what do you think?

Also if the addUser command succeeds should we block that for cluster members generally? It kind of makes sense.

Comment by Andy Schwerin [ 03/Oct/13 ]

You want db.getSiblingDB("admin").system.users.findOne() in step 4.

Generated at Thu Feb 08 03:24:40 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.