2013-05-14 15 views
6

Desidero creare un'applicazione Spring 3 (v 3.1.1.RELEASE) (su Java 1.6) per comunicare con un servizio Web HTTPS, che sta utilizzando un certificato autofirmato che ho creato. Sono confuso su come impostare i miei trusttores e keystones. Usando il mio certificato auto-firmato, ho generato una chiave di volta utilizzando i seguenti comandi ..."Ricevuto avviso fatale: handshake_failure" quando si tenta di connettersi al servizio Web https

openssl pkcs12 -export -in server.crt -inkey server.key \ 
      -out server.p12 -name myalias 

keytool -importkeystore -deststorepass password -destkeypass password -deststoretype jks -destkeystore server.keystore -srckeystore server.p12 -srcstoretype PKCS12 -srcstorepass password -alias myalias 

Poi ho configurato la mia domanda Primavera in questo modo ...

<http-conf:conduit name="*.http-conduit"> 
      <http-conf:tlsClientParameters secureSocketProtocol="SSL" disableCNCheck="true"> 
        <sec:trustManagers> 
         <sec:keyStore type="JKS" password="password" resource="server.keystore" /> 
        </sec:trustManagers> 
        <sec:keyManagers keyPassword="password"> 
         <sec:keyStore type="pkcs12" password="password" resource="server.p12" /> 
        </sec:keyManagers> 
      </http-conf:tlsClientParameters> 
    </http-conf:conduit> 

    <jaxws:client id="orgWebServiceClient" 
      serviceClass="org.mainco.bsorg.OrganizationWebService" address="${wsdl.url}" /> 

ma quando faccio funzionare la mia domanda, ottengo l'errore di seguito. Cosa mi sono perso?

Caused by: javax.net.ssl.SSLHandshakeException: SSLHandshakeException invoking https://nonprod.cbapis.org/qa2/bsorg/OrganizationService: Received fatal alert: handshake_failure 
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [classes.jar:1.6.0_45] 
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) [classes.jar:1.6.0 _45] 
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) [classes.jar:1.6.0_45] 
    at java.lang.reflect.Constructor.newInstance(Constructor.java:513) [classes.jar:1.6.0_45] 
    at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1458) [cxf-rt-transports-http-2.6.0.jar:2.6.0] 
    at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1443) [cxf-rt-transports-http-2.6.0.jar:2.6.0] 
    at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) [cxf-api-2.6.0.jar:2.6.0] 
    at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:659) [cxf-rt-transports-http-2.6.0.jar:2.6.0] 
    at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62) [cxf-api-2.6.0.jar:2.6.0] 
    at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262) [cxf-api-2.6.0.jar:2.6.0 ] 
    at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:532) [cxf-api-2.6.0.jar:2.6.0] 
    at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:464) [cxf-api-2.6.0.jar:2.6.0] 
    at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:367) [cxf-api-2.6.0.jar:2.6.0] 
    at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:320) [cxf-api-2.6.0.jar:2.6.0] 
    at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:89) [cxf-rt-frontend-simple-2.6.0.jar:2.6.0] 
    at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:134) [cxf-rt-frontend-jaxws-2.6.0.jar:2.6.0] 
... 5 more 
Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure 
    at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174) [jsse.jar:1.6] 
    at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:136) [jsse.jar:1.6] 
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1822) [jsse.jar:1.6] 
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1004) [jsse.jar:1.6] 
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1188) [jsse.jar:1.6] 
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1215) [jsse.jar:1.6] 
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1199) [jsse.jar:1.6] 
    at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:434) [jsse.jar:1.6] 
    at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166) [jsse.jar:1.6] 
    at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1014) [classes.jar:1.6.0_45] 
    at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:230) [jsse.jar:1.6] 
    at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleHeadersTrustCaching(HTTPConduit.java:1395) [cxf-rt-transports-http-2.6.0.jar:2.6.0] 
    at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.onFirstWrite(HTTPConduit.java:1337) [cxf-rt-transports-http-2.6.0.jar:2.6.0] 
    at org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutputStream.java:42) [cxf-api-2.6.0.jar:2.6.0] 
    at org.apache.cxf.io.AbstractThresholdOutputStream.write(AbstractThresholdOutputStream.java:69) [cxf-api-2.6.0.jar:2.6.0] 
    at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1415) [cxf-rt-transports-http-2.6.0.jar:2.6.0] 
... 15 more 
+0

Ciao Dave, abbiamo bisogno di ulteriori informazioni. Quindi il tuo servizio Web HTTPS è in esecuzione su quale server applicazioni, Tomcat? La tua applicazione Spring è in esecuzione sullo stesso server fisico o su un server separato? – Hiro2k

+4

Puoi aggiungere questo agli argomenti JVM: '-Djavax.net.debug = ssl, handshake, failure' e pubblicare i risultati del log? – Avi

+0

Inoltre, puoi guardare una mia domanda simile nella quale ho avuto lo stesso problema e ho postato tutto ciò che ho controllato dopo molte indagini mi hanno portato alla risposta: http://stackoverflow.com/questions/15544116/sslhandshakeexception -received-fatal-alert-handshake-failure-when-setting-ciph – Avi

risposta

0

Ecco la sequenza delle cose che è necessario verificare la presenza di:

  1. Verificare la sua entrata nel keystore utilizzando keytool -list. Fare riferimento this articolo per sintassi
  2. Verificare se ci sono un insieme comune di pacchetti di crittografia supportati tra il client e il server
  3. Infine, puntare il file da .jks sia keyManagers e trustManagers come indicato nel cxf documentation
0

È dovrebbe avere il certificato SSL corretto nel keystore, del server a cui si sta tentando di connettersi.

È possibile creare il keystore utilizzando il metodo dato here.

Controllare questi esempi. Questi stanno funzionando per me.

example 1example 2

+0

Il certificato deve essere nel keystore, i certificati dei server che si sta tentando di connettersi devono essere nel trust store o java cert store. – Raymond

3

Se non si sta facendo un doppio senso l'autenticazione SSL significato, il server non si preoccupa che il cliente è in modo che non ha bisogno di controllare e verificare il certificato client; allora in quel caso tutto ciò di cui hai bisogno sul lato client è solo un archivio fidato che contiene un elenco di certificati server affidabili. Nel tuo caso, il truststore del tuo client conterrà solo il certificato del server autofirmato e questo è tutto. È prassi comune in java avere il tuo truststore nel formato .jks. Se riesci a generare un truststore, allora sei pronto. Sul lato server non è necessario preoccuparsi del truststore, ma è necessario configurare il server per disporre di un certificato server valido.

In un'autenticazione SSL bidirezionale, è necessario il keystore e il truststore sia configurati sul lato client che sul lato server. Il truststore del client rimarrebbe identico a quello dell'autenticazione a 1 via. Il truststore del server deve contenere il certificato del client autofirmato. Sia il client che il server devono essere configurati per utilizzare i rispettivi certificati che presentano a ciascuno durante l'handshake SSL. Durante la stretta di mano, entrambe le parti verificano reciprocamente il certificato contro il loro truststore e stabiliscono l'identità dell'altra parte. E una volta stabilite le identità, dovresti essere in grado di stabilire la connessione.

Per la generazione di negozi suggerisco di utilizzare uno strumento chiamato Portecle che può essere molto utile.

+0

"allora in quel caso tutto ciò di cui hai bisogno sul lato client è solo un archivio fidato che contiene un elenco di certificati server attendibili" Che cosa succede se stai colpendo i server https in base all'input dell'utente in modo dinamico. Quindi non conosci i server prima del tempo. Cosa faresti in questo caso? – Rose

Problemi correlati