Aprire il file MORECERT.PEM con il notepad e verificare:
- che sia in formato ASCII
- che i certificati siano accodati correttamente (non devono esserci -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- sulla stessa riga)
- che abbia una riga vuota alla fine
Buongiorno,
in questo modo riesci anche a ricevere?
Noi siamo riusciti dopo mille prove ad installare i certificati per l’invio della fattura, però non riusciamo ancora a ricevere. Nel dettaglio abbiamo creato un contenitore .p12 dove abbiamo concatenato tutti i certificati a nostra disposizione. Poi nel server xml del nostro Apache Tomcat abbiamo indicato tale file. Abbiamo anche inserito i vari certificati all’interno del cacerts di Java.
Fatto questo riusciamo ad inviare la fattura allo sdI che la interpreta correttamente ma non riesce a mandarci le notifiche,
Nel dettaglio dei messaggi dal sito fatturapa.gov.it viene segnalato il seguente errore:
javax.net.ssl.SSLHandshakeException: General SSLEngine problem
mentre lato nostro non riceviamo errori.
Sembra che lo sdI non riconosca il nostro certificato (che l’agenzia ci ha fornito).
Mi viene quindi da pensare che mettere tutto insieme in unico certificato non sia la soluzione adeguata……
Abbiamo provato a inviare una richiesta di assistenza, ci hanno chiamato per dirci che ci avrebbero risposto a breve ma non abbiamo ancora avuto risposta……
Buongiorno Dario,
ho seguito la procedura da te indicata e sul Tomcat ho associato il pfx creato. Adesso l’invio della notifica di scarto fallisce di nuovo ma con errore differente:
Buongiorno Dario,
grazie per le istruzioni, ho provato a generare i file pfx ma continua a non funzionare.
L’errore alla chiamata del web service sdi RiceviFile è sempre:
System.ServiceModel.Security.SecurityNegotiationException: Impossibile stabilire un canale sicuro per SSL/TLS con l’autorità ‘testservizi.fatturapa.it’. —> System.Net.WebException: Richiesta annullata: Impossibile creare un canale sicuro SSL/TLS…
in System.Net.HttpWebRequest.GetResponse()
in System.ServiceModel.Channels.HttpChannelFactory`1.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
— Fine della traccia dello stack dell’eccezione interna —
Server stack trace:
in System.ServiceModel.Channels.HttpChannelUtilities.ProcessGetResponseWebException(WebException webException, HttpWebRequest request, HttpAbortReason abortReason)
in System.ServiceModel.Channels.HttpChannelFactory`1.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
in System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSpan timeout)
in System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout)
in System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object ins, Object outs, TimeSpan timeout)
in System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
in System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
Exception rethrown at [0]:
in System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
in System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
in FatturaE.FatturaPARF.SdIRiceviFile.RiceviFile(RiceviFileRequest request)
in FatturaE.FatturaPARF.SdIRiceviFileClient.FatturaPARF_SdIRiceviFile_RiceviFile(RiceviFileRequest request)
Controllando con il comando openssl s_client - connect
verso testservizi.fatturapa.it e verso il nostro server e sembra tutto corretto.
A questo punto penso sia qualcosa nel modo in cui effetuiamo al chiamata, noi stiamo utilizzando codice .net (vb ma va bene anche c#), qualcuno ha qualche esempio da fornire per queste chiamate ai web service sdi?
Grazie a tutti
Buongiorno Dario, abbiamo creato i pfx client e server con la procedura da te indicata. Al momento nel Connector del server.xml di Tomcat abbiamo associato il pfx server creato al keystore e il cacerts di Java al truststore inserendo nel cacerts i due pfx creato però ancora non riusciamo a completare il flusso. Questi due certificati un volta creati, come vanno linkati al webserver e a Java?
buongiorno
anche su iis abbiamo grossi problemi
installato i due pfx come da questo post.
nei certificati della macchina li vedo.
sul sito ho configurato il certificato .
se vado sul sito https://testservizi.fatturapa.it/ mi dice che non è sicuro .
ho caricato tutti i certificati che ci hanno passato in tutte le radici possibili.
CAEntratetest.cer / caentrate.der / test.servizi.fatturapa.it.cer
servizi.fatturapa.it.cer / SistemaInterscambioFatturaPA.cer / SistemaInterscambioFatturaPATest.cer
Buongiorno
Noi non abbiamo utilizzato webserver ma implementato un servizio windows in c# che ospita un server http ssl. Invio e ricezione fatture funzionano.
I certificati li ho caricati tutti nello store personal del server.
Un saluto a tutti,
dopo una risposta negativa dall’assistenza (problema dal nostro lato nessuna assistenza…) ritorno sul problema certificati.
Ho ri-seguito la guida di Dario sulla creazione dei pfx, rimossi i certificati e reinstallati.
Ricontrollato con openssl ed eseguendo dal nostro server:
openssl s_client -connect testservizi.fatturapa.it:443
noto una cosa che prima mi sfuggiva:
Citazione CONNECTED(00000140)
depth=1 C = IT, O = Agenzia delle Entrate, OU = Servizi Telematici, CN = CA Agen
zia delle Entrate
verify error:num=19:self signed certificate in certificate chain
5236:error:89070077:lib(137):CAPI_RSA_SIGN:unsupported algorithm nid:e_capi.c:84
5:NID=0x2a3
5236:error:14099006:SSL routines:ssl3_send_client_verify:EVP lib:s3_clnt.c:3222: —
Certificate chain
0 s:/C=IT/O=Agenzia delle Entrate/OU=Servizi Sicuri/CN=testservizi.fatturapa.it
i:/C=IT/O=Agenzia delle Entrate/OU=Servizi Telematici/CN=CA Agenzia delle Entrate
1 s:/C=IT/O=Agenzia delle Entrate/OU=Servizi Telematici/CN=CA Agenzia delle Entrate
i:/C=IT/O=Agenzia delle Entrate/OU=Servizi Telematici/CN=CA Agenzia delle Entrate
Cosa significa error 19 self signed certificate in certificare chain?
Potrebbe essere questo il problema?
Il certificato self signed in questione è quello indicato con il numero 1 e con cn=CA Agenzia delle Entrate.
Questo è il certificato principale che firma tutti i certificati usati dall’agenzia e devi includerlo tra quelli considerati “attendibili” per avere una connessione senza segnalazione di errori.
Però, attenzione: sul servizio di produzione troverai una situazione diversa:
$ openssl s_client -connect servizi.fatturapa.it:443
CONNECTED(00000005)
depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/C=IT/ST=Rome/L=Rome/O=Sogei - Societa' Generale d'Informatica S.p.A./CN=servizi.fatturapa.it
i:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2
1 s:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2
i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
2 s:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
Con openssl esce comunque error:num=19, ma qui il certificato non è firmato dal certificato interno dell’agenzia, ma da un certificato pubblico che normalmente è considerato attendibile dai browser, dal run time Java o dai certificati installati sul sistema a seconda di ciò che usa il tuo sistema mentre si connette.
Buongiorno,
anch’io continuo a ricevere questo messaggio di errore all’invio della notifica di scarto da parte dell’SDI al mio WS (https://…/RicezioneFatture.asmx):
Buongiorno,
no sono sempre bloccato.
Mi pare di capire che tu sei più avanti, in quanto parli di notifica di scarto?
Riesci quindi a chiamare il ws dello sdi RiceviFile?
Sì riesco a richiamare il ws RiceviFile ed inviare il file.
Riesco a vederlo in monitoraggio flussi nella gestione canale sul sito: www.fatturapa.gov.it.
Il primo step “Lettura dati instradamento” da esito positivo.
Il secondo "Invio fattura a Pubblica Amministrazione " da l’errore:
org.apache.axis2.AxisFault: HTTP ( 403 ) Forbidden address : https://26.2.162.231:80
Ho segnalato il problema all’assistenza ma al momento non mi hanno risposto.
Ciao a tutti , io sono nella stessa situazione di errore 403 Forbidden, la cosa strana è che per il canale aziendale ha funziona tutto correttamente, mentre per i nostri clienti sempre la stessa procedura, da sempre errore 403 Forbidden, qualcuno ha avuto la stessa problematica?