Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
pfx-Zertifikat in Tomcat für SSL-Verschlüsselung nutzen
wir haben ein kleines Servlet entwickelt was auf einem neu installierten Apache Tomcat/9.0.65 laufen soll. Das ganze ist bereits fertig und jetzt geht es nur um die SSL Verschlüsselung.
Ich habe von unserer Netzwerkabteilung ein pfx-Zertifikat erhalten. Dieses würde ich gerne einbinden. Dazu habe ich die Server.xml wie folgt erweitert / angepasst.
Die Verbindung mit einem Browser über SSL funktioniert. Nur leider wird ein self-signed certificate angezeigt und nicht das was in der Server.xml hinterlegt wurde.
Das führt natürlich dazu das der Website nicht vertraut wird.
Kann mir hier jemand helfen? Sind ggf. noch weitere Schritte notwendig?
Ich bezweifle das das ein pfx File ein valider Keystore ist. Du wirst es erstmal in ein sinnvolles Format konvertieren müssen, in den keystore importieren und dann den keystore korrekt einbinden. Dazu musst dem Zertifikat auch ein Alias geben, den im Keystore kann es mehrere Zertifikate geben.
Es ist ein gültiges Format und Tomcat sollte damit umgehen können. Aber ich habe bisher auch kein pfx File genutzt muss ich gestehen.
Was mich halt wundert: Wenn Tomcat noch das selbst signierte Zertifikat nutzt, dann liegt ganz offensichtlich ein Fehler in der Konfiguration vor. Der Eintrag für das alte Zertifikat hätte entweder ersetzt oder für das neue Zertifikat angepasst werden müssen.
Wenn es Probleme mit dem lesen des Zertifikats gegeben hätte, dann wäre das auch entsprechend im log zu finden. Das wäre halt in meinen Augen zu prüfen.
Aber das Einfachste ist halt, die Konfiguration anzuschauen: Wo liegt wie das bisherige self signed Zertifikat? Das dann einfach ersetzen und schon wäre man ohne viel Konfiguration fertig. Das wäre auch etwas der Weg, der z.B. unter
(Da findet sich auch die Information zu den unterstützten Formaten:
Tomcat currently operates only on JKS, PKCS11 or PKCS12 format keystores. The JKS format is Java's standard "Java KeyStore" format, and is the format created by the keytool command-line utility. This tool is included in the JDK. The PKCS12 format is an internet standard, and can be manipulated via (among other things) OpenSSL and Microsoft's Key-Manager.
Die Verbindung mit einem Browser über SSL funktioniert. Nur leider wird ein self-signed certificate angezeigt und nicht das was in der Server.xml hinterlegt wurde.
Danke für die Anmerkungen.
Ich muss gestehen ich bin primär im Bereich Datenbanken unterwegs und habe mit Webservern eher wenig am Hut. Java kenne ich noch aus dem Studium, weshalb ich für ein aktuelles Problem ein kleines Servlet schreiben konnte/musste --> Bedeutet: Ich muss die ein oder andere Rückfrage stellen - Sorry.
Interpretiere ich dein Kommentar und die Beschreibung richtig, das ich in jedem Fall ein Keystore erstellen MUSS und die pfx-Datei dort rein laden MUSS?
Aber das Einfachste ist halt, die Konfiguration anzuschauen: Wo liegt wie das bisherige self signed Zertifikat? Das dann einfach ersetzen und schon wäre man ohne viel Konfiguration fertig
Das interessante ist ich habe nie über das keytool ein self-signed Zertifikat erstellt. Demnach habe ich auch keine Idee wo das liegen kann. Aber ich versuche mal die logs zu finden und zu durchsuchen.
Ich bezweifle das das ein pfx File ein valider Keystore ist. Du wirst es erstmal in ein sinnvolles Format konvertieren müssen, in den keystore importieren und dann den keystore korrekt einbinden. Dazu musst dem Zertifikat auch ein Alias geben, den im Keystore kann es mehrere Zertifikate geben.
Ich hatte beim einlesen verschiedene Beispiele gesehen in der eine pfx Datei in der Server.xml Datei referenziert wurde. Leider waren die Beispiele nicht sehr ausführlich beschrieben.
Interpretiere ich dein Kommentar und die Beschreibung richtig, das ich in jedem Fall ein Keystore erstellen MUSS und die pfx-Datei dort rein laden MUSS?
Nein, as muss nicht zwingend sein. Aber es kann deutlich einfacher sein. Die Konfiguration des Tomcat ist relativ komplex und ich hatte da in der Vergangenheit auch schon meinen Spass mit. Ich erinnere mich da aber nicht mehr wirklich an die genauen Details.
Ich habe Dich so verstanden, dass der TomCat, den Du derzeit nutzt, bereits ein Selfsigned Zertifikat nutzt. Wenn dies der Fall ist, dann würde ich einfach nur schauen, was für ein Keystore benutzt wird (sollte ja in der server.xml zu finden sein) um dann diese Datei auszutauschen / das Zertifikat zu ersetzen.
Das interessante ist ich habe nie über das keytool ein self-signed Zertifikat erstellt. Demnach habe ich auch keine Idee wo das liegen kann. Aber ich versuche mal die logs zu finden und zu durchsuchen.
Hast Du denn den Tomcat einfach bei Apache herunter geladen oder ist das irgend ein "firmeninternes" Softwarepaket? Bei letzterem kann es so sein, dass da ein solches Zertifikat mit eingebaut wurde.
Der Tomcat Download selbst war zumindest in der Vergangenheit immer ohne https konfiguriert. Sprich: Es gab schlicht kein Zertifikat. Daher auf vielen Seiten der Hinweis, dass man da etwas auskommentieren und anpassen soll.
(Meine Erfahrungen hier sind aber etwas älter. Ich habe da vor 1-2 Jahren das letzte Mal ein Tomcat konfiguriert meine ich.)
Nein der Tomcat ist "frisch" von mir heruntergeladen und war quasi "originalverpackt"
Was ich dann gemacht hatte war mir das pfx-Zertifikat zu erstellen und dieses über den oben genannten xml Code in der Server xml einzubinden. Ich ging davon aus dass das reichen sollte. Tut es aber wohl nicht.
Das absolut merkwürdige ist, das er dieses Zertifikat schon erkennt. Denn wenn ich für Testzwecke das hinterlegte Kennwort für den PrivateKey ändere und den Tomcat starte - meckert er dass das KW falsch ist.
Bitte diese Antwort ganz lesen. Ich beschreibe erst, wie ich immer an sowas heran gehe. Aber das ist jetzt vielleicht gar nicht notwendig - es kann sein, dass der Tomcat prinzipiell richtig konfiguriert ist und nur bei dem Zertifikat etwas fehlt.
Also die generelle Vorgehensweise wäre aus meiner Sicht immer, dass ich mir die Beispiele in dem server.xml ansehe. Und bei dem 9.0.x findet sich da dann etwas wie:
XML:
<!-- Define an SSL/TLS HTTP/1.1 Connector on port 8443
This connector uses the NIO implementation. The default
SSLImplementation will depend on the presence of the APR/native
library and the useOpenSSL attribute of the AprLifecycleListener.
Either JSSE or OpenSSL style configuration may be used regardless of
the SSLImplementation selected. JSSE style configuration is used below.
-->
<!--
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="150" SSLEnabled="true">
<SSLHostConfig>
<Certificate certificateKeystoreFile="conf/localhost-rsa.jks"
type="RSA" />
</SSLHostConfig>
</Connector>
-->
<!-- Define an SSL/TLS HTTP/1.1 Connector on port 8443 with HTTP/2
This connector uses the APR/native implementation which always uses
OpenSSL for TLS.
Either JSSE or OpenSSL style configuration may be used. OpenSSL style
configuration is used below.
-->
<!--
<Connector port="8443" protocol="org.apache.coyote.http11.Http11AprProtocol"
maxThreads="150" SSLEnabled="true" >
<UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" />
<SSLHostConfig>
<Certificate certificateKeyFile="conf/localhost-rsa-key.pem"
certificateFile="conf/localhost-rsa-cert.pem"
certificateChainFile="conf/localhost-rsa-chain.pem"
type="RSA" />
</SSLHostConfig>
</Connector>
-->
Und da kann man schon gut erkennen, dass die Struktur zumindest eine andere ist. Das, was Du da gefunden hast als Beispiel, ist evtl. für eine ältere Version von Tomcat (Evtl. vom 8.5er?). Das ist aber eine reine Vermutung - ich stecke da auch nicht tief drin.
Wichtig ist halt, das man da jetzt zwei unterschiedliche Dinge sieht (aus meiner Sicht):
a) Es gibt zwei Protokolle, die man wählen kann - ich meine, dass Apr Protokoll hat bei mir Probleme gemacht auf meinem Windows Server. Aber ich erinnere mich nicht mehr.
b) Man kann die Zertifikate auf zwei Arten angeben: JSSE mäßig oder OpenSSL mäßig. Was mich etwas irritiert: Bei ersterem müsste es eigentlich noch mehr Attribute geben. Bei OpenSSL mäßig ist es dann so, wie man es bei Linux oft findet: Die Zertifikate liegen alle separat vor und sind nicht in einem Store untergebracht, d.h. du hast das KeyFile (Private Key), das Certificate (Public Key) und dann alle public Zertifikate zusammen, die die Chain ausmachen bis hin zum root Zertifikat. (Um es mal Laienhaft auszudrücken.)
Speziell bei Deinem Problem:
Was mich aber generell wundert: Wenn du falsche Einträge haben solltest, dann solltest Du das im Log auch direkt finden. Das ignoriert er ja nicht einfach sondern sollte das anmeckern. Und dann ist auch keine Verbindung mit dem Tomcat möglich.
Wenn Du da nichts bekommst, der Tomcat einwandfrei startet und Du Dich auf Port 8443 verbinden kannst, dann sieht es so aus, als ob der Tomcat deine Konfiguration genommen hat!
==> Evtl. schauen wir an der falschen Stelle, der Tomcat ist soweit konfiguriert und funktioniert.
Prüfe das Zertifikat - was wird genau angezeigt, wenn Du die Seite auf Port 8443 öffnest? Die Browser können Dir ja die Zertifikate anzeigen!
Wenn dem Zertifikat nicht vertraut wird, dann liegt das an anderen Gründen. Es sind zwei Dinge notwendig:
a) Es muss dem root Zertifikat vertraut werden
b) Es müssen die Zertifikate der Chain mitgegeben werden.
Dann wäre evtl. da etwas zu machen. Ggf. muss also ein oder zwei Intermediate Zertifikate hinzugefügt werden. Dann ist in der PFX nur das eigene Zertifikat (public und private) und eben nicht dieses. Das sollte man aber dann ablesen können!
Was mich aber generell wundert: Wenn du falsche Einträge haben solltest, dann solltest Du das im Log auch direkt finden. Das ignoriert er ja nicht einfach sondern sollte das anmeckern. Und dann ist auch keine Verbindung mit dem Tomcat möglich.
Wenn Du da nichts bekommst, der Tomcat einwandfrei startet und Du Dich auf Port 8443 verbinden kannst, dann sieht es so aus, als ob der Tomcat deine Konfiguration genommen hat!
zunächst nochmal vielen Dank für deine ausführliche Antwort und deine Mühen.
In den Logs finde ich keine Einträge die auf Probleme hinweisen. Ich habe im Ordner "logs" geprüft. Gibt es noch einen anderen Ort in den logs geschrieben werden?
Das Zertifikat sieht wie folgt aus (Der zensierte Teil enthält die Servernamen. Ausgestellt von und für sind identisch). Unser erstelltes Zertifikat hat außerdem eine Gültigkeit >1 Jahr. Das im Browser angezeigte Zertifikat ist 1Jahr gültig.
...kommt ein Fehler beim starten des Tomcats (sinngemäß: Blöcke können nicht entschlüsselt werden.) --> Ich vermute weil das Passwort für den privatekey nicht angegeben wurde. Das Attribut keystorepass bewirkt keine Änderung.
Ok, das sieht dann etwas danach aus, dass Tomcat Dein Zertifikat geladen hat und nur die Chain fehlt (die "intermediate certificates").
Die fehlenden Zertifikate wirst Du vermutlich dort bekommen können, wo Du auch das Zertifikat bekommen hast (Deine Netzwerk-Abteilung). Ggf. auch mal prüfen, was sie zur Verfügung gestellt haben - evtl hast Du das ja auch schon.
Da könnte Dir dann als Vorgehen evtl. diese Seite hier helfen:
Da gibt es aber viele Beschreibungen für viele Tools. In der Webseite oben hast Du einen openssl Aufruf, der das erzeugt. Ggf. kann dir das aber auch die Netzwerk-Abteilung direkt zur Verfügung stellen? Wenn die da eine eigene Zertifikat Infrastruktur betreiben, dann werden die das vermutlich auch mal "eben so" machen können.
Ok, das sieht dann etwas danach aus, dass Tomcat Dein Zertifikat geladen hat und nur die Chain fehlt (die "intermediate certificates").
Die fehlenden Zertifikate wirst Du vermutlich dort bekommen können, wo Du auch das Zertifikat bekommen hast (Deine Netzwerk-Abteilung). Ggf. auch mal prüfen, was sie zur Verfügung gestellt haben - evtl hast Du das ja auch schon.
Da könnte Dir dann als Vorgehen evtl. diese Seite hier helfen:
Da gibt es aber viele Beschreibungen für viele Tools. In der Webseite oben hast Du einen openssl Aufruf, der das erzeugt. Ggf. kann dir das aber auch die Netzwerk-Abteilung direkt zur Verfügung stellen? Wenn die da eine eigene Zertifikat Infrastruktur betreiben, dann werden die das vermutlich auch mal "eben so" machen können.
--> Das Funktioniert auch, jedoch erscheint die Warnung: "...verwendet den Signaturalgorithmus SHA1withRSA. Dies gilt als Sicherheitsrisiko. Dieser Algorithmus wird in einem zukünftigen Update deaktiviert."
Beim starten des Tomcats erhalte ich immernoch den Fehler das die Entschlüsselung fehlschlug. ABER: Ich bekomme jetzt überhaupt kein Zertifikat im Browser mehr angezeigt, was ich einfach mal als Fortschritt ansehe, da ich mir eh nicht erklären kann welches Zertifikat da geliefert wurde.
Für mich stellt sich jetzt die Frage: Wieso schlägt beim starten des Tomcats die Entschlüsselung fehl.
a) Kann es sein das Tomcat >9 Sha1 vllt. nicht mehr unterstützt?
b) Fehlt vllt. im xml-Code
