So installieren Sie ein kommerzielles SSL-Zertifikat auf einem Zimbra-Server

Ein kommerzielles SSL-Zertifikat auf Zimbra kann aus verschiedenen Gründen fehlschlagen, selbst wenn die Zertifizierungsstelle die korrekte Ausstellung bestätigt. Die häufigsten Probleme liegen in der Regel nicht am Zertifikat selbst: Der private Schlüssel stimmt nicht mit dem ausgestellten Zertifikat überein, eine Zwischenzertifizierungsstelle fehlt, der Hostname fehlt im Subject Alternative Name (SAN) des Zertifikats oder der Administrator stellt die Dateien bereit, bevor er die Zertifikatskette validiert hat.

Am sichersten ist es, den Vorgang als eine Abfolge von Prüfungen und nicht als einen einzigen Befehl zum Installieren des Zertifikats zu behandeln. Das dokumentierte Zertifikatstool von Zimbra zmcertmgrkann eine Zertifikatsignierungsanforderung (CSR) erstellen, den privaten Schlüssel und die CA-Kette überprüfen, das Zertifikat für Zimbra-Dienste bereitstellen und das aktuell aktive Zertifikat anzeigen. Die offiziellen Befehle sind im Leitfaden „Administrationskonsole und CLI-Zertifikatstools“ des Zimbra Tech Centers dokumentiert .

So sollte eine erfolgreiche Zimbra SSL-Installation aussehen

Bevor Sie Änderungen vornehmen, definieren Sie das gewünschte Ergebnis. Eine korrekte Bereitstellung sollte alle folgenden Bedingungen erfüllen:

• Die SAN-Liste des Zertifikats enthält alle öffentlichen Hostnamen, die Clients tatsächlich verwenden, wie z mail.example.com. B. .
• Das ausgestellte Zertifikat stimmt mit dem für das kommerzielle Zertifikat gespeicherten privaten Schlüssel überein.
• Zimbra kann die vollständige Zertifikatskette vom Serverzertifikat über die Zwischenzertifizierungsstellenzertifikate bis hin zur Stammzertifizierungsstelle validieren.
• zmcertmgr deploycrt commwird ohne Schlüsselkonflikt oder Kettenvalidierungsfehler abgeschlossen.
• Die Zimbra-Dienste werden sauber neu gestartet.
• zmcertmgr viewdeployedcrtzeigt das erwartete Zertifikat an.
• Ein Browser oder TLS-Client, der eine Verbindung zum öffentlichen Hostnamen herstellt, sieht das neue Zertifikat und keine Vertrauenswarnung.

Schlägt eine dieser Prüfungen fehl, beheben Sie das Problem auf der betreffenden Ebene, bevor Sie fortfahren. Das wiederholte Bereitstellen derselben Dateien löst selten ein Problem mit Schlüsseln, SANs oder der Schlüsselkette.

Bevor Sie beginnen: Wählen Sie den passenden Zertifizierungsworkflow.

Auf der aktuellen Tech-Center-Seite von Zimbra wird darauf hingewiesen, dass Zimbra 8.7 und höher zmcertmgrals zimbraBenutzer ausgeführt wird. Außerdem wird dokumentiert, dass der kommerzielle private Schlüssel commercial.keyin der Datei benannt werden muss /opt/zimbra/ssl/zimbra/commercialund dass das Serverzertifikat sowie die CA-Kettendatei vor der Bereitstellung in einem temporären Verzeichnis abgelegt werden sollten.

Schritt 1: Sichern Sie das aktuelle Zertifikatsmaterial

Löschen Sie nicht zuerst das bestehende SSL-Verzeichnis. Erstellen Sie zunächst eine Sicherungskopie, die Sie im Falle eines Fehlers bei der neuen Bereitstellung wiederherstellen können. Als Root-Benutzer wäre ein konservatives Beispiel folgendes:

cp -a /opt/zimbra/ssl/zimbra /opt/zimbra/ssl/zimbra.backup-$(date +%Y%m%d-%H%M%S)

Notieren Sie sich außerdem das aktuell eingesetzte Zertifikat, bevor Sie es ändern:

su - zimbra
/opt/zimbra/bin/zmcertmgr viewdeployedcrt

Dies dient als Vergleichsgrundlage nach der Änderung. Falls Ihre Umgebung mehrere Zimbra-Knoten umfasst, erfassen Sie den aktuellen Zertifikatsstatus auf jedem relevanten Server, anstatt anzunehmen, dass diese identisch sind.

Schritt 2: Generieren Sie eine CSR mit den Hostnamen, die Sie tatsächlich benötigen

Für ein neues kommerzielles Zertifikat erstellen Sie die CSR mit dem Produktionshostnamen und allen zusätzlichen SANs. Zimbra dokumentiert die folgende Syntax:

/opt/zimbra/bin/zmcertmgr createcsr comm -new \
-subject "/C=US/ST=CA/L=Sunnyvale/O=Example/OU=IT/CN=mail.example.com" \
-subjectAltNames "mail.example.com"

Wenn sich Benutzer auch über einen anderen Namen verbinden, z. B. „example.com“ webmail.example.com, fügen Sie diesen bei der Zertifikatsanforderung der SAN-Liste hinzu. Moderne TLS-Clients validieren Hostnamen anhand von SANs. Daher kann ein Zertifikat, das allein anhand des allgemeinen Namens korrekt erscheint, dennoch eine Browserwarnung auslösen, wenn der Hostname fehlt.

Überprüfen Sie den CSR, bevor Sie ihn an Ihre Zertifizierungsstelle senden:

/opt/zimbra/bin/zmcertmgr viewcsr comm /opt/zimbra/ssl/zimbra/commercial/commercial.csr

Prüfpunkt: An dieser Stelle abbrechen, falls die angeforderten DNS-Namen falsch sind. Wenn das Zertifikat zuerst ausgestellt und später ein fehlender SAN entdeckt wird, muss es normalerweise von der Zertifizierungsstelle neu ausgestellt werden.

Schritt 3: Serverzertifikat und vollständige CA-Zertifikatskette sammeln

Nach der Validierung sendet Ihre kommerzielle Zertifizierungsstelle normalerweise das Serverzertifikat sowie ein oder mehrere Zwischenzertifikate zurück. Das offizielle Verfahren von Zimbra für kommerzielle Einzelknotenzertifikate erwartet das Serverzertifikat im PEM-Format und weist Administratoren an, Zwischen- und Stammzertifikate zu einer Zertifikatskette zusammenzufassen.

Ein typischer Bühnenaufbau sieht folgendermaßen aus:

/tmp/commercial.crt
/tmp/ca_intermediary.crt
/tmp/ca.crt

Bauen Sie die Kette anschließend in der von Zimbra dokumentierten Reihenfolge auf:

cat /tmp/ca_intermediary.crt /tmp/ca.crt > /tmp/ca_chain.crt

Verwenden Sie die von Ihrer Zertifizierungsstelle für Ihr spezifisches Zertifikatsprodukt bereitgestellten Dateien. Kopieren Sie kein Zwischenzertifikat aus einem fremden Tutorial, nur weil der Name der Zertifizierungsstelle ähnlich aussieht. Die Hierarchien von Zertifizierungsstellen ändern sich im Laufe der Zeit, und das falsche Zwischenzertifikat ist eine häufige Ursache für Probleme unable to get local issuer certificate.

Schritt 4: Überprüfen Sie vor der Bereitstellung den privaten Schlüssel, das Serverzertifikat und die Zertifikatskette.

Dies ist die wichtigste Sicherheitsvorkehrung. Führen Sie den dokumentierten Verifizierungsbefehl als Zimbra-Benutzer in aktuellen Zimbra-Versionen aus:

