Dieser Artikel wurde speziell für die Atlassian Server Plattform geschrieben. Aufgrund der eingeschränkten Funktionalitäten in Atlassian Cloud Applikationen können die Inhalte dieses Artikels nicht auf Atlassian Cloud Applikationen angewendet werden.

Die Ausgangslage

Beim Versuch auf Applikationen zuzugreifen, die mit SSL verschlüsselt sind (z. B. HTTPS, LDAPS, IMAPS), wird eine Exception ausgegeben und die Verbindung wird abgelehnt. Das kann passieren wenn Sie eine sichere Verbindung zu einem der folgenden Server/Applikationen herstellen wollen:

  • Active Directory Server
  • Mail Server
  • Eine andere Atlassian-Applikation, mithilfe von Applikations-Links

Beispielsweise wird folgender Fehler im UI ausgegeben, wenn Sie das Jira-Vorgangsmakro nutzen:

Error rendering macro: java.io.IOException: Could not download: https://siteURL/Jira/secure/IssueNavigator.jspa?view=rss&&type=12&type=4&type=3&pid=10081&resolution=1&fixfor=10348&sorter/field=issuekey&sorter/order=DESC&sorter/field=priority&sorter/order=DESC&tempMax=100&reset=true&decorator=none

 Währenddessen erscheint folgendes im Log:

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


Die Diagnose

Verwenden Sie SSLPoke um die Verbindung zu prüfen

Probieren Sie die Java-Klasse SSLPoke aus um zu sehen ob Ihr Truststore die richtigen Zertifikate enthält. Dadurch können Sie sich mit einem SSL-Service verbinden. Senden Sie einen Byte als Input und beobachten Sie den Output.

  1. Downloaden Sie SSLPoke.class
  2. Führen Sie die Klasse wie unten stehend aus und ändern Sie die URL und den Port entsprechend.
<JAVA_HOME>/bin/java SSLPoke Jira.example.com 443


(Info) Ein Mail Server könnte mail.example.com 465 sein.

  • Eine fehlgeschlagene Verbindung würde folgendes produzieren:

    /usr/bin/java SSLPoke Jira.example.com 443
    sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
     at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387)
     at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
     at sun.security.validator.Validator.validate(Validator.java:260)
     at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
     at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
     at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
     at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1351)
     at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:156)
     at sun.security.ssl.Handshaker.processLoop(Handshaker.java:925)
     at sun.security.ssl.Handshaker.process_record(Handshaker.java:860)
     at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1043)
     at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1343)
     at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:728)
     at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
     at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:138)
     at SSLPoke.main(SSLPoke.java:31)
    Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
     at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:145)
     at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:131)
     at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
     at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:382)
     ... 15 weitere
  • Eine erfolgreiche Verbindung sieht so aus:

    <JAVA_HOME>/bin/java SSLPoke Jira.example.com 443
    Successfully connected

Wenn -Djavax.net.ssl.trustStore in Ihren JVM Arguments erscheint, wird Java den Keystore nutzen, der in diesem Argument spezifiziert ist. Ob der -Djavax.net.ssl.trustStore Parameter Probleme verursacht können Sie überprüfen, indem Sie den SSLPoke-Test laufen lassen und das gleiche JVM Argument für diesen Keystore nutzen. Zum Beispiel:

<JAVA_HOME>/bin/java -Djavax.net.ssl.trustStore=/my/custom/truststore SSLPoke Jira.example.com 443

Wenn das fehlschlägt (bestätigt, dass der Truststore nicht die entsprechenden Zertifikate enthält), dann muss das Zertifikat in den Truststore, wie in der Anleitung für die Verbindung von SSL-Diensten beschrieben, importiert werden.


Die Ursache

