Erstellung einer Zertifikatsanforderung (CSR)
Exchange Server benötigt ein gültiges TLS-Zertifikat, um sichere Kommunikation über HTTPS und SMTP zu gewährleisten. Für die Ausstellung eines Zertifikates ist eine Zertifikatsanforderung (CSR, Certificate Signing Request) erforderlich.
Die manuelle Erstellung einer solchen Zertifikatsanforderung mit einer INF-Datei und dem Windows-Tool certreq bietet einen entscheidenden Vorteil gegenüber dem grafischen Zertifikat-Dialog in der IIS-MMC: die Wiederholbarkeit. Mit einer INF-Datei kannst du den Prozess jederzeit reproduzieren, dokumentieren und automatisieren.
Die Erstellung der Zertifikatanforderung muss nicht zwingend auf einem Exchange Server erfolgen. Oftmals wird dies auf einem zentralen System, z.B. einem Exchange Admin-Client, durchgeführt.
Wichtig ist, dass das vollständige Zertifikat als kennwortgeschützte PFX-Datei an einem sicheren Ablageort gespeichert wird. So kann im Notfall bei einer Serverwiederherstellung leicht auf das Zertifikat zurückgegriffen werden. Das Kennwort der PFX-Datei solltest du in einem Passwort-Safe hinterlegen.
Voraussetzungen
- Administrative Berechtigungen auf dem Exchange-Server oder einem Admin Server
- Kenntnis des Exchange-Namensraumes (z. B. mail.contoso.com, autodiscover.contoso.com)
- Zugriff auf die Windows-Eingabeaufforderung
- Entscheidung über die Exportierbarkeit des privaten Schlüssels
- Wichtig: Vor Ausstellung des Zertifikats erfolgt eine Überprüfung durch die Zertifizierungsstelle (CA).
Diese kann erfolgen durch:- Eintragen eines DNS-TXT-Records
- Bereitstellung einer TXT-Datei auf einem Webserver
- E-Mail-Validierung
Bei Unternehmenszertifikaten mit erweiterter Validierung (EV) kann zusätzlich ein Handelsregisterauszug erforderlich sein. Dies verzögert die Ausstellung.
Schritt 1: INF-Datei erstellen
Die INF-Datei definiert die Parameter für die Zertifikatsanforderung.
Ein Beispiel für ein SAN-Zertifikat mit mehreren Hostnamen:
Ein Beispiel für ein Zertifikat mit einem Hostnamen:
Erläuterungen
- Subject: Muss mindestens den Eintrag CN=<Hostname> enthalten
Der Vollständigkeit halber werden oft weitere Angaben ergänzt, z. B.:
CN=mail.varunagroup.de,OU=IT,O=Varunagroup AG,L=Berlin,S=BE,C=DE
Diese Angaben beschreiben die Organisationseinheit (OU) im Unternehmen, die Organisation (O), den Ort (L), das Bundesland (S) und das Land (C) - KeyLength: 2048 Bit gilt inzwischen als unsicher.
4096 Bit sind empfehlenswert, können aber zu Problemen mit älteren Clients führen. Im Regelfall sollte die Sicherheit ausschlaggebend sein - Exportable: TRUE ermöglicht den Export des privaten Schlüssels (siehe Risiken unten)
- Extensions: Enthält alle SAN-Einträge (Subject Alternative Names) für Exchange
Exportierbarkeit des privaten Schlüssels
Vorteile:
- Ermöglicht das Backup oder die Migration des Zertifikats auf andere Server.
Risiken:
- Erhöht die Gefahr, dass der private Schlüssel kompromittiert wird, wenn er nicht sicher gespeichert wird.
- Empfehlung: Nur aktivieren, wenn zwingend erforderlich (z. B. für Load-Balancer oder Cluster).
Schritt 2: CSR mit certreq erstellen
Speichern Sie die INF-Datei z. B. als request.inf und führe folgenden Befehl in einer adminstrativen Kommandozeile aus:
Erläuterungen
- request.inf: Dateiname der zuvor erstellten INF-Konfigurationsdatei
- request.csr: Dateiname der zu erstellenden Zertifikatanforderung
Die Datei request.csr enthält die Zertifikatsanforderung. Bereitstellung an die CA:
- Entweder die Datei direkt an das CA-Team senden
- den Inhalt der Datei in das Webportal eines Drittanbieter-CAs einfügen
certreq -new request.inf request.csr
Schritt 3: Zertifikat einbinden
Nach Erhalt des Zertifikats von der Zertifierungsstelle installieren du es mit:
certreq -accept certificate.cer
Erläuterungen
- Die ursprüngliche Anfrage (CSR) wird mit dem ausgestellten Zertifikat zusammengeführt
- Das Zertifikat wird dem privaten Schlüssel zugeordnet und in den Zertifikatsspeicher des Servers installiert
- Exchange kann das Zertifikat nun für TLS-Verbindungen aktiviert werden (wenn der CSR auf einem Exchange Server erstellt wurde)
Best Practices
- Verwende starke Schlüssel (4096 Bit, wenn möglich)
- Minimiere die Anzahl der SAN-Einträge auf das Notwendige
- Nutze Wildcard-Zertifikate (*.contoso.com) nur im Ausnahmefall
- Schütze die PFX-Sicherungsdatei (Zertifikat mit privatem Schlüssel) mit NTFS-Berechtigungen und ggf. Hardware-Sicherheitsmodule (HSM)
- Dokumentiere den Prozess für Audits und Wiederholbarkeit