su - zimbra
/opt/zimbra/bin/zmcertmgr verifycrt comm \
/opt/zimbra/ssl/zimbra/commercial/commercial.key \
/tmp/commercial.crt \
/tmp/ca_chain.crt

Eine erfolgreiche Verifizierung bestätigt, dass Zertifikat und privater Schlüssel übereinstimmen und das Zertifikat gültig ist. Die Dokumentation der Zertifikatstools von Zimbra erklärt, dass verifycrtdabei eine Schlüsselprüfung und eine Prüfung der Zertifikatskette durchgeführt werden.

Schlägt die Überprüfung fehl, wählen Sie die Lösung anhand des Fehlers aus.

• Nicht übereinstimmendes Zertifikat und privater Schlüssel: Das CA-Zertifikat wurde nicht von der mit dem aktuellen Konto verknüpften CSR ausgestellt commercial.key. Stellen Sie den korrekten Schlüssel wieder her oder stellen Sie das Zertifikat von einer neuen CSR neu aus.
• Die Zertifikatskette konnte nicht validiert werden: Das Zwischen-/Root-Zertifikat ist unvollständig, in der falschen Reihenfolge, abgelaufen oder nicht die Kette für dieses Serverzertifikat. Fordern Sie die korrekte Kette von der ausstellenden Zertifizierungsstelle an.
• Das Zertifikat ist abgelaufen: Verwenden Sie es nicht. Fordern Sie ein aktuelles Zertifikat an und prüfen Sie, ob ein Zwischenzertifikat oder das Stammzertifikat in der Kette abgelaufen ist. Zimbra beschreibt diesen Fehlerfall in seiner Anleitung zur Fehlerbehebung bei abgelaufenen Stammzertifizierungsstellen .
• Hostname fehlt: Die Überprüfung entspricht möglicherweise nicht der Hostnamenprüfung, die ein Browser durchführt. Überprüfen Sie die ausgestellten SANs und stellen Sie sie neu aus, falls der öffentliche Name fehlt.

Schritt 5: Bereitstellung des kommerziellen Zertifikats

Die Bereitstellung sollte erst nach erfolgreicher Verifizierung erfolgen:

/opt/zimbra/bin/zmcertmgr deploycrt comm /tmp/commercial.crt /tmp/ca_chain.crt

Der dokumentierte Bereitstellungsprozess von Zimbra kopiert das kommerzielle Zertifikat in seinen SSL-Bereich, fügt die CA-Kette hinzu, aktualisiert die Zertifikatskonfiguration und installiert Zertifikatsmaterial für Dienste wie MTA, LDAP, Proxy und Mailbox-Komponenten, soweit dies für den Server erforderlich ist.

Überschreiben Sie keine zufälligen Java-Keystores oder Servicezertifikatsdateien manuell, es sei denn, die Dokumentation Ihrer Zimbra-Version erfordert dies ausdrücklich. Der Zweck besteht darin, die zmcertmgrKonsistenz der servicespezifischen Zertifikatsdateien zu gewährleisten.

Schritt 6: Zimbra-Dienste neu starten

Nach der Bereitstellung muss Zimbra neu gestartet werden:

su - zimbra
zmcontrol restart

Überprüfen Sie anschließend den Servicestatus:

zmcontrol status

Wenn ein Dienst nicht wieder erreichbar ist Running, sollten Sie die Ursache untersuchen, bevor Sie die Zertifikatsänderung als abgeschlossen erklären. Zertifikatsprobleme können LDAP, Proxy, Mailbox oder andere TLS-abhängige Kommunikation beeinträchtigen, insbesondere in Installationen mit mehreren Knoten.

Schritt 7: Überprüfen Sie das Ergebnis sowohl auf Zimbra- als auch auf Clientseite.

Verwenden Sie zunächst die Zertifikatsansicht von Zimbra:

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

