2016-03-29 12 views
0

Ich versuche, eine einfache esb-Konfiguration zu konfigurieren, die einen HTTP-Endpunkt verfügbar macht, aber intern einen https-Dienst aufruft.Verbrauchen HTTPS mit Mule

unten ist meine Konfiguration:

<?xml version="1.0" encoding="UTF-8"?> 

<mule xmlns:ws="http://www.mulesoft.org/schema/mule/ws" xmlns:tls="http://www.mulesoft.org/schema/mule/tls" xmlns:http="http://www.mulesoft.org/schema/mule/http" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" 
    xmlns:spring="http://www.springframework.org/schema/beans" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd 
http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd 
http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd 
http://www.mulesoft.org/schema/mule/tls http://www.mulesoft.org/schema/mule/tls/current/mule-tls.xsd 
http://www.mulesoft.org/schema/mule/ws http://www.mulesoft.org/schema/mule/ws/current/mule-ws.xsd"> 


<http:listener-config name="HTTP_Listener_Configuration" host="0.0.0.0" port="8096" doc:name="HTTP Listener Configuration"/> 

<http:request-config name="HTTP_Request_Configuration" protocol="HTTPS" doc:name="HTTP Request Configuration"> 

->

</http:request-config> 

<flow name="secureddemoFlow"> 
    <http:listener config-ref="HTTP_Listener_Configuration" path="/" doc:name="HTTP"/> 
    <logger message="Inside---" level="INFO" doc:name="Logger"/> 
    <http:request config-ref="HTTP_Request_Configuration" path="/secureservice/esb" host="10.208.18.246" port="8443" method="GET" doc:name="HTTP"/> 

    <logger message="done---" level="INFO" doc:name="Logger"/> 
</flow> 
</mule> 

Diese erfolgreich im Einsatz, aber wenn der Endpunkt ich die unten Exception zugegriffen wird:

INFO 2016-03-30 12:08:01,443 [[secureddemo].HTTP_Listener_Configuration.worker.01] org.mule.api.processor.LoggerMessageProcessor: Inside--- 
ERROR 2016-03-30 12:08:01,531 [[secureddemo].HTTP_Listener_Configuration.worker.01] org.mule.exception.DefaultMessagingExceptionStrategy: 
******************************************************************************** 
Message    : Error sending HTTP request. Message payload is of type: NullPayload 
Type     : org.mule.api.MessagingException 
Code     : MULE_ERROR--2 
Payload    : {NullPayload} 
JavaDoc    : http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/api/MessagingException.html 
******************************************************************************** 
Exception stack is: 
1. No subject alternative names present (java.security.cert.CertificateException) 
    sun.security.util.HostnameChecker:142 (null) 
2. General SSLEngine problem (javax.net.ssl.SSLHandshakeException) 
    sun.security.ssl.Alerts:192 (http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/net/ssl/SSLHandshakeException.html) 
3. General SSLEngine problem (javax.net.ssl.SSLHandshakeException) 
    sun.security.ssl.Handshaker:1362 (http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/net/ssl/SSLHandshakeException.html) 
4. javax.net.ssl.SSLHandshakeException: General SSLEngine problem (java.util.concurrent.ExecutionException) 
    org.glassfish.grizzly.impl.SafeFutureImpl$Sync:349 (null) 
5. java.util.concurrent.ExecutionException: javax.net.ssl.SSLHandshakeException: General SSLEngine problem (java.io.IOException) 
    org.mule.module.http.internal.request.grizzly.GrizzlyHttpClient:245 (null) 
6. Error sending HTTP request. Message payload is of type: NullPayload (org.mule.api.MessagingException) 
    org.mule.module.http.internal.request.DefaultHttpRequester:287 (http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/api/MessagingException.html) 
******************************************************************************** 
Root Exception stack trace: 
java.security.cert.CertificateException: No subject alternative names present 
    at sun.security.util.HostnameChecker.matchIP(HostnameChecker.java:142) 
    at sun.security.util.HostnameChecker.match(HostnameChecker.java:91) 
    at sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:347) 
    at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:255) 
    at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:138) 
    at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1328) 
    at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:153) 
    at sun.security.ssl.Handshaker.processLoop(Handshaker.java:868) 
    at sun.security.ssl.Handshaker$1.run(Handshaker.java:808) 
    at sun.security.ssl.Handshaker$1.run(Handshaker.java:806) 
    at java.security.AccessController.doPrivileged(Native Method) 
    at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1299) 
    at org.glassfish.grizzly.ssl.SSLUtils.executeDelegatedTask(SSLUtils.java:247) 
    at org.glassfish.grizzly.ssl.SSLBaseFilter.doHandshakeStep(SSLBaseFilter.java:669) 
    at org.glassfish.grizzly.ssl.SSLFilter.doHandshakeStep(SSLFilter.java:330) 
    at org.glassfish.grizzly.ssl.SSLBaseFilter.doHandshakeStep(SSLBaseFilter.java:583) 
    at org.glassfish.grizzly.ssl.SSLBaseFilter.handleRead(SSLBaseFilter.java:304) 
    at com.ning.http.client.providers.grizzly.SwitchingSSLFilter.handleRead(SwitchingSSLFilter.java:74) 
    at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119) 
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283) 
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200) 
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132) 
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111) 
    at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77) 
    at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536) 
    at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112) 
    at org.mule.module.http.internal.request.grizzly.FlowWorkManagerIOStrategy.run0(FlowWorkManagerIOStrategy.java:134) 
    at org.mule.module.http.internal.request.grizzly.FlowWorkManagerIOStrategy.access$100(FlowWorkManagerIOStrategy.java:31) 
    at org.mule.module.http.internal.request.grizzly.FlowWorkManagerIOStrategy$WorkerThreadRunnable.run(FlowWorkManagerIOStrategy.java:157) 
    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:591) 
    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571) 
    at java.lang.Thread.run(Thread.java:722) 

******************************************************************************** 

Bitte assistieren.

Antwort

1

Dieses Problem tritt auf, wenn Sie versuchen, auf einen Dienst mit einem Hostnamen zuzugreifen, der nicht im Serverzertifikat als SubjectAlternativeName (SAN) angegeben ist. Da Sie eine Anfrage an 116.202.169.182 senden, wenn dieser Server sein Zertifikat an den Client zurückgibt, damit es validiert werden kann, ist eine der durchgeführten Überprüfungen die 'Hostname-Verifizierung' (im Grunde: ist das wirklich, mit wem ich kommunizieren möchte?) finden Sie 116.202.169.182 aufgelistet.

Das Problem ist nicht in dem Trust Store oder Schlüsselspeicher Sie konfigurieren (in der Tat, Sie definieren es einfach, aber nicht tatsächlich es in Ihrem request-config Referenzierung, so dass ich denke nicht, dass es wird verwendet), aber mit dem Server Sie sind Senden einer Anfrage an. Sie könnten die Anfrage über den Hostnamen senden, den sie in ihrem Zertifikat definiert.

HTH

+0

Ich habe den Code nach Ihrem Vorschlag aktualisiert und bin jetzt eine Handshake Ausnahme bekommen, könnten Sie bitte –

+0

helfen können Sie den Code Update teilen? Wenn Sie jetzt die IP nicht direkt verwenden, könnte der Handshake-Fehler darauf zurückzuführen sein, dass das, was ich über den '' 'tls-context''' erwähnt habe, nicht referenziert wird. Ich müsste mir den Code und die Ausnahme ansehen, um sicher zu gehen. – afelisatti

+0

Ich habe den Code aktualisiert, mit dem, den ich jetzt benutze (einschließlich Ihrer Kommentare) –