Tanpa TLS, setiap byte yang berjalan antara aplikasi dan MongoDB — query, hasil query, sampai password yang Anda kirim saat createUser — bergerak sebagai teks polos yang bisa dibaca pihak penyadap jaringan. Encryption in transit menutup celah itu: klien dan server berjabat tangan lewat protokol TLS, menyepakati kunci, lalu seluruh percakapan berikutnya terenkripsi. Chapter ini menjalankan lab TLS sungguhan: satu server mongod sementara dengan sertifikat self-signed di port 28018, lalu kita buktikan tiga skenario koneksi — ditolak, tidak dipercaya, dan berhasil.

Peta materi Chapter ini:

  • Empat mode TLS pada net.tls.mode dan strategi migrasinya.
  • Membuat sertifikat self-signed dengan openssl dan mengaktifkan TLS di konfigurasi.
  • Tiga skenario koneksi nyata: tanpa TLS, TLS tanpa tlsCAFile, dan TLS lengkap.
  • Perbedaan sertifikat self-signed dan CA, serta TLS di MongoDB Atlas.

Empat Mode TLS #

TLS dikendalikan oleh net.tls.mode di file konfigurasi. Empat nilainya membentuk tangga migrasi:

ModeKoneksi masukKeterangan
disabledHanya non-TLSTLS mati total — keadaan server latihan kita
allowTLSNon-TLS dan TLSTransisi; umumnya untuk anggota cluster lawas
preferTLSNon-TLS dan TLSKoneksi antar-server memakai TLS
requireTLSHanya TLSKlien non-TLS ditolak sejak jabat tangan

Untuk server baru, langsung gunakan requireTLS. Untuk cluster hidup yang klien-nya belum siap, naik bertahap: preferTLS lebih dulu, lalu requireTLS setelah semua klien bermigrasi — strategi resmi yang dianjurkan dokumentasi MongoDB.

Menyiapkan Sertifikat Self-Signed #

Lab ini berjalan sepenuhnya di mesin lokal dan tidak menyentuh server bersama kita. Kita butuh tiga berkas: kunci privat, sertifikat, dan gabungan keduanya (format PEM yang dibaca certificateKeyFile). Perintah openssl berikut membuat semuanya:

bash 
openssl req -newkey rsa:2048 -nodes -keyout kunci-server.pem -out server.csr \
  -subj "/CN=localhost/O=Latihan MongoDB/C=ID"
openssl x509 -req -in server.csr -signkey kunci-server.pem -days 365 -out sert-server.pem \
  -extfile <(printf "subjectAltName=DNS:localhost,IP:127.0.0.1")
cat sert-server.pem kunci-server.pem > bundle-server.pem

Output yang Dihasilkan (baris progress pembuatan kunci dihilangkan):

text 
Certificate request self-signature ok
subject=CN=localhost, O=Latihan MongoDB, C=ID

Opsi -extfile yang memuat subjectAltName bukan hiasan — tanpa field SAN, klien modern menolak mencocokkan alamat meskipun CN sudah benar. Kita periksa hasilnya:

bash 
openssl x509 -in sert-server.pem -noout -subject -ext subjectAltName

Output yang Dihasilkan:

text 
subject=CN=localhost, O=Latihan MongoDB, C=ID
X509v3 Subject Alternative Name:
    DNS:localhost, IP Address:127.0.0.1

Menyalakan requireTLS #

Berikut konfigurasi lengkap server lab (simpan sebagai mongod-tls.conf, jalankan dengan mongod --config mongod-tls.conf):

text 
net:
  bindIp: 127.0.0.1
  port: 28018
  tls:
    mode: requireTLS
    certificateKeyFile: /tmp/tls-lab/bundle-server.pem
    CAFile: /tmp/tls-lab/sert-server.pem
    allowConnectionsWithoutCertificates: true
storage:
  dbPath: /tmp/tls-lab/data
systemLog:
  destination: file
  path: /tmp/tls-lab/mongod.log
  logAppend: true

Tiga baris di blok tls penting untuk dipahami:

  1. certificateKeyFile: sertifikat dan kunci privat server dalam satu berkas PEM — identitas yang dipresentasikan kepada klien.
  2. CAFile: rantai kepercayaan. Sejak MongoDB 9.0, menjalankan TLS tanpa rantai kepercayaan tidak lagi diizinkan (galat The use of TLS without specifying a chain of trust is no longer supported); sertifikat self-signed kita berperan sebagai CA-nya sendiri.
  3. allowConnectionsWithoutCertificates: true: secara default, server yang memiliki CAFile menuntut setiap klien mempresentasikan sertifikat. Nilai true mengizinkan klien SCRAM biasa — pola umum produksi saat Anda ingin enkripsi TLS tanpa authentication x.509.

Setelah server hidup, log-nya mengonfirmasi TLS aktif — perhatikan "ssl":"on":

