Wie man einen CSR auf Qmail generiert

Diese Anleitung zeigt Ihnen wie Sie einen CSR (Certificate Signing Request) unter qmail erzeugen mithilfe der OpenSSL-Kommandozeile. Qmail (und sein aktiv gepflegter Fork notqmail) enthält kein integriertes CSR-Tool. Sie verwenden OpenSSL, um in einem Schritt zwei Dateien zu erstellen: einen privaten Schlüssel, der auf dem Server verbleibt, und den CSR, den Sie bei Ihrer Zertifizierungsstelle (CA) einreichen.

Der CSR kodiert den Mail-Hostnamen, den Ihr Server während STARTTLS präsentiert, Ihre Organisationsdaten sowie den öffentlichen Teil des Schlüssels. Der zugehörige private Schlüssel verlässt den Server niemals. Wenn Sie ihn verlieren, wird das ausgestellte Zertifikat unbrauchbar, und Sie müssen ein neues Schlüsselpaar erzeugen.

Ein Hinweis zu qmail vs. notqmail: Das ursprüngliche qmail wurde 1998 von Daniel J. Bernstein eingefroren und hat seither keine Upstream-Updates mehr erhalten. notqmail (aktuelle Version: 1.09, Mai 2024) ist der von der Community gepflegte Fork, der Sicherheitskorrekturen, aktuelle Build-Kompatibilität und fortlaufende Portabilitätsarbeit hinzufügt. TLS gehört nicht dazu: Sowohl bei notqmail als auch beim ursprünglichen qmail stammt STARTTLS aus einem externen Patch, und die Release-Notes zu 1.09 vermerken, dass der bestehende smtp-tls-Patch auf diese Version nicht anwendbar ist und ein neuer Upstream-Patch benötigt wird. Prüfen Sie den Patch-Status für die Version, die Sie betreiben, bevor Sie ein Zertifikat bestellen. Der Prozess zur CSR-Erzeugung ist bei beiden identisch, da er OpenSSL und nicht ein qmail-Binary verwendet. Wenn Sie noch das ursprüngliche qmail betreiben, sollten Sie den Umstieg auf notqmail oder Postfix erwägen, um weiterhin Sicherheitsunterstützung zu erhalten.

Voraussetzungen

• Root- oder sudo-Zugriff auf den Server, auf dem qmail (oder notqmail) läuft.
• OpenSSL muss installiert sein. Es ist im Basissystem jeder gängigen Linux- und BSD-Distribution enthalten. Prüfen Sie dies mit openssl version.
• Der vollqualifizierte Mail-Hostname, den Sie auf dem Zertifikat haben möchten, zum Beispiel mail.example.com. Dieser muss dem MX-Eintrag entsprechen, mit dem sich Clients über STARTTLS verbinden, nicht der reinen Apex-Domain.

Schritt 1: Verzeichnis für Schlüssel und CSR vorbereiten

Qmail-smtpd liest sein TLS-Zertifikat aus /var/qmail/control/servercert.pem, dem Pfad, der im TLS-Patch fest vorgegeben ist. Erstellen Sie ein Unterverzeichnis für das Schlüsselmaterial und schränken Sie den Zugriff auf root ein:

sudo mkdir -p /var/qmail/control/ssl
sudo chmod 700 /var/qmail/control/ssl
cd /var/qmail/control/ssl

Sie erzeugen Schlüssel und CSR in diesem Verzeichnis. Nachdem die CA das Zertifikat ausgestellt hat, kombinieren Sie die Dateien zu der servercert.pem, die qmail-smtpd beim Start einliest.

Schritt 2: Privaten Schlüssel und CSR erzeugen

Führen Sie den folgenden Befehl aus. Er erstellt den privaten Schlüssel und den CSR in einem Schritt und enthält den Subject Alternative Name (SAN), den moderne Mail-Clients und CAs verlangen. Der SAN muss den Mail-Hostnamen auflisten (den, auf den Ihr MX-Eintrag verweist):

sudo openssl req -new -newkey rsa:2048 -nodes 
-keyout /var/qmail/control/ssl/mail.example.com.key 
-out /var/qmail/control/ssl/mail.example.com.csr 
-subj "/C=US/ST=YourState/L=YourCity/O=YourCompany/CN=mail.example.com" 
-addext "subjectAltName=DNS:mail.example.com"

Hier ist, was jeder Teil bewirkt:

• req -new erstellt eine neue Zertifikatsanforderung.
• -newkey rsa:2048 erzeugt einen neuen 2048-Bit-RSA-Privatschlüssel. 2048 Bit sind derzeit das Minimum für öffentliche Zertifikate; Sie können rsa:4096 für einen größeren Schlüssel verwenden.
• -nodes lässt den privaten Schlüssel unverschlüsselt (ohne Passphrase), damit qmail-smtpd ihn beim Start ohne Nachfrage laden kann.
• -keyout schreibt den privaten Schlüssel. Halten Sie diese Datei geheim und senden Sie sie niemals an jemanden, auch nicht an die CA.
• -out schreibt den CSR, den Sie bei der CA einreichen.
• -subj füllt die Subject-Felder direkt aus, sodass der Befehl ohne interaktive Abfragen läuft. Setzen Sie CN (Common Name) auf Ihren Mail-Hostnamen.
• -addext „subjectAltName=…“ fügt den SAN-Eintrag hinzu. CAs stellen Zertifikate anhand der SAN-Liste aus, daher muss der Mail-Hostname hier erscheinen.

