Wie man einen CSR auf Postfix generiert

Diese Anleitung zeigt Ihnen wie Sie einen CSR (Certificate Signing Request) auf Postfix erstellen, und zwar über die Kommandozeile mit OpenSSL. Postfix selbst generiert keine Schlüssel oder CSRs; es verwendet die von OpenSSL erzeugten Dateien und referenziert sie in /etc/postfix/main.cf. Sie führen einen einzigen Befehl aus, der gleichzeitig zwei Dateien erstellt: einen privaten Schlüssel, der auf dem Server verbleibt, und den CSR, den Sie bei Ihrer Zertifizierungsstelle (CA) einreichen.

Der CSR enthält den Hostnamen, den Ihr MTA bei STARTTLS präsentiert, Ihre Organisationsdaten sowie den öffentlichen Teil des Schlüssels. Der zugehörige private Schlüssel verlässt den Server nie. Geht er verloren, wird das ausgestellte Zertifikat unbrauchbar, und Sie müssen von vorne beginnen.

Voraussetzungen

• Root- oder sudo-Zugriff auf den Server, auf dem Postfix läuft.
• OpenSSL muss installiert sein. Es ist bei jeder gängigen Linux-Distribution im Basissystem enthalten; prüfen Sie dies mit openssl version.
• Der vollqualifizierte Mail-Hostname, der auf dem Zertifikat stehen soll, zum Beispiel mail.example.com. Dieser muss mit dem MX-Eintrag übereinstimmen, mit dem sich Clients über STARTTLS verbinden, nicht mit der reinen Apex-Domain.

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

Bewahren Sie das TLS-Material von Postfix in einem eigenen Verzeichnis unter /etc/postfix/ auf, damit die Berechtigungen leicht zu verwalten sind. Erstellen Sie es und beschränken Sie den Zugriff auf root:

sudo mkdir -p /etc/postfix/ssl
sudo chmod 700 /etc/postfix/ssl
cd /etc/postfix/ssl

Sie erzeugen den Schlüssel und den CSR innerhalb dieses Verzeichnisses und referenzieren sie anschließend in main.cf, nachdem die CA das Zertifikat ausgestellt hat.

Schritt 2: Privaten Schlüssel und CSR erzeugen

Führen Sie den folgenden Befehl aus. Er erzeugt den privaten Schlüssel und den CSR in einem Schritt und enthält den Subject Alternative Name (SAN), den moderne Browser, E-Mail-Clients und CAs voraussetzen. Der SAN muss den Mail-Hostnamen enthalten (denjenigen, auf den Ihr MX-Eintrag zeigt), nicht die reine Apex-Domain:

sudo openssl req -new -newkey rsa:2048 -nodes 
-keyout /etc/postfix/ssl/mail.example.com.key 
-out /etc/postfix/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 die Erklärung der einzelnen Bestandteile:

• req -new erstellt einen neuen Certificate Signing Request.
• -newkey rsa:2048 erzeugt einen neuen 2048-Bit-RSA-Privatschlüssel. 2048 Bit ist derzeit das Minimum für öffentliche Zertifikate; für einen größeren Schlüssel können Sie rsa:4096 verwenden.
• -nodes lässt den privaten Schlüssel unverschlüsselt (ohne Passphrase), sodass Postfix ihn beim Start ohne Abfrage laden kann.
• -keyout schreibt den privaten Schlüssel. Halten Sie diese Datei geheim und senden Sie sie niemandem, auch nicht der CA.
• -out schreibt den CSR, den Sie bei der CA einreichen.
• -subj füllt die Subjektfelder direkt aus, sodass der Befehl ohne interaktive Abfragen ausgeführt wird. Setzen Sie CN (Common Name) auf Ihren Mail-Hostnamen.
• -addext „subjectAltName=…“ fügt den SAN-Eintrag hinzu. CAs stellen 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 in Ihrem MX-Eintrag), und passen Sie die -subj-Werte an Ihre Organisation an. Der zweistellige Ländercode (C) muss in Großbuchstaben angegeben werden, zum Beispiel US oder GB. Bei einem domänenvalidierten (DV) Zertifikat werden die Organisationsfelder nicht überprüft, der Befehl benötigt aber trotzdem gültige Werte. Moderne OpenSSL-Versionen signieren 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 diese Zeile weg, und OpenSSL fragt Sie nach jedem Wert:

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

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

Mehrere Hostnamen abdecken

Wenn dieselbe Postfix-Instanz auf mehr als einem Namen antwortet (zum Beispiel sowohl mail.example.com als auch smtp.example.com, oder ein gemeinsames Zertifikat für Mail und Webmail), listen Sie jeden Hostnamen im SAN-Wert auf, getrennt durch Kommas:

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

