Ich schreibe Integrationstests für eine Mule ESB-Anwendung. Die Mule-Anwendung stellt über HTTPS eine Verbindung zu einer Drittanbieter-API her. Wenn ich versuche, meine Anwendung auf dem Test-API-Endpunkt eines Drittanbieters auszuführen, funktioniert alles einwandfrei und ich muss kein @ hinzufügeKlien spezifische SSL-Konfiguration für den HTTPS-Connector. Ich glaube, dies liegt an der Tatsache, dass der Server von der Zertifizierungsstelle signierte Zertifikate hat, weshalb man ihnen sofort vertraut und z. ein HTTP-Connector wie dieser

<https:connector
        name="my.https.connector"
        cookieSpec="netscape"
        validateConnections="true"
        sendBufferSize="0"
        receiveBufferSize="0"
        receiveBacklog="0"
        clientSoTimeout="10000"
        serverSoTimeout="10000"
        socketSoLinger="0"
        doc:name="HTTPS">
    <service-overrides sessionHandler="org.mule.session.NullSessionHandler"/>
</https:connector>

wird sofort funktionieren.

Wenn ich den Integrationstest schreibe, stoppe ich die API des Drittanbieters (oder verspotte sie, wenn Sie dies bevorzugen). Damit SSL funktioniert, muss ich jedoch einen Keystore für den eingebetteten HTTPS-Server generieren und den Client-HTTPS-Connector durch Hinzufügen von @ änder

    <https:tls-client path="keystore" storePassword="psw" />
    <https:tls-key-store path="keystore" storePassword="psw" keyPassword="psw" />

wie überall im Internet erwähnt.

Ich könnte den testenden HTTPS-Konnektor in einer separaten XML-Datei definieren und in das @ ladeFunctionalTestCase.getConfigResources() Methode. Dies ist jedoch nicht ideal: Ich bin wirklich auf der Suche nach einer Möglichkeit, den HTTPS-Konnektor (den Client) dazu zu bringen, @ zu vertrauealle - aber nur beim Ausführen des Integrationstests - d. h. beim Ausführen eines Maven bauen. Dies muss programmgesteuert geschehen, damit der Mule-Anwendungscode nicht verändert wird.

Ich habe versucht, den folgenden Code in ein @ einzufüg@BeforeClass kommentierte Methode

http: //www.rgagnon.com/javadetails/java-fix-certificate-problem-in-HTTPS.htm

aber hatte kein Glück. Beim Ausführen der Integrationstests erhalte ich weiterhin die folgende Ausnahm

Exception stack is:
1. unable to find valid certification path to requested target (sun.security.provider.certpath.SunCertPathBuilderException)
  sun.security.provider.certpath.SunCertPathBuilder:196 (null)
2. PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target (sun.security.validator.ValidatorException)
  sun.security.validator.PKIXValidator:385 (null)
3. sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target (javax.net.ssl.SSLHandshakeException)
  sun.security.ssl.Alerts:192 (http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/net/ssl/SSLHandshakeException.html)

Jemand mit einer funktionierenden Lösung? :)