WSO2-Produkte können von der WSO2-Website heruntergeladen und in Sekundenschnelle installiert werden, danach können Sie die Software ausprobieren. Keine Gebühren, keine Verträge und… keine Anwälte.
Sobald Sie ein WSO2-Produkt starten, werden Sie feststellen, dass der Browser das Zertifikat, das zur Verschlüsselung der Verbindung verwendet wird, nicht akzeptiert. Es handelt sich um ein so genanntes selbstsigniertes Zertifikat, das als weniger sicher gilt als ein Zertifikat einer Zertifizierungsstelle.
Wie funktionieren die Zertifikate?
Ohne allzu sehr ins Detail zu gehen, funktionieren Zertifikate über einen Trust-Mechanismus. Zertifikate werden von sogenannten Zertifizierungsstellen wie den Unternehmen Comodo oder Symantec ausgestellt. Ein von ihnen ausgestelltes Zertifikat sollte vertrauenswürdig sein, da die Vertrauensbeziehung zu Zertifizierungsstellen unumstritten ist. Das Zertifikat garantiert, dass die Website tatsächlich die ist, die sie vorgibt zu sein.
Zertifikate in diesem Sinne werden verwendet, um den sicheren https-Verkehr zu und von Ihren WSO2-Produkten zu verschlüsseln. Um HTTPS einzurichten, benötigen Sie ein gültiges Zertifikat, damit das WSO2-Produkt die Verbindung verschlüsseln kann.
In diesem Tutorial habe ich ein Wildcard-Zertifikat verwendet, das von einer (vertrauenswürdigen) Zertifizierungsstelle signiert wurde. Das Zertifikat wird anstelle der selbstsignierten WSO2-Zertifikate im Keystore verwendet. Diese Zertifikate eignen sich hervorragend für Testzwecke, aber in einer Produktionsumgebung werden Sie diesen Keystore natürlich durch einen anderen ersetzen wollen. Außerdem werden Sie so die lästigen Meldungen über die mit selbstsignierten Zertifikaten verbundene Sicherheit los.
Bedenken Sie, dass Zertifikate Geld kosten, da eine Dienstleistung (in diesem Fall Vertrauen) angeboten wird. Einige Organisationen bieten kostenlose 90-Tage-Zertifikate an, wenn Sie es ausprobieren und nicht direkt Geld für ein vollwertiges Zertifikat ausgeben möchten. Beachten Sie, dass Sie einen Nachweis über das Eigentum oder die Kontrolle über die Website erbringen müssen, für die Sie das Zertifikat benötigen. Für weitere Informationen empfehlen wir Ihnen, sich im Internet zu informieren.
Wir gehen davon aus, dass Sie ein funktionierendes WSO2-Produkt haben, z.B. einen WSO2 ESB. Bevor wir beginnen, benötigen wir ein paar Dinge.
- Ein gültiges Zertifikat, normalerweise vom Systemadministrator Ihres Unternehmens erworben
- Der private Key des Zertifikats, den Sie normalerweise vom Systemadministrator Ihres Unternehmens erhalten
- Die Zwischen- und Root-Zertifikate, die von dem Vertrauensunternehmen bereitgestellt werden, das das gültige Zertifikat signiert hat. Sie können von der Website des Unternehmens heruntergeladen werden (in diesem Fall habe ich ein Zertifikat von Comodo verwendet https://support.comodo.com/index.php?/Default/Knowledgebase/List/Index/108/sha-2)
Um festzustellen, welche Sie benötigen, müssen Sie das gültige Zertifikat öffnen und das unten stehende Fenster öffnen.
Hier sehen Sie die gesamte Zertifikatskette. Sie sehen, dass das Platzhalterzertifikat des Clients das derzeit ausgewählte ist.
Über dem aktuellen Zertifikat sind zwei weitere Zertifikate aufgeführt, die als Zwischenzertifikate in der Zertifikatskette fungieren.
Wenn sie aktiviert sind, werden die Namen der Zwischenzertifikate angezeigt, die Sie benötigen:
- Comodo RSA Organization Validation Secure Server ca Zertifikat
- Comodo RSA Certification Authority-Zertifikat
- Im Falle des Root-Zertifikats ist dieses nicht aufgeführt und höchstwahrscheinlich bereits in das von Ihnen verwendete System eingebettet. Wenn Sie nicht sicher sind, sollte es nichts ausmachen, auch dieses hinzuzufügen.
- Externes ca-Root-Zertifikat als vertrauenswürdig hinzufügen
Hier sehen Sie das signierte Wildcard-Zertifikat (*.domain.nl) und die beiden Zwischenzertifikate in der Kette. Wenn Sie die Vermittler öffnen, finden Sie den genauen Namen des Zertifikats, das Sie finden müssen.
Wir benötigen also das COMODO RSA Zertifizierungsstellen-Zertifikat und den Comodo Rsa Organization Validation Secure Server ca.
Erstellen und Konfigurieren eines neuen Keystores
Die Erstellung eines neuen Keystore mit einem vertrauenswürdigen Key erfolgt in folgenden Schritten:
- Erstellen einer PKCS12/PFX-Datei
- Erstellen des Keystore
- Export eines öffentlichen Keys aus der JKS-Datei
- Hinzufügen des Keystore und des öffentlichen Keys zum Produkt
- Hinzufügen des öffentlichen Keys zum Public Truststore
- Konfigurieren des Produkts zur Verwendung des neuen Keystore
- Hinzufügen der Zwischenzertifikate zum Keystore.
- Fertig!
Wir werden diese Schritte im Folgenden genauer beschreiben.
Vor der Erstellung eines Keystore müssen wir eine .pfx-Datei mit den gesammelten Zertifikaten und Keys erstellen.
Schritt 1 – Erstellen einer PKCS12/PFX-Datei
Zunächst müssen Sie Zertifikate in das PKCS12/PFX-Format exportieren. Setzen Sie bei Bedarf sichere Passwörter ein. Für diesen Teil des Prozesses haben wir eine openssl-Eingabeaufforderung verwendet, die Sie in der Befehlszeile durch Eingabe von „openssl“ öffnen können.
Um eine richtige PFX-Datei zu erzeugen, müssen Sie den folgenden Befehl verwenden. Bei korrekter Ausführung wird zweimal nach einem Kennwort gefragt, vergessen Sie nicht, was Sie als Kennwort verwenden, da Sie es später benötigen!
openssl pkcs12 -export -in <customer valid certificate file>.crt -inkey <customer valid certficate file private key>.key -name "<alias for your pfx>" -certfile <additional certificate intermediary1> -certfile <additional certificate intermediary 2> -out <pfx keystore name>.pfx |
Das Ergebnis ist eine gültige pfx-Datei.
Schritt 2 – Erstellen des Keystore
Nun konvertieren wir die PKCS12/PFX-Datei mit dem folgenden Befehl in einen Java-Keystore:
keytool -importkeystore -srckeystore <pkcs12/pfx file name>.pfx -srcstoretype pkcs12 -destkeystore <Keystore file name>.jks -deststoretype JKS |
Für dieses Kommando benötigen Sie eine gültige JDK-Installation, keytool ist im Lieferumfang des JDK enthalten. Es befindet sich im Verzeichnis /bin des JDK.
Falls Ihre Kommandozeile keytool nicht findet, wenn Sie versuchen, es zu benutzen, ist Ihre PATH-Umgebungsvariable möglicherweise nicht gesetzt. Ändern Sie die Umgebungsvariable PATH auf Ihrem Computer und fügen Sie den Speicherort des Ordners jdk bin hinzu. Nachdem dies konfiguriert ist, sollten Sie in der Lage sein, keytool von jedem Verzeichnis auf dem Computer aus zu benutzen. Wenn der Befehl ausgeführt wird, haben Sie einen gültigen Keystore!
Schritt 3 – Exportieren Sie einen öffentlichen Key aus Ihrer JKS-Datei
Neben dem Keystore gibt es einen „Public Truststore“ innerhalb des WSO2-Produkts, zu dem wir den öffentlichen Key unseres Keystores hinzufügen müssen.
Da wir bisher noch keinen öffentlichen Key haben, müssen wir diesen aus dem Keystore exportieren.
keytool -export -alias "certificate alias" -keystore <mykeystore.jks> -file <public key name>.pem |
Überprüfen Sie, ob der Alias derselbe ist wie der, den Sie für Ihre pfx-Datei verwendet haben.
Schritt 4 – Hinzufügung des Keystore und des öffentlichen Keys zum Produkt
Bevor wir den Keystore und den öffentlichen Key für das WSO2-Produkt konfigurieren können, müssen wir die Dateien im Ordner <PRODUCT_HOME>/repository/resources/security ablegen.
Wenn die Dateien an ihrem Platz sind, können wir das Produkt so konfigurieren, dass es unsere neu erstellten Dateien verwendet.
Schritt 4.1 – Hinzufügen des öffentlichen Keys zum Public Truststore
Der öffentliche Truststore im Ordner <PRODUCT_HOME>/repository/resources/security/ heißt „client-truststore.jks“, wir fügen den öffentlichen Key mit dem folgenden Befehl zu diesem Truststore hinzu.
keytool -import -alias <certificate alias> -file <public key name>.pem -keystore client-truststore.jks -storepass wso2carbon |
Hinweis: Das Standardpasswort für client-truststore.jks lautet „wso2carbon“.
Schritt 4.2 – Konfigurieren des Produkts für den neuen Keystore
In jedem WSO2-Produkt gibt es viele verschiedene Dateien, die sich auf den Standard-Keystore beziehen. Wenn Sie diesen durch den neuen Keystore ersetzen möchten, müssen Sie den Eintrag an allen relevanten Stellen ändern.
Am wichtigsten ist die Konfiguration des primären Keystore-Eintrags in der Datei <PRODUCT_HOME>/repository/conf/carbon.xml. Sollten Sie diesen Eintrag nicht bearbeiten wollen, können Sie auch manuell einen zusätzlichen Keystore-Eintrag hinzufügen.
Der Eintrag wird wie folgt aussehen:
|
|
Ändern Sie ihn in etwa so:
<KeyStore> |
Das Passwort wird in plaintext gespeichert. Falls Sie einen sichereren Platzhalter mit einem verschlüsselten Wert speichern möchten, verwenden Sie SecureVault. Für mehr Informationen zu diesem Thema verweise ich Sie auf den Blog meines Kollegen: https://www.yenlo.com/blog/wso2torial-encrypt-passwords-using-secure-vault
Der einfachste Weg, alle anderen Einträge des Standard-Keystore zu finden, ist die Verwendung von „grep -nr „.jks“ im Ordner <PRODUCT_HOME>/repository/conf/, dies listet alle relevanten Einträge und ihre Dateien auf.
Sie erhalten dann ein Bild wie unten. Nun können Sie jede der gefundenen Dateien öffnen und die entsprechenden Keystore-Einträge ändern.
/axis2/axis2.xml:260: <Location>repository/resources/security/wso2carbon.jks</Location> |
Sobald Sie diese Einträge ersetzt haben, starten Sie den Server neu.
Schritt 5 – Hinzufügen der Zwischenzertifikate zum Keystore
Nachdem wir nun den Keystore korrekt konfiguriert haben, können wir ihn in der Carbon-Konsole nachschlagen.
Unter der Registerkarte „Main“ gibt es eine Schaltfläche mit dem Namen „Keystores“. Ursprünglich sahen Sie hier „wso2carbon.jks“, jetzt sollten Sie Ihren eigenen Keystore sehen.
Sollte dies nicht der Fall sein, stellen Sie sicher, dass Sie den Keystore-Eintrag in der carbon.xml korrekt konfiguriert haben.
Dieser sollte wie folgt aussehen und Ihren Keystore-Namen enthalten.
Sie müssen jetzt nur noch das Zwischenzertifikat und (optional) das Stammzertifikat zum Keystore hinzufügen.
Klicken Sie auf die Schaltfläche Zertifikat importieren und führen Sie diesen Vorgang für die Zwischenzertifikate durch.
Das Ergebnis sieht dann etwa so aus:
Schritt 6 – Fertig!
Der Server wird neu gestartet und die Carbon-Konsole aufgerufen. Im Browser wird neben der URL angezeigt, ob es sich um eine gültige HTTPS-Verbindung handelt.
Wird die Website in Ihrem Browser immer noch als unsicher angezeigt, können Sie zusätzliche Informationen über das Problem erhalten, indem Sie auf die Benachrichtigung in Ihrem Browser klicken.
Wenn Sie hier keine ausreichenden Informationen finden, können Sie auch eines der vielen SSL-Checker-Webtools wie https://www.ssllabs.com/ssltest/ ausprobieren.
Hinweis: Vergessen Sie nicht, dass, wenn Sie direkt zur IP-Adresse in Ihrem Browser gehen und nicht über eine DNS-Adresse, es auch sagen wird, dass das HTTPS nicht korrekt ist. In unserem Fall wurde das Zertifikat für *.domain.nl verwendet, so dass der Browser die Website nur als sicher einstuft, wenn Sie über eine Variante von *.domain.nl gehen.
Falls Sie Fragen zu diesem Blogpost haben, kontaktieren Sie uns über den Kommentarbereich dieses Blogs. Weitere technische Informationen finden Sie auch in unseren WSO2-Tutorials, Webinaren und Whitepapers. Benötigen Sie Unterstützung? Wir bieten WSO2-Produktsupport, WSO2-Entwicklungssupport, WSO2-Betriebssupport und WSO2-Trainingsprogramme.
Vielen Dank an Rob Blaauboer für seinen Beitrag zu diesem Blogpost.