Ersetzen Sie mail.example.com durch den tatsächlichen Hostnamen, mit dem sich Clients verbinden (häufig derselbe Name wie Ihr MX-Eintrag), und passen Sie die -subj-Werte an Ihre Organisation an. Der zweistellige Ländercode (C) muss großgeschrieben werden, zum Beispiel US oder GB. Bei einem domänenvalidierten (DV) Zertifikat werden die Organisationsfelder nicht überprüft, aber der Befehl benötigt trotzdem gültige Werte. Modernes OpenSSL signiert den CSR standardmäßig mit SHA-256, was von jeder öffentlichen CA verlangt wird.

Wenn Sie die Felder lieber interaktiv statt mit -subj ausfüllen möchten, lassen Sie dieses Flag weg, und OpenSSL fragt Sie nach jedem Wert:

sudo openssl req -new -newkey rsa:2048 -nodes 
-keyout /var/qmail/control/ssl/mail.example.com.key 
-out /var/qmail/control/ssl/mail.example.com.csr 
-addext "subjectAltName=DNS:mail.example.com"

Lassen Sie bei der Abfrage das Challenge Password und den optionalen Firmennamen leer, indem Sie einfach Enter drücken. CAs ignorieren diese Felder, und ein Challenge-Passwort verursacht später Probleme.

Mehr als einen Hostnamen abdecken

Wenn dieselbe qmail-Instanz auf mehr als einen Namen antwortet (zum Beispiel sowohl mail.example.com als auch smtp.example.com), listen Sie jeden Hostnamen im SAN-Wert auf, durch Kommas getrennt:

-addext "subjectAltName=DNS:mail.example.com,DNS:smtp.example.com"

Der Common Name sollte weiterhin der primäre Mail-Hostname sein. Die reine Apex-Domain dem SAN hinzuzufügen ist nur sinnvoll, wenn sich Mail-Clients jemals direkt mit ihr verbinden; wenn Ihr MX-Eintrag auf einen Sub-Hostnamen verweist, benötigen Sie die Apex-Domain nicht auf dem Zertifikat.

Bevorzugen Sie einen ECDSA-Schlüssel?

ECDSA-Schlüssel sind bei gleichem Sicherheitsniveau kleiner und schneller als RSA und werden von jedem aktuellen Mail-Client und jeder CA unterstützt. Um stattdessen einen P-256-Schlüssel (prime256v1) und CSR zu erzeugen, tauschen Sie das Argument -newkey aus:

sudo openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -pkeyopt ec_param_enc:named_curve -nodes 
-keyout /var/qmail/control/ssl/mail.example.com.key 
-out /var/qmail/control/ssl/mail.example.com.csr 
-subj "/C=US/ST=YourState/L=YourCity/O=YourCompany/CN=mail.example.com" 
-addext "subjectAltName=DNS:mail.example.com"

Beachten Sie, dass das ursprüngliche qmail mit DJB’s TLS-Patches ECDSA möglicherweise nicht unterstützt. Wenn Sie notqmail mit einem aktuellen OpenSSL betreiben, funktioniert ECDSA ohne Probleme.

Schritt 3: Den privaten Schlüssel schützen

Sperren Sie den privaten Schlüssel so ab, dass nur root ihn lesen kann. Die rohe Schlüsseldatei wird nur benötigt, wenn Sie später die kombinierte servercert.pem erstellen, daher sind Root-Eigentümerschaft und Modus 600 korrekt:

sudo chown root:root /var/qmail/control/ssl/mail.example.com.key
sudo chmod 600 /var/qmail/control/ssl/mail.example.com.key

Die CSR-Datei ist nicht geheim (sie enthält nur den öffentlichen Schlüssel und Ihre Subject-Daten), aber sie im gleichen abgesperrten Verzeichnis zu belassen, hält die Struktur übersichtlich.

Schritt 4: Den CSR überprüfen

Bevor Sie die Anforderung einreichen, bestätigen Sie, dass sie den richtigen Hostnamen und SAN enthält und dass ihre Signatur gültig ist:

openssl req -noout -text -verify -in /var/qmail/control/ssl/mail.example.com.csr

Achten Sie auf verify OK in der Ausgabe, prüfen Sie, dass die Zeile Subject Ihren Mail-Hostnamen als Common Name zeigt, und bestätigen Sie, dass der Abschnitt X509v3 Subject Alternative Name jeden erwarteten Hostnamen aufführt. Falls ein SAN fehlt, erzeugen Sie den CSR mit dem korrekten -addext-Wert neu: Eine CA kann nach der Ausstellung keine Hostnamen mehr hinzufügen. Sie können den CSR auch in unseren Online-CSR-Decoder einfügen, um diese Felder im Browser zu prüfen.