Sie können auch überprüfen, ob ein bereitgestelltes Dienstzertifikat demnächst abläuft:

/opt/zimbra/bin/zmcertmgr checkcrtexpiration all -days 30

Testen Sie abschließend den exakten öffentlichen Hostnamen, den die Benutzer verwenden. Ein hilfreicher OpenSSL-Check von einem anderen Rechner aus ist:

openssl s_client -connect mail.example.com:443 -servername mail.example.com -showcerts

Suchen Sie nach dem erwarteten Endzertifikat, dem korrekten Hostnamen, einer vollständigen Zertifikatskette und einem erfolgreichen Verifizierungsergebnis. Öffnen Sie anschließend dieselbe HTTPS-URL in einem aktuellen Browser. Ein Browsertest ist wichtig, da er den tatsächlich erreichten Hostnamen prüft und nicht nur die Zertifikatsdateien auf der Festplatte.

Wenn das Standardverfahren nicht ausreicht

Ändern Sie Ihre Vorgehensweise, anstatt die Schritte für einen einzelnen Knoten zu erzwingen, wenn eine dieser Bedingungen zutrifft:

• Bei Zimbra-Installationen mit mehreren Knoten muss die Zertifikatsbereitstellung möglicherweise Proxy-, Mailbox-, LDAP- und MTA-Rollen auf verschiedenen Hosts abdecken. Das Zertifikatstool von Zimbra unterstützt Optionen für mehrere Server. Prüfen Sie jedoch die Vorgehensweise für Ihre Topologie, bevor Sie diese verwenden.
• Ein Reverse-Proxy oder ein externer Load Balancer beendet die TLS-Verbindung: Das öffentliche Zertifikat muss möglicherweise auch auf diesem Gerät installiert sein. Ein korrektes Zimbra-Zertifikat allein ändert nichts daran, was Clients sehen, wenn die TLS-Verbindung vorgelagert beendet wird.
• Sie importieren einen vorhandenen Schlüssel: Stellen Sie sicher, dass er sich an der Stelle befindet, an der Zimbra den kommerziellen privaten Schlüssel erwartet, und dass die Berechtigungen den Versionsanforderungen entsprechen, bevor Sie die Überprüfung durchführen.
• Ihre Zertifizierungsstelle stellt lediglich ein Zwischenzertifikatpaket bereit: Befolgen Sie die Anweisungen der Zertifizierungsstelle zur aktuellen Zertifikatskette, anstatt ein eigenes Stammzertifikat zu erstellen. Zimbra benötigt eine validierbare Zertifikatskette; die genauen Dateien hängen vom Aussteller ab.
• Das Zertifikat wurde mit demselben Hostnamen, aber einem anderen Schlüssel erneuert: Aktualisieren Sie den zugehörigen privaten Schlüssel vor der Überprüfung. Ein zuvor commercial.keyausgestelltes Zertifikat kann nicht für ein neues Schlüsselpaar validiert werden.

Abschließende Selbstprüfung

Die Installation ist erst dann abgeschlossen, wenn alle folgenden Bedingungen erfüllt sind: Die Installation wird erfolgreich verifycrtabgeschlossen deploycrt, die Zimbra-Dienste befinden sich wieder im Status „Wird ausgeführt“, viewdeployedcrtdas neue Zertifikat wird angezeigt und eine externe TLS-Verbindung zum realen Hostnamen empfängt dasselbe gültige Zertifikat ohne eine Vertrauens- oder Hostnamenwarnung.

Die Befehlssyntax und versionsspezifisches Verhalten entnehmen Sie bitte der offiziellen Dokumentation der Zimbra-Zertifikatstools . Die hier aufgeführten Beispiele dienen lediglich mail.example.comals Platzhalter; ersetzen Sie Namen, Zertifikatsdateien und Organisationsdetails durch die für Ihre Umgebung geltenden Werte.