Enable TLS for MongoDB

The fix/etc/mongod.conf

net:
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/mongodb/server.pem
    CAFile: /etc/ssl/mongodb/ca.pem

sudo systemctl restart mongod

Why it matters

Without TLS, every document you read, every document you write and the authentication exchange itself cross the network in cleartext. MongoDB’s SCRAM authentication resists replay of the stored credential, but it does nothing for the data — and the data is the entire point of a database.

The four modes, and the one that catches people

Mode	Accepts plaintext	Accepts TLS
disabled	yes	no
allowTLS	yes	yes
preferTLS	yes	yes
requireTLS	no	yes

allowTLS and preferTLS both still accept unencrypted connections. The difference between them is only what the server prefers for internal replication traffic — neither turns anything away.

This is the same trap as Postgres and MySQL, with an extra edge: preferTLS reads like it’s doing something protective, and it is a popular half-step. A server on preferTLS will report TLS working, show encrypted connections in your testing, and quietly accept the one legacy client still connecting in the clear.

requireTLS is the only mode that requires anything.

The certificate is one combined file

MongoDB wants the certificate and its private key concatenated into a single PEM, which is unusual enough to be a common first stumble:

cat server.crt server.key > /etc/ssl/mongodb/server.pem
sudo chown mongodb:mongodb /etc/ssl/mongodb/server.pem
sudo chmod 600 /etc/ssl/mongodb/server.pem

certificateKeyFile points at that combined file, not at a cert. If MongoDB refuses to start with a TLS error, this is the first thing to check.

The client half

A server requiring TLS stops eavesdropping. Only the client decides whether it verifies which server it reached:

mongodb://app:secret@db.internal:27017/appdb?authSource=admin&tls=true&tlsCAFile=/etc/ssl/ca.pem

tls=true encrypts and validates against the CA by default — MongoDB drivers verify certificates unless you tell them not to. The options that turn that off (tlsAllowInvalidCertificates, tlsAllowInvalidHostnames) exist for self-signed certificates and are frequently pasted in to “fix” a connection error. Each one gives up exactly the protection you enabled TLS for.

If a driver only connects with tlsAllowInvalidCertificates=true, the certificate is wrong. Fix the certificate.

Verify it worked

Confirm the mode on the running server:

db.adminCommand({ getCmdLineOpts: 1 }).parsed.net.tls

Expect { mode: 'requireTLS', ... }. Anything else accepts plaintext.

Then prove a plaintext connection is refused:

mongosh --host your.db --serverSelectionTimeoutMS 5000 --quiet --eval 'db.version()'

Expect a connection failure. And that TLS works:

mongosh --host your.db --tls --tlsCAFile /etc/ssl/mongodb/ca.pem \
  --quiet --eval 'db.version()'

Check the certificate independently of the driver:

openssl s_client -connect your.db:27017 -CAfile /etc/ssl/mongodb/ca.pem </dev/null 2>&1 \
  | grep -E 'Protocol|Cipher|Verify return code|subject='

Verify return code: 0 (ok) is what you want. Anything else means clients will need the options you don’t want them using.

Check expiry now rather than at 3am:

openssl x509 -in /etc/ssl/mongodb/server.pem -noout -enddate

Before you apply this

requireTLS disconnects every plaintext client at once, and MongoDB has no reload — the restart drops everything regardless.

Use preferTLS as a transition, not a destination:

1. Set preferTLS, restart. Nothing breaks; TLS is now available.
2. Migrate clients to tls=true one at a time.
3. Confirm nothing is left on plaintext — check currentOp for connections and your driver logs.
4. Set requireTLS, restart.

The failure mode of stopping at step 1 is believing you’re done. preferTLS in production for months is extremely common and it protects nobody who isn’t already asking for TLS.

On a replica set, TLS applies between members too. Enabling requireTLS on one member while the others are plaintext breaks replication immediately. Roll it out as: preferTLS on every member first (so all combinations work), then requireTLS on each in turn — secondaries first, primary last after stepping it down.

Certificate expiry is a hard outage, not a warning. Every member refuses connections, including from each other. Whatever issues these needs renewal automation and expiry monitoring before you depend on it.

Related

• Grant least privilege roles — the credential this protects.
• Enable authorization — do that first; it matters more.