Ciao a tutti,
ho un canale SDICOOP accreditato correttamente in produzione, dopo aver superato tutti i test correttamente.
Il problema che riscontro è che su 10 chiamate alla RiceviFatture che ricevo da SDI, almeno 2 non vanno a buon fine. Dai log di IIS ho notato che la chiamata si conclude con errore 403 e substatus 0.
La cosa strana è che appunto le altre chiamate si concludono correttamente in stato 200, ricevendo correttamente la fattura! Fosse un problema di certificati otterrei errore su ogni chiamata ricevuta.
Ho importato nella trusted root della macchina il certificato CA Agenzia Delle Entrate, mentre nello store personal dell’utente tutti gli altri (i 2 .pfx client e server, il certificato servizi.fatturapa e il certificato Sistema di Interscambio fattura PA).
L’unica cosa che mi viene in mente è che il SdI abbia server multipli che consegnano le fatture e che abbiano installato certificati client diversi, per cui alcuni funzionano e altri no. Per saperlo dovresti riuscire a salvare le informazioni relative al certificato in un log.
Non conosco IIS per cui ti chiedo: così come hai configurato IIS, il client SdI deve per forza usare il certificato client fornito durante la procedura di accreditamento (SistemaInterscambioFatturaPA.cer), oppure viene accettato qualsiasi certificato client firmato dalla CA dell’AdE?
Ti chiedo questo perché noi non abbiamo riscontrato questo problema e la verifica che facciamo è che il certificato client sia firmato dalla CA dell’AdE e che il CN del certificato corrisponda a “Sistema Interscambio Fattura PA”, che è meno rigido rispetto alla verifica della corrispondenza esatta del certificato.
Tra l’altro ho notato che il certificato che ci avevano dato nel kit di test a ottobre è scaduto a novembre, quindi presumo che non lo stiano più usando.
Ciao,
anch’io ho lo stesso problema con apache su linux e su canali diversi.
Nell’ultima configurazione funzionante di apache ho messo il certificato
CN=CA Agenzia delle Entrate,OU=Servizi Telematici,O=Agenzia delle Entrate,C=IT con hash 498e3e72
su entrambi i file
SSLCertificateChainFile /etc/sdi_certificate/caentrate.cer
SSLCACertificateFile /etc/sdi_certificate/caentrate.cer
ma l’errore 403 continua a uscire. Quali altri certificati potrei aggiungere alla catena per cercare di coprire tutte le casistiche?
Grazie
Avete provato a vedere i log? Non c’è scritto nulla di utile?
In particolare apache dovrebbe mettere nel log degli errori il motivo per cui l’autorizzazione viene negata.
[Thu Jan 10 09:30:50.233493 2019] [ssl:info] [pid 10269:tid 140266258204416] [client 217.175.52.231:46081] AH01964: Connection to child 24 established (server xxxx:443)
[Thu Jan 10 09:30:50.234232 2019] [ssl:debug] [pid 10269:tid 140266258204416] ssl_engine_kernel.c(2143): [client 217.175.52.231:46081] AH02645: Server name not provided via TLS extension (using default/first virtual host)
[Thu Jan 10 09:30:50.319770 2019] [ssl:debug] [pid 10269:tid 140266258204416] ssl_engine_kernel.c(366): [client 217.175.52.231:46081] AH02034: Initial (No.1) HTTPS request received for child 24 (server xxxxx:443)
[Thu Jan 10 09:30:50.319859 2019] [ssl:debug] [pid 10269:tid 140266258204416] ssl_engine_kernel.c(746): [client 217.175.52.231:46081] AH02255: Changed client verification type will force renegotiation
[Thu Jan 10 09:30:50.461962 2019] [ssl:debug] [pid 10269:tid 140266258204416] ssl_engine_kernel.c(2143): [client 217.175.52.231:46081] AH02645: Server name not provided via TLS extension (using default/first virtual host)
A quanto pare c’è qualche problema con il certificato SSL.
La differenza nei due casi sta nella riga con l’errore: alert bad certificate (SSL alert number 42)
Per qualche motivo il certificato non gli piace, ma non c’è nessun altro dettaglio.
Apparentemente il SdI ha client diversi che presentano certificati diversi e uno di questi viene rifiutato, ma senza vedere i suddetti certificati è difficile capire il perché.
Non vedo come possa utilizzare certificati differenti. Tutti quelli che mi sono stati passati nel kit di test sono mappati nello store dei certificati della macchina (ad eccezione ovviamente dei certificati di test)
Come ho scritto all’inizio, il certificato client che ho io nel kit è scaduto a novembre (perché la richiesta di accreditamento l’avevamo fatta a ottobre), quindi il certificato client con cui si collega il SdI adesso non può essere lo stesso che ho io nel kit.
Il certificato CA, quello sì che è uguale, ma il certificato client nel frattempo l’hanno aggiornato.
La mia ipotesi (ma ripeto senza vedere i certificati è difficile dirlo) è che utilizzino più certificati client diversi su server diversi (anche se firmati dalla stessa CA) e che uno di questi per qualche motivo vi crea problemi.
Noi queste anomalie non le abbiamo finora riscontrate, ma abbiamo ricevuto solo una cinquantina di fatture e non utilizziamo né IIS né apache.
Grazie per la risposta, il certificato client che abbiamo ricevuto a novembre scade nel 2021… Purtroppo non ho trovato su IIS il modo di vedere quale certificato viene usato per autenticare la richiesta. Proverò in giornata a sentire Sogei. Qualcun altro ha avuto lo stesso problema?
ma non è il problema della CRL che ho già sollevato e discusso (e risolto) su IIS, dovuto al fatto che il certificato della loro CA ha una assurdità dentro?
Ho sentito il supporto tecnico di Sogei. Se comunichi loro l’identificativo SdI riescono a dirti l’errore esatto (come in fase di test). Il mio problema è che ottengo l’errore “Unable to decrypt message”.
Questo messaggio può trarre in inganno.
Sta ad indicare che lo Sdi non è riuscito a decriptare il messaggio, ma questo potrebbe essere dovuto al semplice fatto che stai restituendo una pagina html di Internal Error Server (almeno io avevo questo problema).
Se non l’hai già fatto verifica i log di IIS (io uso HttpLogBrowser che ti da un visione tabellare delle chiamate ed eventuali response errati). E eventualmente attivando ‘Failed Request Tracing rules’ su IIS dovresti avere informazioni in più per capire dov’è il problema.
A seguito di tre errori consecutivi di tentata consegna di una fattura passiva, il supporto mi ha riportato l’errore
In merito alla Sua richiesta, Le comunichiamo il file è in stato di mancata consegna.
L’errore riscontrato è il seguente: javax.net.ssl.SSLException: Received fatal alert: protocol_version.
Ciao e grazie per la risposta,
ho già visionato i log di IIS, ho come codice errore 403, substatus 0 e win32status 64 (che starebbe a significare “il nome di rete specificato non è più disponibile”). Per quanto riguarda le failed request tracing rules ho già controllato ma non mi torna nulla di utile, ho incollato lo screen pochi post sopra.
Anche io avevo status 64 (pero’ error code 500) e mi dava errori random (3 messaggi su 5 dello Sdi passavano), quel " il nome di rete specificato non è più disponibile" mi aveva portato parecchio fuoristrada, e alla fine non c’entrava niente.
Ho risolto sistemando i certificati, ti posso dare il link che mi ha risolto il problema, e puoi vedere se è il tuo caso, pero’ a tuo rischio e pericolo (fare modificare su impostazioni così delicate sul server comporta certe responsabilità e rischi).