text 
"msg":"Waiting for connections","attr":{"port":28018,"ssl":"on"}

Tiga Skenario Koneksi #

Skenario pertama: klien lama tanpa TLS. Server requireTLS menutup koneksi itu sejak awal:

bash 
mongosh "mongodb://127.0.0.1:28018/?directConnection=true" --quiet --eval 'db.adminCommand({ping: 1})'

Output yang Dihasilkan:

text 
MongoServerSelectionError: connection <monitor> to 127.0.0.1:28018 closed

Skenario kedua: klien mengaktifkan tls=true tetapi tidak membawa CA apa pun. Jabat tangan TLS berjalan, lalu klien menolak sertifikat yang tidak dikenalnya:

bash 
mongosh "mongodb://127.0.0.1:28018/?directConnection=true&tls=true" --quiet --eval 'db.adminCommand({ping: 1})'

Output yang Dihasilkan:

text 
MongoNetworkError: self-signed certificate; if the root CA is installed locally, try running Node.js with --use-system-ca

Skenario ketiga: klien mempercayai sertifikat kita lewat parameter tlsCAFile — dan koneksi akhirnya berhasil:

bash 
mongosh "mongodb://127.0.0.1:28018/?directConnection=true&tls=true&tlsCAFile=/tmp/tls-lab/sert-server.pem" --quiet --eval 'db.adminCommand({ping: 1}).ok'

Output yang Dihasilkan:

text 
1

Nilai 1 adalah ok: 1 dari ping — kini seluruh percakapan klien-server berjalan terenkripsi. Parameternya juga berlaku di connection string aplikasi: mongodb://host:28018/?tls=true&tlsCAFile=/jalan/ke/ca.pem. Setelah selesai bereksperimen, matikan server lab Anda (proses mongod milik sendiri, bukan server bersama).

Memeriksa TLS dari Dalam mongosh #

Dua perintah ringkas memungkinkan kita memeriksa status TLS tanpa membuka file konfigurasi. Yang pertama membaca mode TLS yang sedang berjalan pada server yang kita hubungi:

js 
db.adminCommand({ getParameter: 1, tlsMode: 1 })

Output yang Dihasilkan (bagian $clusterTime dan operationTime diringkas):

text 
{
  tlsMode: 'disabled',
  ok: 1
}

Nilai disabled menegaskan koneksi kita ke server latihan memang tidak terenkripsi — sesuai desain latihan. Perintah kedua menanyakan library TLS yang dipakai mongod — informasi yang berguna saat audit versi:

js 
db.adminCommand({ buildInfo: 1 }).openssl

Output yang Dihasilkan:

text 
{
  running: 'OpenSSL 3.5.7 9 Jun 2026',
  compiled: 'OpenSSL 3.5.4 30 Sep 2025'
}

Field running menunjukkan versi OpenSSL yang aktif di proses, sedangkan compiled versi saat mongod dibangun. Ketika kerentanan TLS dipublikasikan, dua angka inilah yang Anda bandingkan dengan imbauan keamanan.

Self-Signed, CA, dan Atlas #

Sertifikat self-signed cocok untuk lab dan jaringan tertutup, tetapi setiap klien harus diberi tlsCAFile secara eksplisit — persis galat skenario kedua di atas. Deployment produksi memakai sertifikat yang diterbitkan CA internal organisasi atau CA publik; klien sudah mempercayai root CA tersebut sehingga konfigurasi lebih ringkas, dan rotasi sertifikat kedaluwarsa menjadi prosedur terjadwal (server memberi peringatan 30 hari sebelum kedaluwarsa). Untuk authentication berbasis sertifikat klien (x.509), buang allowConnectionsWithoutCertificates — setiap klien wajib mempresentasikan sertifikat yang divalidasi terhadap CAFile, topik yang menyambung ke mekanisme x.509 di Chapter Authentication.

Di MongoDB Atlas, TLS selalu aktif untuk semua cluster — Anda tidak perlu (dan tidak bisa) mematikannya, cukup mengunduh sertifikat CA Atlas untuk koneksi aplikasi.

Rangkuman #

  • Empat mode net.tls.mode membentuk tangga migrasi; server baru langsung requireTLS.
  • Sertifikat self-signed cukup untuk lab; sertakan subjectAltName, gabungkan sertifikat dan kunci menjadi satu PEM untuk certificateKeyFile.
  • MongoDB 9.0 mewajibkan rantai kepercayaan (CAFile); klien SCRAM tanpa sertifikat membutuhkan allowConnectionsWithoutCertificates: true.
  • Klien mengaktifkan TLS dengan tls=true dan mempercayai server lewat tlsCAFile; tanpa keduanya masing-masing gagal dengan galat berbeda.
  • Produksi memakai CA internal/publik dan memantau kedaluwarsa sertifikat; Atlas mengaktifkan TLS secara permanen.