Homework 2.4 : Create replica with TLS enabled

MongoDB University M310: MongoDB Security
#1

When setting up the MongoDB servers with TLS, authenticating after connecting with db.getSiblingDB("$external").auth or via mongo command-line parameters (as described in the online MongoDB documentation) worked perfectly. However, the validation script failed to connect.

The problem seemed to be that MongoDB did not automatically recognize the username from the certificate. When connecting with:

mongo --host localhost --ssl --sslPEMKeyFile ~/shared/certs/client.pem --sslCAFile ~/shared/certs/ca.pem --port 31240

The user has no privileges (which is what the validation script also output). When connecting with:

mongo --host localhost --ssl --sslPEMKeyFile ~/shared/certs/client.pem --sslCAFile ~/shared/certs/ca.pem --port 31240 --authenticationDatabase ‘$external’ --authenticationMechanism MONGODB-X509 -u “C=US,ST=New York,L=New York City,O=MongoDB,OU=University2,CN=M310 Client”

I could connect perfectly. This is how it is described in the online documentation as well. To solve the homework, I modified the validation script to include the --authenticationDatabase, --authenticationMechanism, and -u parameters. That caused the script to work as intended.

Out of curiosity, did anyone else encounter that? Is there a mongod option to “inherit the username from the certificate” that I could have specified? Or perhaps a way of disabling all authentication except for x.509 so that mongod defaulted to the $external database for authentication?

#2

@ ciscofu

Well, I’m not really sure what your question is here, but let me make two points. First, you should not and do not have to change the validation script if you’ve done the exercise correctly; and, second, the --host is not ‘localhost’. Look this over again and see what you’re missing here. Good luck.

#3

Thanks for the reply. Sorry, questions were at the bottom. Basically, is it unusual, and under what circumstances does MongoDB not automatically use the subject name from the certificate file as the username.

To be clear, the exercise was literally to set up mongod servers with the following requirements:

  • Specific mongod listening ports
  • Specific certificate file locations
  • MongoDB servers configured in a replica set
  • TLS used for all connections

Based on the above, I met the requirements. Yet, the validation script didn’t work. Fortunately it was written in Bash instead of Go, so I was able to troubleshoot and identified that the script does not connect the way that MongoDB documents. When the script was changed so that it connects the way the documentation says that it should, it worked.

If other people are encountering the same issue, I can chalk it up to a bug in the validation script, because it is possible to set up servers that meet the requirements but for which the validation script doesn’t work. If I am the only one seeing this problem, then I probably set up the servers differently. Given that this week is still active, it would not be appropriate for me to paste the exact commands I used to stand up the servers. Instead, I am asking under what circumstances does mongod accept x.509 connections but require that the username be explicitly specified.

As far as the hostname, one was not specified as part of the homework problem. I used openssl to look at the server.pem certificate, and the first SAN is “localhost”, so I used it. Mongo did not throw any errors when connecting to it because it is valid. Since all three mongod processes run on the same VM, and I was only accessing it from the local VM, it seemed as good as any other name. If you are telling me that using “localhost” as the name causes this behavior, then you have answered my question. Otherwise, we simply have different choices in how we connect to the server.

#4

I can confirm that using the hostname database.m310.mongodb.university (for both the mongo host and for the replica set member names) has no effect. The validation script does not run without the extra parameters.

I referenced the official MongoDB documentation when setting up the servers and creating the x.509 user. Duplicating the behavior of making the script not work should be pretty easy.

One interesting thing to note is that the 4.0 documentation specifies that the additional arguments to mongo are necessary when connecting with x.509. Looking at the 3.2 version of the page does not show them.

I installed mtools to assist with some of the boilerplate deployments (although it was not used for this particular homework question, since mlaunch doesn’t allow TLS configuration). The mongod and mongo versions show 3.2.22, but I wonder if something else was updated that is causing it to use 4.0-ish behavior?

#5

@ ciscofu

Thanks for the clarification. Do I understand you correctly, that you are not using the supplied database VM for your work, but have deviated from that? In that case, you’re kind of on your own.

In the supplied VM, the MongoDB version is Enterprise 3.2.22 and, once the replica set is correctly set up and initiated, the script works fine as supplied, with no changes and no user name required.

I do agree that the hostname doesn’t seem to be the problem. I’ve tried every different combination that I can think of, and the script works with all of them

FWIW, you are the only student in 4 iterations of this course to have this problem, so my guess is that you’ve done something different in your setup (if you’re using the VM) or have deviated from the requirements in some way.

#6

I am using the supplied Vagrant VM (database) for the homework exercise. However, in case it was relevant, I wanted to point out that I did make some minor modifications to the VM. I installed mtools (using pip, which is installed by default) and its of course its dependencies (psutil and python-dev). I verified that both the MongoDB server and client versions were still 3.2.22 but wonder if something else may have been upgraded that changes MongoDB’s connectivity behavior.

Is there a way I can provide you with the steps I took so that you can identify what I am doing differently than you (and everyone else)? I use MongoDB in both development and production, and using x.509 is something that makes a lot of sense – it is one of the things I wanted to get out of this course. Seeing strange behavior that nobody can explain has me a little concerned though. Hopefully it’s nothing more than a mongod command-line option.

#7

A user being the only person to ask the question doesn’t make them the only ones to have the issue. I have the same problem and will likely modify the validation script as well if I don’t get an answer today.

Enabling TLS turns on authentication. This authentication makes it so the validation script can’t get the member info without authenticating first. The validation script doesn’t validate before requesting member info.

As an alternative, see the validation script from lab 1.3, which does validate first:

statusStr="var status = rs.status();
           delete status.codeName;
           print(JSON.stringify(status))"
memberStr="db = db.getSisterDB('\$external');
           db.auth({
             mechanism: 'MONGODB-X509',
             user: 'C=US,ST=New York,L=New York City,O=MongoDB,OU=University2,CN=M310 Client'
           });
           var status = rs.status();
           var statuses = status.members.map((member) => (member.stateStr)).sort();
           print(JSON.stringify(statuses));"
#8

@Jeffrey_45001

Indeed, very often more than one student makes the same error. That doesn’t make it correct, it just means that they are incorrect in the same way.

But honestly, if out of (at roughly current count while I’ve been a TA) ~4500 students have taken the course, and only 2 have the same problem, you might reasonably suppose that the error is in your setup or process, and not in the supplied script.

Finally, I would very strongly suggest that you open a new thread with a new post rather than trying to re-open a closed subject from 4 months ago and then say something like “… if I don’t get an answer today”. You are lucky that I happened to spot this.

#9