Ich habe Jenkins zum ersten Mal verwendet, um eine CD / CD-Umgebung zu erstellen.
Ich habe Jenkins mit Docker eingerichtet, das Git-Repository registriert, es erstellt und bin zur Bereitstellungsphase übergegangen. Verwenden Sie das Tomcat7-Maven-Plugin von maven als Bereitstellungsmethode Es gab jedoch einen unerwarteten Fehler.
com.sun.jersey.api.client.ClientHandlerException: javax.net.ssl.SSLHandshakeException:sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Ich habe einen Fehler erhalten und habe Google Teacher wie gewohnt gefragt.
Grob gesagt stellte ich fest, dass eine Fehlermeldung angezeigt wurde, da das SSL-Zertifikat der Site, mit der ich kommunizieren wollte, nicht vertrauenswürdig war. Es scheint, dass es herauskommt, wenn das Oleore-Zertifikat oder das Zertifikat abgelaufen ist.
Der Server, den ich bereitstellen wollte, war jedoch kein Oleore-Zertifikat und noch nicht abgelaufen. Selbst wenn ich mit einem Browser darauf zugegriffen habe, konnte ich über https fest kommunizieren. Dieses "Zugriff mit einem Browser" komplizierte das Problem jedoch später.
Ich habe viel gesucht, aber keine nützlichen Informationen gefunden. Keine der Sites verfügt über Zertifikatsvertrauensstellungen. Fügen Sie sie daher einfach mit keytool zur Vertrauensvertrauensliste hinzu. .. .. .. Das brauche ich aber nicht, weil es nicht mein Zertifikat ist! Ich dachte über verschiedene andere Faktoren nach.
Mein SSL-Zertifikat wurde von Let's Encrypt ausgestellt. Ist Java nicht vertrauenswürdig? Verschlüsseln wir uns selbst? Dachte ich und suchte.
Es gab eine Person, die [hier] nachforschte (https://munyagu.com/586/). Ich verstehe, haben Sie immer noch darauf vertraut, dass wir uns selbst verschlüsseln?
Beim Lesen dieses Artikels jedoch die folgende Beschreibung
Let 's Encrypt-Zertifikate werden anscheinend von Java 8 Update 101 unterstützt. Dort war.
Gibt es einen Fehler, weil die von Jenkins verwendete Java-Version kleiner als Java 8 Update 101 ist! Wenn Sie die Version von Java erwähnen, wird es gelöst!
Ich dachte. .. .. .. ..
Wie ich oben geschrieben habe, dachte ich, dass es an der Java-Version liegt, also habe ich die von Jenkins verwendete Version überprüft. Ich fand heraus, dass die Java-Version in den Systeminformationen von Jenkins geschrieben ist, also ging ich.
java.version 1.8.0_171
・ ・ ・ ・ ・ ・ ・ ・ ・
Ich bin mir sicher, dass sich die Java-Version von Jenkins von der Java-Version unterscheidet, wenn sie tatsächlich ausgeführt wird. Deshalb habe ich im Job die Java-Version ausgeführt.
java -version openjdk version "1.8.0_171" OpenJDK Runtime Environment (build 1.8.0_171-8u171-b11-1~deb9u1-b11) OpenJDK 64-Bit Server VM (build 25.171-b11, mixed mode)
・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・
Warum? War es nicht wegen der Java-Version? Ich weiß es nicht mehr
Ich habe mich entschlossen, hier zum ersten Mal lokal bereitzustellen. Ich habe den Befehl ausprobiert, der von Jenkins vom lokalen ausgeführt wurde.
com.sun.jersey.api.client.ClientHandlerException: javax.net.ssl.SSLHandshakeException:sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Ernsthaft.
Anfragen, die normalerweise an http gehen, werden an https umgeleitet
Ich weiß nicht, was die Ursache ist, deshalb habe ich versucht, es bereitzustellen, indem ich es über http anstelle von https zugänglich gemacht habe, um das Problem einzugrenzen.
Sie können es ordnungsgemäß bereitstellen.
Die Bereitstellung mit dem tomcat7-maven-Plugin von maven funktioniert nicht. Das SSL-Zertifikat scheint ein Problem zu sein, aber es gibt kein Problem, selbst wenn Sie über einen Browser auf die Site zugreifen. Lassen Sie uns Encript gibt einen Fehler abhängig von der Version von Java, aber es ist nicht die aktuell verwendete Version. Jenkins selbst ist kein Problem, da lokal ähnliche Fehler auftreten. Da Sie dies mit http tun können, ist der Befehl korrekt und es ist unwahrscheinlich, dass auf der Clientseite ein Problem vorliegt
Um ehrlich zu sein, habe ich keine Ahnung, wo das Problem liegt. Ich begann zu denken, dass es schneller sein würde, das Zertifikat mit Keytool hier zu registrieren.
Wie Sie später sehen werden, wird der Fehler durch die Registrierung bei keytool nicht behoben. Infolgedessen war es die richtige Antwort.
Es gibt eine [Site](https://community.letsencrypt.org/t/certificate-error-sun-security-validator-validatorexception-pkix-path-building-failed-sun- Ich habe diesen Kommentar in Security-Provider-Certpath-Suncertpathbuilder-Ausnahme-Unmöglichkeit-Finden-Gültiger-Zertifizierungs-Pfad-zum-Angeforderten-Ziel / 28283 gefunden.
Dein Problem hat nichts mit Java zu tun! Ihre Site gibt eine unvollständige Kette von Zertifikaten zurück! Wir müssen es also ändern, um die vollständige Zertifikatskette (fullchain.pem) zurückzugeben!
Was. .. ..
Sicher hatte ich cert1.pem geladen. Laden Sie fullchain.pem, wie es auf der Site geschrieben wurde. .. ..
Der Fehler verschwand sofort und ich konnte ohne Probleme bereitstellen! !! !! !!
Ich habe gerade die SSL-Zertifikatdatei geändert, um sie von cert1.pem in fullchain.pem zu lesen. Es gibt kein Problem mit dem Zugriff über den Browser. Wenn beim Zugriff über Java eine Fehlermeldung angezeigt wird, überprüfen Sie diese bitte.
Die Datei, die das SSL-Zertifikat gelesen hat, wurde auf einer Site geschrieben, und ich dachte, es wäre in Ordnung, da sie problemlos mit dem SSL-Zertifikat funktioniert. Aufgrund dieser Überzeugung habe ich die Überprüfung, ob SSL in Ordnung ist, verschoben.
Ich denke immer noch, wenn Sie fullchain1.pem haben, brauchen Sie cert1.pem nicht, oder? Es wäre nicht passiert, wenn es nur fullchain1.pem gäbe. .. .. Wenn jemand weiß, warum Sie cert1.pem benötigen, lassen Sie es mich bitte wissen
Recommended Posts