Der Common Name sollte weiterhin der primäre Mail-Hostname sein. Die reine Apex-Domain in den SAN aufzunehmen, ist nur sinnvoll, wenn sich E-Mail-Clients jemals direkt damit verbinden; wenn Ihr MX-Eintrag auf einen Sub-Hostnamen verweist, benötigen Sie die Apex-Domain nicht im Zertifikat.

Lieber einen ECDSA-Schlüssel?

ECDSA-Schlüssel sind bei gleichem Sicherheitsniveau kleiner und schneller als RSA und werden von jedem aktuellen E-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 /etc/postfix/ssl/mail.example.com.key 
-out /etc/postfix/ssl/mail.example.com.csr 
-subj "/C=US/ST=YourState/L=YourCity/O=YourCompany/CN=mail.example.com" 
-addext "subjectAltName=DNS:mail.example.com"

Schritt 3: Den privaten Schlüssel schützen

Sperren Sie den privaten Schlüssel so ab, dass nur root ihn lesen kann. Postfix öffnet sein TLS-Material, bevor es Rechte abgibt, daher sind Root-Besitz und der Modus 600 sowohl korrekt als auch erforderlich:

sudo chown root:root /etc/postfix/ssl/mail.example.com.key
sudo chmod 600 /etc/postfix/ssl/mail.example.com.key

Die CSR-Datei ist nicht geheim (sie enthält nur den öffentlichen Schlüssel und Ihre Subjektdaten), aber sie im selben abgesicherten Verzeichnis aufzubewahren, hält die Struktur übersichtlich.

Schritt 4: Den CSR überprüfen

Bevor Sie den Antrag einreichen, überprüfen Sie, ob er den richtigen Hostnamen und SAN enthält und ob seine Signatur gültig ist. Dieser Befehl gibt den entschlüsselten Inhalt aus und prüft die Signatur lokal:

openssl req -noout -text -verify -in /etc/postfix/ssl/mail.example.com.csr

Achten Sie in der Ausgabe auf verify OK, prüfen Sie, ob die Zeile Subject Ihren Mail-Hostnamen als Common Name anzeigt, und stellen Sie sicher, dass der Abschnitt X509v3 Subject Alternative Name jeden erwarteten Hostnamen auflistet. Fehlt ein SAN, 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 ihren gesamten Inhalt, einschließlich der BEGIN- und END-Zeilen:

cat /etc/postfix/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 Postfix-SSL-Installation, um es bereitzustellen. Behalten Sie die .key-Datei auf dem Server: Sie benötigen sie zusammen mit dem ausgestellten Zertifikat, um STARTTLS bereitzustellen, und Sie dürfen sie niemals an die CA oder eine andere Person senden.

Wenn Sie lieber nicht die Kommandozeile verwenden möchten, erstellen Sie den Antrag 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 selben Pfad auf dem Server ablegen.

Wo die Dateien in Postfix eingebunden werden

Zur Einordnung: So werden die soeben erzeugten Dateien in Postfix eingebunden, sobald die CA das Zertifikat und das Zwischenzertifikat (CA-Bundle) zurückgeliefert hat. Ab Postfix 3.4 wird die empfohlene Einzeldirektiven-Form verwendet, die eine PEM-Datei erwartet, die den privaten Schlüssel gefolgt von der vollständigen Zertifikatskette enthält:

cat mail.example.com.key mail.example.com.crt intermediate.pem 
> /etc/postfix/ssl/mail.example.com.chain.pem
sudo chmod 600 /etc/postfix/ssl/mail.example.com.chain.pem

Dann in /etc/postfix/main.cf:

smtpd_tls_chain_files = /etc/postfix/ssl/mail.example.com.chain.pem
smtpd_tls_security_level = may

Bei Postfix-Versionen älter als 3.4 verwenden Sie das ältere Direktiven-Paar, wobei der Schlüssel und ein vollständiges Kettenzertifikat in getrennten Dateien liegen:

smtpd_tls_cert_file = /etc/postfix/ssl/mail.example.com.fullchain.crt
smtpd_tls_key_file  = /etc/postfix/ssl/mail.example.com.key
smtpd_tls_security_level = may

Die vollständige Installationsanleitung, einschließlich des Submission-Dienstes auf Port 587 und der Überprüfung mit OpenSSL, finden Sie in unserer Postfix-SSL-Installationsanleitung.

CSR auf anderen Mail-Plattformen erzeugen

Verwenden Sie einen anderen Mailserver oder Gateway? Sehen Sie sich unsere weiteren CSR-Anleitungen an:

• Courier IMAP Server
• Kerio Connect
• Qmail
• SurgeMail
• Zimbra
• Alle Anleitungen zur CSR-Erzeugung