Buongiorno,
da qualche giorno sto cercando di effettuare i test di interoperabilità verso il canale SDICoop, abbiamo già generato la CSR e ricevuto i file che abbiamo combinato tra loro ricavando un certificato .p12.
Installando questo certificato e tentando di collegarmi al sito https://testservizi.fatturapa.it/ riesco ad accedere senza problemi.
Il problema sorge nel momento in cui tento di effettuare la chiamata tramite il nostro web service.
Io ho inserito il certificato nel nostro cacerts utilizzato dal jks, ma non ho un risposta positiva nel momento in cui chiamo il loro web service https://testservizi.fatturapa.it/ricevi_file?wsdl
Si seguito gli errori presi dal log:
Caused by: org.apache.cxf.service.factory.ServiceConstructionException: Failed to create service.
at org.apache.cxf.wsdl11.WSDLServiceFactory.(WSDLServiceFactory.java:87)
at org.apache.cxf.jaxws.ServiceImpl.initializePorts(ServiceImpl.java:218)
at org.apache.cxf.jaxws.ServiceImpl.initialize(ServiceImpl.java:161)
… 51 more
Caused by: javax.wsdl.WSDLException: WSDLException: faultCode=PARSER_ERROR: Problem parsing ‘https://testservizi.fatturapa.it/ricevi_file?wsdl’.: 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
at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(WSDLReaderImpl.java:2198)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2390)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2422)
at org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:266)
at org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:165)
at org.apache.cxf.wsdl11.WSDLServiceFactory.(WSDLServiceFactory.java:85)
… 53 more
Caused by: 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
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1964)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:328)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:322)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1614)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:987)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1072)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1564)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:263)
at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:991)
at org.apache.xerces.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:144)
at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:832)
at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:798)
at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:108)
at org.apache.xerces.parsers.DOMParser.parse(DOMParser.java:230)
at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:298)
at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(WSDLReaderImpl.java:2188)
… 58 more
Caused by: 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:397)
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
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:1596)
… 78 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
il servizio di test del sistema di interscambio https://testservizi.fatturapa.it utilizza un certificato firmato dall’Agenzia delle Entrate per certificare l’identità del server, e richiede il certificato firmato dall’Agenzia delle Entrate che ti è stato fornito per l’autenticazione del client.
Il servizio di produzione https://servizi.fatturapa.it, invece, utilizza un certificato firmato da una autorità pubblica riconosciuta (attualmente GlobalSign) per certificare l’identità del server, sempre richiedendo il certificato firmato dall’Agenzia delle Entrate che ti è stato fornito per l’autenticazione del client.
Per fare i test dovrai quindi impostare il certificato CA_Entrate nel TrustManager, oltre che inserire il certificato client nel KeyManager.
Ciao Stefano,
grazie molte per la risposta!
Immaginavo fosse qualcosa del genere.
Il problema è che non so dove sia il TrustManager, nè a come farne riferimento.
Per la java ho solo il file cacerts nel folder security, e qui è dove ho inserito il certificato client.
Mentre per Wildfly 12 non so bene dove muovermi, ho provato a cercare in rete ma non ho trovato molte info.
Parlando con l’assistenza di Sogei non mi hanno mai parlato di questo TrustManager, ma gli errori sui vari check mi avevano fatto insospettire.
CaRoot dell’agenzia delle entrate
Ho ottenuto un file p.12 come suggerito da Sogei.
Ho inserito il contenuto del file p.12 nel cacerts usato dalla mia java alla base di wildfly 12.
Avviando l’applicazione per l’invio di un documento l’errore al momento è questo:
Caused by: org.apache.cxf.service.factory.ServiceConstructionException: Failed to create service.
at org.apache.cxf.wsdl11.WSDLServiceFactory.(WSDLServiceFactory.java:87)
at org.apache.cxf.jaxws.ServiceImpl.initializePorts(ServiceImpl.java:218)
at org.apache.cxf.jaxws.ServiceImpl.initialize(ServiceImpl.java:161)
… 51 more
Caused by: javax.wsdl.WSDLException: WSDLException: faultCode=PARSER_ERROR: Problem parsing ‘https://testservizi.fatturapa.it/ricevi_file?wsdl’.: java.io.IOException: Server returned HTTP response code: 403 for URL: https://testservizi.fatturapa.it/ricevi_file?wsdl
at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(WSDLReaderImpl.java:2198)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2390)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2422)
at org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:266)
at org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:165)
at org.apache.cxf.wsdl11.WSDLServiceFactory.(WSDLServiceFactory.java:85)
… 53 more
Caused by: java.io.IOException: Server returned HTTP response code: 403 for URL: https://testservizi.fatturapa.it/ricevi_file?wsdl
Questo è molto strano perchè inserendo il file p.12 nel mio browser e chiamando lo stesso wsdl mi torna una risposta positiva.
Ciao Oiram,
per creare il file p.12 ho usato il tuo stesso comando.
Tramite browser avevo il tuo stesso problema, ho chiamato il numero verde di Sogei e mi hanno detto di riprovare a breve, senza cambiare o fare nulla è andato.
Ora riesco a chiamare il wsdl da browser ma tramite Wildfly ho nuovamente l’errore 403.
Grazie per l’informazione, proverò anche io a chiamare il numero verde e vedere se, magicamente, dal browser tutto funziona.
Pensando a questa differenza di comportamento tra quello che avviene sul browser e nel servizio web mi viene un dubbio: non ci sarà mica un controllo sull’indirizzo del chiamante nei servizi web esposti dal SdI?
Lo dico perché, almeno nella mia configurazione, il server web su cui sto sviluppando i web services non si trova nella mia rete (si trova presso una web farm) mentre io cerco di fare i test tramite il browser che ovviamente espone un IP pubblico differente.
Perdonate se ho detto una baggianata, ma ho questa sensazione che spero qualcuno possa smentire.
Abbiamo il vostro stesso problema: installando il certificato sul browser riusciamo a collegarci, ma dal nostro applicativo no.Possiamo chiedervi come avete risolto?
Buongiorno,
personalmente abbiamo chiamato il numero verde 800 299 940 e abbiamo spiegato all’operatore che abbiamo fatto tutti i passaggi ma tramite browser vedevamo solo la pagina che ci mostrava il messaggio “Sogei S.p.A.
Webserver is running” ma quando tentavamo di chiamare il wsdl ci dava “utente non autorizzato”. l’operatore ci ha chiesto di riprovare dopo un po’, ed effettivamente senza cambiare nulla lato nostro abbiamo visto, sempre tramite browser, lo schema del webservice di test.
A questo punto immagino che l’operatore ci abbia semplicemente abilitato, cosa molto strana visto che avremmo già dovuti esserlo.
Grazie della risposta,
anche noi abbiamo chiamato il numero verde e dopo il loro intervento siamo riusciti a visualizzare il wsdl da browser, ma purtroppo continuiamo a ricevere errore 403 dal nostro applicativo Java.
Per ovviare all’errore 403 i nostri sviluppatori hanno usato l’indirizzo del redirect e lo hanno passato al web services, questo perchè per qualche motivo non è gestita bene la parte di re-indirizzamento delle chiamate verso il loro wsdl.
Si l’autenticazione avviene tramite certificato, ma non avendo cambiato nulla lato nostro, immaginiamo che prima della nostra chiamata non avessero inserito il nostro certificato nei loro server.
Si esatto, senza fare nulla ora riusciamo ad autenticarci e inviare file.
Certo, il file client.p12 devi crearlo, nel nostro caso (ma credo valga per tutti) abbiamo inserito la nostra private.key e il loro certificato client “SDI-PIVA.cer/pem”
Qualche giorno fa abbiamo contattato l’assistenza esponendo il problema della risposta 403 da browser, ci hanno detto che saremmo stati ricontattati.
Senza aver sentito nessuno o fatto modifiche dalla nostra parte, oggi funziona.
Penso quindi che fosse necessaria una abilitazione dalla loro parte.
In ogni caso otteniamo sempre errore da codice chiamando l’endpoint https://testservizi.fatturapa.it/ricevi_file
a questo punto verifichiamo meglio il nostro codice e nel caso ricontatteremo l’assistenza…