Wann auch immer Java versucht eine Verbindung zu einer anderen Applikation via SSL herzustellen (z. B.: HTTPS, IMAPS, LDAPS), wird die Verbindung nur zustande kommen, wenn Java der Applikation vertrauen kann. In der Java-Welt funktioniert das über einen Keystore (typischerweise $JAVA_HOME/lib/security/cacerts), auch bekannt als Truststore. Dieser enthält eine Liste aller bekannten Zertifikate von den Zertifizierungsstellen (CA) und Java traut nur Zertifikaten, die von einem dieser CAs signiert sind oder öffentlich Zertifikate sind, die ebenfalls im Keystore sind. Wenn wir uns beispielsweise das Zertifikat für Atlassian ansehen, können wir sehen, dass das *.atlassian.com-Zertifikat von den Zwischenzertifiziertungsstellen DigiCert High Assurance EV Root CA und DigiCert High Assurance CA-3 signiert wurden. Diese Zwischenzertifizierungsstellen wurden vom Hauptverzeichnis Entrust.net Secure Server CA signiert.

Diese drei Zertifikate werden als Zertifizierungskette referenziert und weil sie alle im Java Keystore (cacerts) enthalten sind, traut Java jedem Zertifikat, das von diesen signiert wurde (in diesem Fall *.atlassian.com). Alternativ würde Java auch dieser Seite vertrauen, wenn das *.atlassian.com-Zertifikat im Keystore wäre.

Das Problem wird von einem Zertifikat ausgelöst, das selbst-signiert (nicht von einer Zertifizierungsstelle) ist oder von einem Zertifikat, das sich nicht im Java Truststore befindet. Java vertraut dem Zertifikat nicht und deshalb kann keine Verbindung zur Applikation hergestellt werden.


Die Lösung

 Fügen Sie SSL-Zertifikate automatisch hinzu!

Es gibt für diesen Prozess spezielle SSL für Jira und SSL für Confluence Add-Ons. Bitte installieren und nutzen Sie diese Add-Ons um Zertifikate einfacher zu importieren.

(Info) Die SSL für Jira und SSL für Confluence Add-Ons werden nicht von Atlassian supported.
(Info) Diese Add-Ons sind Teil des Atlassian Labs und können unter Umständen nicht mit den neuesten Jira- und Confluence-Versionen kompatibel sein.


  1. Stellen Sie sicher, dass Sie die öffentlichen Zertifikate der Zielinstanz, laut der Anleitung zur Verbindung von SSL-Diensten, in den Truststore importiert haben.
  2. Stellen Sie auch sicher, dass Sie alle Zertifikate in den korrekten Truststore importiert haben, wenn Sie mehrere JRE/JDKs haben. Lesen Sie hierzu: Java installieren.
  3. Überprüfen Sie ob der korrekte Truststore verwendet wird. Wenn -Djavax.net.ssl.trustStore konfiguriert wurde, überschreibt dieser den Ort des Standard-Truststores und das muss natürlich überprüft werden.
  4. Überprüfen Sie ob Ihr Anti-Viren-Tool "SSL Scanning" hat und SSL/TLS blockiert. Falls ja, dann deaktivieren Sie diese Funktion oder richten Sie eine Ausnahme für die Zieladressen ein (lesen Sie in der Produktdokumentation des Tools nach ob das möglich ist).
  5. Wenn Sie einen Mail Server wie Exchange anbinden, stellen Sie sicher, dass Klartexte erlaubt sind.
  6. Verifizieren Sie, dass der Zielserver so konfiguriert ist, dass SSL korrekt verwendet werden kann. Das kann mit dem SSL Server Tool gemacht werden.


Dieser Inhalt wurde zuletzt am 03.07.2020 aktualisiert.

Der Inhalt auf dieser Seite ist schon seit einer Weile nicht mehr aktualisiert worden. Das muss kein Nachteil sein. Oft überdauern unsere Seiten Jahre, ohne wirklich unnütz zu werden. Einfach auf diesen Link klicken, wenn wir die Seite mal wieder aktualisieren sollten. Alte Inhalte können falsch, irreführend oder überholt sein. Bitte nutzen Sie das Formular oder den Live-Chat auf dieser Seite oder kontaktieren Sie uns via E-Mail unter content@seibert.group, wenn Sie Zweifel, Fragen, Anregungen oder Änderungswünsche haben.