Schritt 5: Den CSR einreichen

Öffnen Sie die CSR-Datei und kopieren Sie deren gesamten Inhalt, einschließlich der BEGIN- und END-Zeilen:

cat /var/qmail/control/ssl/mail.example.com.csr

Der Block sieht folgendermaßen aus. Kopieren Sie alles von der ersten bis zur letzten Zeile, einschließlich der fünf Bindestriche auf jeder Seite der BEGIN- und END-Markierungen:

-----BEGIN CERTIFICATE REQUEST-----
MIIC...base64-encoded data...AB
-----END CERTIFICATE REQUEST-----

Fügen Sie diesen Block in Ihr SSL-Bestellformular ein. Nachdem die CA den CSR validiert und das Zertifikat ausgestellt hat, folgen Sie unserer Anleitung zur SSL-Installation für qmail, um es zu implementieren. Bewahren Sie die .key-Datei auf dem Server auf: Sie benötigen sie zusammen mit dem ausgestellten Zertifikat, um STARTTLS zu aktivieren, und Sie dürfen sie niemals an die CA oder eine andere Person senden.

Wenn Sie die Kommandozeile lieber nicht verwenden möchten, erstellen Sie die Anforderung mit unserem CSR-Generator und fügen Sie das Ergebnis in Ihre Bestellung ein. Der Generator liefert einen passenden privaten Schlüssel, den Sie am gleichen Pfad auf dem Server ablegen.

Wo die Dateien in qmail landen

Zum Kontext: So werden die soeben erzeugten Dateien in qmail eingebunden, nachdem die CA das Zertifikat und das Zwischenzertifikat (CA-Bundle) zurückgegeben hat. Qmail-smtpd liest sein TLS-Material aus einer einzelnen kombinierten PEM-Datei unter /var/qmail/control/servercert.pem. Diese Datei muss den privaten Schlüssel, das Serverzertifikat und die Zwischenzertifikate in dieser Reihenfolge aneinandergehängt enthalten:

cat mail.example.com.key mail.example.com.crt intermediate.pem 
> /var/qmail/control/servercert.pem
sudo chown root:nofiles /var/qmail/control/servercert.pem
sudo chmod 640 /var/qmail/control/servercert.pem

Die Gruppe nofiles ist die Standardgruppe für den Benutzer qmaild, unter dem qmail-smtpd läuft. Modus 640 erlaubt qmaild, die Datei über die Gruppenmitgliedschaft zu lesen, während sie für andere Benutzer unlesbar bleibt. Wenn Ihr System eine andere Gruppe für qmaild verwendet, setzen Sie diesen Gruppennamen im Befehl chown ein.

Qmail-smtpd bietet STARTTLS nur an, wenn es mit TLS-Unterstützung erstellt wurde, was weder das ursprüngliche qmail noch notqmail von sich aus mitliefert. Der übliche Weg bei beiden ist Frederik Vermeulens qmail-tls-Patch: Er bewirkt, dass qmail-smtpd servercert.pem einliest und STARTTLS ankündigt, sobald diese Datei vorhanden ist. Der andere Weg ist Erwin Hoffmanns s/qmail mit ucspi-ssl, bei dem sslserver die Umgebungsvariable UCSPITLS in /service/qmail-smtpd/run exportiert und der Schlüssel in einer separaten serverkey.pem liegt, sodass die oben beschriebene Einzeldatei-Struktur dort nicht gilt. Nachdem Sie die kombinierte PEM-Datei platziert haben, starten Sie den Dienst qmail-smtpd neu:

sudo svc -t /service/qmail-smtpd

Die vollständige Installationsanleitung, einschließlich der Überprüfung der Zertifikatskette mit OpenSSL, finden Sie in unserer Anleitung zur SSL-Installation für qmail.

STARTTLS nach der Installation überprüfen

Sobald das Zertifikat installiert ist, bestätigen Sie, dass Ihr Server STARTTLS ankündigt und eine gültige Kette bereitstellt:

openssl s_client -connect mail.example.com:25 -starttls smtp -servername mail.example.com

Achten Sie auf Verify return code: 0 (ok) und bestätigen Sie, dass Subject und Aussteller mit Ihrem Zertifikat übereinstimmen. Sie können den Server auch mit unserem SSL Checker scannen, um einen visuellen Bericht über die Zertifikatskette und das Ablaufdatum zu erhalten.

CSR auf anderen Mail-Plattformen erzeugen

Betreiben Sie einen anderen Mailserver? Sehen Sie sich unsere weiteren CSR-Anleitungen an:

• Courier IMAP Server
• Kerio Connect
• Postfix
• Proxmox
• SurgeMail
• Zimbra
• Alle CSR-Generierungsanleitungen