Es scheint fast unvorstellbar, aber es gab eine Zeit, in der die Übertragung sensibler Informationen über das Internet ohne Verschlüsselung die Norm war. Ich erinnere mich noch gut an die Tage, als das kleine Schloss-Symbol in der Adressleiste eines Browsers eine Seltenheit war - eigentlich war es sogar untypisch.
HTTPS, das Protokoll, das für eine sichere Kommunikation im Internet sorgt, war einmal nicht der Standard. Dieser Wandel hin zu einer verschlüsselten Übertragung ist nicht nur auf Webseiten beschränkt, sondern erstreckt sich auf alle Bereiche der digitalen Kommunikation, einschließlich Datenbanksystemen wie MongoDB. Ähnlich wie Webseitenbetreiber ihre Seiten mit HTTPS absichern, sollten auch Datenbankadministratoren Maßnahmen ergreifen um ihre Datenbanken mit TLS abzusichern. Dieser Schritt ist unabdingbar, um die Vertraulichkeit und Integrität der übertragenen Daten zu gewährleisten und sie vor unbefugtem Zugriff Dritter zu schützen.
Zum Kapitel springen Was ist TLS?
TLS, kurz für Transport Layer Security, ist die wichtigste Technologie, die für die Verschlüsselung und Sicherheit im Internet sorgt. Als direkter Nachfolger von SSL (Secure Sockets Layer) dient TLS als Schutzschild für Daten, die zwischen zwei Systemen übertragen werden. Dies gilt für Webseiten und Browser, Datenbanken und Anwendungen und auch für viele andere Bereiche. Es verschlüsselt die Daten so, dass sie während der Übertragung vor Eingriffen, Abhöraktionen und anderen Formen von Angriffen geschützt sind.
Durch die Einrichtung von TLS für MongoDB stellen wir sicher, dass jede Datenübertragung zwischen unserer Datenbank und den anfragenden Systemen verschlüsselt und somit vor unbefugtem Zugriff geschützt ist.
Zum Kapitel springen Eigene TLS-Zertifikate
In diesem Tutorial konzentrieren wir uns auf einen besonders sicheren Ansatz zur Implementierung von TLS für MongoDB: die Erstellung und Nutzung eigener Zertifikate.
Dieser Weg erfordert, dass wir nicht nur Zertifikate für den Server generieren, sondern auch entsprechende Zertifikate für die Clients bereitstellen. Die Verwendung selbstsignierter Zertifikate stellt eine einfache Methode dar, um eine verschlüsselte Verbindung zwischen Datenbank und Client aufzubauen, ohne dabei auf externe Zertifizierungsstellen angewiesen zu sein.
Das Einrichten eigener Zertifikate für TLS trägt dazu noch wesentlich zur Erhöhung der Sicherheitsebene bei. Über die verschlüsselte Verbindung hinaus bietet dieser Ansatz nämlich einen weiteren zusätzlichen Sicherheitslayer. Neben den üblichen Zugangsdaten, also Benutzername und Passwort, erfordert der Zugriff auf die Datenbank nach diesem Beitrag zusätzlich die Authentifizierung mittels der Zertifikatsdateien.
Dies bedeutet, dass selbst im Falle eines kompromittierten Passworts der Zugang zur Datenbank ohne das entsprechende Zertifikat dennoch verwehrt bleibt. Diese zusätzliche Sicherheitsschicht gewährleistet, dass ausschließlich autorisierte Systeme und Personen Zugriff auf die Datenbank erhalten.
Zum Kapitel springen Übersicht der Zertifikate
Für die Sicherheit unserer MongoDB-Installation durch den zusätzlichen Sicherheitslayer, werden wir in diesem Tutorial drei Arten von Zertifikaten verwenden: das Root-CA-Zertifikat, das Serverzertifikat und das Clientzertifikat. Jedes dieser drei Zertifikate spielt eine entscheidende Rolle im Sicherheitsgefüge der Datenbankkommunikation.
Zertifikat | Beschreibung |
---|---|
Root-CA Zertifikat | Das Zertifikat für die eigene Certificate Authority |
Server Zertifikat | Das Zertifikat für den Server |
Client Zertifikat | Das Zertifikat für den Client |
Zum Kapitel springen Root-CA Zertifikat
Das Root-CA Zertifikat (Root Certificate Authority) ist das oberste Zertifikat in unserer Zertifikatskette und dient als vertrauenswürdige Quelle für die Authentizität anderer Zertifikate. Indem wir unser eigenes Root-CA erstellen, fungieren wir als unsere eigene Zertifizierungsstelle. Dies ermöglicht es uns, die Authentizität und Vertrauenswürdigkeit der Server- und Clientzertifikate selbst zu garantieren. Das Root-CA-Zertifikat ist quasi der Schlüsselhalter, der die Identität aller untergeordneten Zertifikate bestätigt.
Für diejenigen, die bereits mit dem Konzept von SSL/TLS-Zertifikaten vertraut sind, kann der Prozess der Erstellung eines eigenen Root-CA ähnlich dem sein, was Organisationen wie Let's Encrypt tun. Let's Encrypt ist eine weit verbreitete Certificate Authority, die kostenlose SSL/TLS-Zertifikate anbietet und damit eine sichere, verschlüsselte Kommunikation im Internet ermöglicht.
Die Verteilung des Root-CA-Zertifikats an jede Instanz, sowohl Server als auch Clients, ist ein entscheidender Schritt, um ein vertrauenswürdiges Sicherheitsnetzwerk aufzubauen. Dieses Zertifikat dient als vertrauenswürdige Referenz für die Überprüfung aller untergeordneten Zertifikate innerhalb der Zertifikatskette. Indem jede Instanz das Root-CA-Zertifikat besitzt, kann sie die Echtheit der von anderen Instanzen präsentierten Zertifikate überprüfen. In einem System, das auf selbstsignierten Zertifikaten wie unserem basiert, stellt das Root-CA-Zertifikat sicher, dass die Kommunikation ausschließlich zwischen verifizierten und vertrauenswürdigen Parteien stattfindet.
Ähnlich wie bei Let's Encrypt, wo das Root-CA-Zertifikat in den Browsern und Betriebssystemen der Nutzer hinterlegt ist, um die Echtheit der Webseiten zu bestätigen, muss in unserem Fall das selbstsignierte Root-CA-Zertifikat manuell zu den vertrauenswürdigen Zertifikaten auf Servern und Clients hinzugefügt werden. Dieser Schritt ist notwendig, da unser Root-CA nicht von den üblichen, vorinstallierten Trust Stores der Betriebssysteme und Browser anerkannt wird. Die manuelle Hinzufügung gewährleistet, dass unsere Zertifikate innerhalb unseres Netzwerks als vertrauenswürdig eingestuft werden, was eine sichere und authentifizierte Kommunikation ermöglicht.
Zum Kapitel springen Server Zertifikat
Das Serverzertifikat wird speziell für die Identifizierung und Authentifizierung unseres MongoDB-Servers verwendet. Es stellt sicher, dass die Clients, die eine Verbindung herstellen, tatsächlich mit dem richtigen Server kommunizieren. Das Serverzertifikat, signiert von unserem Root-CA, bestätigt die Serveridentität gegenüber den Clients und ermöglicht eine verschlüsselte Verbindung.
Zum Kapitel springen Client Zertifikat
Ähnlich wie das Serverzertifikat dient das Clientzertifikat der Authentifizierung des Clients gegenüber dem Server. Es gewährleistet, dass nur autorisierte Clients Zugriff auf den Server erhalten. Die Verwendung von Clientzertifikaten fügt eine zusätzliche Ebene der Sicherheit hinzu, da sich beide Seiten – Server und Client – gegenseitig ihre Identität bestätigen müssen, bevor eine Kommunikation stattfinden kann.
Produktempfehlungen und -suche in Verbindung mit dem Amazon Partnerprogramm:
¹ Angaben ohne Gewähr. Bei einem Kauf über den Link erhalten wir eine Provision.
Durch die Implementierung dieser Zertifikate in unser System stellen wir eine sichere TLS-Verbindung her, die nicht nur verschlüsselt ist, sondern wie bereits erwähnt auch eine beidseitige Authentifizierung erfordert. Dies schützt unsere Datenbank nochmals effektiver vor unbefugtem Zugriff und Datenlecks.
Zum Kapitel springen Vorraussetzungen
Bevor wir in die praktische Umsetzung gehen, ist es wichtig einige Voraussetzungen zu klären. In diesem Abschnitt gehe ich kurz darauf ein, welche Tools und Kenntnisse benötigt werden, um die Einrichtung eigener TLS-Zertifikate für MongoDB so einfach wie möglich zu gestalten.
Zum Kapitel springen Grundlagen MongoDB
Ein Verständnis der Grundlagen von MongoDB ist hilfreich, um die Schritte zur Absicherung der Datenbank nachvollziehen zu können.
Solltest du noch keine MongoDB-Instanz installiert haben, kann ich dir mein Tutorial MongoDB installieren - Die NoSQL Datenbank auf dem eigenen Server empfehlen. Dort wird nicht nur die Installation von MongoDB behandelt sondern auch eine grundlegende Konfiguration vorgenommen, um die Datenbank für den Produktivbetrieb vorzubereiten.
Anhand des verlinkten Tutorials erhältst du ebenfalls Zugriff auf die MongoDB von externen Systemen. Diese Verbindung kannst du nach diesem Tutorial hier dann mit TLS absichern. Hier findest du weitere Informationen um MongoDB mit TLS zu konfigurieren.
Zum Kapitel springen Verständnis von TLS/SSL
Die Erstellung und Verwaltung eigener Zertifikate im Bezug auf TLS und SSL ist kein triviales Unterfangen und erfordert mehr als nur das Kopieren und Einfügen von Befehlen. Dieses Tutorial setzt voraus, dass du nicht nur die Schritte nachvollziehst, sondern auch die Konzepte und Prinzipien hinter TLS und SSL verstehst. Das Ziel ist es, eine sichere Umgebung zu schaffen, in der Daten vertraulich und integer bleiben. Die Komplexität und Wichtigkeit der Absicherung digitaler Kommunikation darf nicht unterschätzt werden; ein fundiertes Wissen ermöglicht es dir, fundierte Entscheidungen zu treffen und deine Infrastruktur effektiv zu schützen. Wenn du diesen Beitrag bis hierhin aufmerksam gelesen hast, bist du bereits auf einem guten Weg.
Zum Kapitel springen Tools
Die Zertifikate werden wir mithilfe von OpenSSL erstellen. Stelle sicher, dass du dieses Tool auf deinem System installiert hast. Ich werde die Anleitung unter Linux Ubuntu durchführen. Der Befehl zum Installieren von OpenSSL lautet:
sudo apt update
sudo apt install openssl
Zum Kapitel springen Erstellen der Zertifikate
Auch wenn wir am Ende effektiv nur drei Dateien verwenden werden siehe: Übersicht der Zertifikate, müssen für das Ergebnis in drei Dateien insgesamt zehn Dateien erstellt werden. Das hat mit der sogenannten Trust of Chain / der vorhin genannten Zertifikatskette zu tun.
Alle Zertifikate in diesem Beitrag werden auf eine Gültigkeit von einem Jahr ausgestellt. Je nach Anwendung und Anforderung kann dieser Zeitraum angepasst werden. Das kann in den Befehlen mit der Änderung des Parameters -days 365
erfolgen. Einzelne Zertifikate können auch mit unterschiedlichen Gültigkeitsdauern ausgestellt werden.
Es macht keinen Sinn, ein Zertifikat länger auszustellen, als das Root-CA Zertifikat gültig ist. Sollte das Root-CA Zertifikat ungültig werden, so werden auch alle damit ausgestellten Zertifikate ungültig.
In diesem Tutorial werden wir die Zertifikate im Order /etc/ssl/mongodb
erstellen. Der Ort an dem du deine Zertifikate speicherst ist aber natürlich dir überlassen.
mkdir /etc/ssl/mongodb
Zum Kapitel springen Root-CA
Zunnächst wird das Root-CA Zertifikat erstellt. Die Informationen zur Root-CA findest du im Kapitel dazu.
Zum Kapitel springen Privater Schlüssel
Der erste Schritt besteht darin, den privaten Stammschlüssel zu erstellen. Im folgenden Beispiel erstellen wir einen 2048-Bit-Schlüssel:
openssl genrsa -out rootCA.key 2048
Sicherheitsrisiko
Halte diesen privaten Schlüssel streng geheim! Wenn jemand in den Besitz dieses Schlüssels kommt, kann er valide Zertifikate für dein Sicherheitsnetzwerk erstellen.
Zum Kapitel springen Zertifikat
Der nächste Schritt besteht darin, das Root-CA Zertifikat zu erstellen und es mit dem privaten Schlüssel zu signieren:
openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 365 -out rootCA.pem
Beim Ausführen des Befehls werden einige Daten verlangt. Diese dienen den Angaben der eigenen Certificate Authority. Da wir diese Authority im eigenen Sicherheitsgefüge verwenden bietet es sich an, die Daten dementsprechend auszufüllen.
You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]: ...
State or Province Name (full name) [Some-State]: ...
Locality Name (eg, city) []: ...
Organization Name (eg, company) [Internet Widgits Pty Ltd]: ...
Organizational Unit Name (eg, section) []: ...
Common Name (e.g. server FQDN or YOUR name) []: ...
Email Address []: ...
Bei der Angabe des Common Name (e.g. server FQDN or YOUR name) []
ist es wichtig, dass die Domain des Servers angegeben wird die auch als CA dient. FQDN steht für Fully Qualified Domain Name. In diesem Fall muss jedoch nicht zwangsweise eine Domain verwendet werden. Es kann auch eine IP Adresse angegeben werden.
Sollte die Angabe weder mit der tatsächlichen IP-Adresse oder der Domain übereinstimmen wird die Verbindung später abgelehnt.
Nach diesem Prozess sind die ersten beiden Dateien erstellt.
rootCA.key rootCA.pem
Diese beiden Dateien sind zentrale Bestandteile deiner eigenen Certificate Authority. Mit diesen beiden Dateien kannst du nun weitermachen und ein Server- sowie Clientzertifikat für deine MongoDB erstellen.
Du kannst deine CA in Zukunft übrigens auch für andere TLS-Verschlüsselungen in deinem Sicherheitsnetzwerk verwenden. Du bist nicht auf die Verwendung mit MongoDB beschränkt.
Die Datei rootCA.pem muss nun auf den Client kopiert und dort abgelegt werden.
Zum Kapitel springen Das Server Zertifikat
Als nächstes werden wir das Server-Zertifkat erstellen. Weitergehende Informationen dazu wurden bereits im Kapitel Server Zertifikat besprochen.
Zum Kapitel springen Privater Schlüssel
Dieser Schritt erzeugt einen neuen privaten Schlüssel, der speziell für deinen MongoDB-Server verwendet wird. Hiermit wird ein 2048-Bit langer privater RSA-Schlüssel erstellt und in der Datei mongodb.key gespeichert:
openssl genrsa -out mongodb.key 2048
Sicherheitsrisiko
Halte diesen privaten Schlüssel streng geheim!
Zum Kapitel springen Certificate Signing Request (CSR)
Mit der CSR beantragst du das Server-Zertifikat bei deiner eigenen CA. Der CSR enthält Informationen über deine Organisation und den Server, ähnlich wie bei der Erstellung des CA-Zertifikats. Der Befehl lautet:
Produktempfehlungen und -suche in Verbindung mit dem Amazon Partnerprogramm:
¹ Angaben ohne Gewähr. Bei einem Kauf über den Link erhalten wir eine Provision.
openssl req -new -key mongodb.key -out mongodb.csr
Bei der Angabe des Common Name (e.g. server FQDN or YOUR name) []
ist es wichtig, dass die IP-Adresse oder die Domain des MongoDB Servers angegeben wird. FQDN steht für Fully Qualified Domain Name. In diesem Fall muss jedoch nicht zwangsweise eine Domain verwendet werden. Es kann auch eine IP Adresse angegeben werden.
Sollte die Angabe weder mit der tatsächlichen IP-Adresse oder der Domain übereinstimmen wird die Verbindung abgelehnt.
You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]: ...
State or Province Name (full name) [Some-State]: ...
Locality Name (eg, city) []: ...
Organization Name (eg, company) [Internet Widgits Pty Ltd]: ...
Organizational Unit Name (eg, section) []: ...
Common Name (e.g. server FQDN or YOUR name) []: ...
Email Address []: ...
Die folgenden Parameter sind optional und werden nicht ausgefüllt:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Zum Kapitel springen CSR signieren
Jetzt muss das CSR mit dem Root-CA-Zertifikat und dem privaten Schlüssel vom Root-CA siginiert werden. Dieser Schritt erzeugt das eigentliche Server-Zertifikat für den MongoDB Server. Nutze zum Signieren den folgendem Befehl:
openssl x509 -req -in mongodb.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out mongodb.crt -days 365 -sha256
Dadurch wird das Zertifikat mongodb.crt erstellt und mit SHA-256 signiert.
Zum Kapitel springen PEM Datei erstellen
MongoDB erfordert üblicherweise, dass der private Schlüssel und das Server-Zertifikat in einer einzigen Datei: mongodb.pem zusammengefasst werden. Dies kannst du mit folgendem Befehl tun:
cat mongodb.key mongodb.crt > mongodb.pem
Jetzt hast du schon mal alles was du brauchst, um MongoDB für TLS zu konfigurieren. Neben den bereits ausgeführten Root-Dateien wurden zusätzlich folgende weitere Dateien erstellt:
mongodb.crt mongodb.csr mongodb.key mongodb.pem
Zum Kapitel springen MongoDB TLS konfigurieren
Um MongoDB für TLS zu konfigurieren musst du auf das MongoDB-Server-Zertifikat: mongodb.pem und das Root-CA-Zertifikat: rootCA.pem verweisen. Dies kannst du über die MongoDB Konfiguration erreichen.
nano /etc/mongod.conf
# mongod.conf
# for documentation of all options, see:
# http://docs.mongodb.org/manual/reference/configuration-options/
# Where and how to store data.
storage:
dbPath: /var/lib/mongodb
# engine:
# wiredTiger:
# where to write logging data.
systemLog:
destination: file
logAppend: true
path: /var/log/mongodb/mongod.log
# network interfaces
net:
port: 27017
bindIp: 0.0.0.0
tls:
mode: requireTLS
certificateKeyFile: /etc/ssl/mongodb/mongodb.pem
CAFile: /etc/ssl/mongodb/rootCA.pem
# how the process runs
processManagement:
timeZoneInfo: /usr/share/zoneinfo
#security:
#operationProfiling:
#replication:
#sharding:
## Enterprise-Only Options:
#auditLog:
Solltest du nach dem Hinzufügen der TLS-Einstellungen Probleme beim Starten der MongoDB haben, empfiehlt es sich einen Blick in die Logs zu werfen:
cat /var/log/mongodb/mongod.log
{"t":{"$date":"2024-09-21T21:30:24.682+00:00"},"s":"E", "c":"NETWORK", "id":23248, "ctx":"main","msg":"Cannot read certificate file","attr":{"keyFile":"/etc/ssl/mongodb/mongodb.pem","error":"error:FFFFFFFF8000000D:system library::Permission denied"}}
Um dieses Problem zu lösen musst du die Zertifikatsdateien mit den notwendigen Berechtigungen versehen. Üblicherweise gilt hier:
- Für Zertifikate im Allgemeinen:
chmod 755
- Für Root-CA im Allgemeinen:
chmod 644
Danach sollte der Fehler mit den fehlenden Berechtigungen verschwinden.
Durch den Parameter mode: requireTLS
kann absofort nur noch eine durch TLS verschlüsselte Verbindung zur MongoDB hergestellt werden. Dies gilt auch für die mongosh
.
TLS-Verbindungsstring mit MongoSH:
mongosh --tls --host {HOST} --port 27017 --tlsCAFile /etc/ssl/mongodb/rootCA.pem --tlsCertificateKeyFile /etc/ssl/mongodb/mongodb.pem -u {USERNAME} --authenticationDatabase {DATRABASE}
Nachdem wir das Server-Zertifikat bereits erstellt haben und auch der Server-interne, durch TLS verschlüsselte, Zugriff bereits möglich ist, werden wir uns als nächstes um die Clients bzw. die Anwendungen kümmern. Diese können sich ab hier nämlich auch nur noch mit passenden und gültigen Zertifikaten authentifizieren.
Zum Kapitel springen Client Zertifikat erstellen
Ähnlich wie du ein Server-Zertifikat erstellt hast, musst du nun ein Zertifikat für jeden Client oder zumindest für die Client-Anwendung erstellen. Dazu generierst du einen privaten Schlüssel und einen CSR (Certificate Signing Request) für den Client und lässt den CSR dann mit deinem Root-CA-Zertifikat signieren. Das Prozedere ist ähnlich dem des Server Zertifikats.
Zum Kapitel springen Privater Schlüssel
2048-Bit langen privaten RSA-Schlüssel erstellen und in der Datei client.key speichern:
openssl genrsa -out client.key 2048
Sicherheitsrisiko
Halte diesen privaten Schlüssel streng geheim!
Zum Kapitel springen Certificate Signing Request (CSR)
Certificate Signing Request mit Informationen über deine Organisation und den Server:
openssl req -new -key client.key -out client.csr
Bei der Angabe des Common Name (e.g. server FQDN or YOUR name) []
ist es wichtig, dass die IP-Adresse oder die Domain des MongoDB Servers angegeben wird. FQDN steht für Fully Qualified Domain Name. In diesem Fall muss jedoch nicht zwangsweise eine Domain verwendet werden. Es kann auch eine IP Adresse angegeben werden.
Sollte die Angabe weder mit der tatsächlichen IP-Adresse oder der Domain übereinstimmen wird die Verbindung abgelehnt.
You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]: ...
State or Province Name (full name) [Some-State]: ...
Locality Name (eg, city) []: ...
Organization Name (eg, company) [Internet Widgits Pty Ltd]: ...
Organizational Unit Name (eg, section) []: ...
Common Name (e.g. server FQDN or YOUR name) []:j {HOST} oder {DOMAIN}
Email Address []: ...
Die beiden folgenden Parameter sind optional und werden nicht ausgefüllt:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []: ...
An optional company name []: ...
Zum Kapitel springen CSR signieren
Die CSR muss ebenfalls mit dem Root-CA-Zertifikat und dem privaten Schlüssel vom Root-CA siginiert werden. Dieser Schritt erzeugt das eigentliche Client-Zertifikat:
openssl x509 -req -in client.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out client.crt -days 365 -sha256
Dadurch wird das Zertifikat client.crt erstellt und mit SHA-256 signiert.
Nach dem Ausfüllen der Daten hast du ingesamt wieder drei Dateien erstellt - diesmal für den Client.
client.crt client.csr client.key
Zum Kapitel springen PEM Datei erstellen
Für die Verwendung in der Client-Anwendung (z.B. Mongoose) müssen der privaten Schlüssel und das Client-Zertifikat möglicherweise wieder in einer PEM-Datei zusammengeführt werden:
cat client.key client.crt > client.pem
Die Datei client.pem muss nun auf den Client kopiert und dort abgelegt werden.
Zum Kapitel springen MongoDB-Verbindungsstring und -Optionen
Nach dem Erstellen der Dateien kann nun eine mit TLS-Verschlüsselte Verbindung zur MongoDB hergestellt werden. Aktualisiere dazu den Verbindungsstring und die Optionen in deiner Client-Anwendung. Diese muss so konfiguriert werden um das Client-Zertifikat-Datei: client.pem und das Root-CA-Zertifikat: rootCA.pem zu verwenden.
In Node.js mit Mongoose könnte das so aussehen:
const options = {
tls: true,
tlsCAFile: 'path/to/rootCA.pem',
tlsCertificateKeyFile: 'path/to/client.pem'
};
mongoose.connect('mongodb://{HOST}', options);
Weitere Infotmationen dazu findest du in der Mongoose-Dokumentation unter TLS.