menu di navigazione del network

Canale SDICOOP produzione - Errori 403 saltuari


(Mattia) #1

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).

Grazie a tutti per l’aiuto


[RISOLTO]RicezioneFatture Errore 403 sub 7 random
Problema con la ricezione di alcune fatture/notifiche da parte dello SdI (Errore irreversibile definito dal protocollo TLS: 42)
Problemi indisponibilità canale web service Ricezione Fatture
(Vladan Bato) #2

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.


(Riccardo Camanzi) #3

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


(Vladan Bato) #4

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.


(Mattia) #5

Ho attivato i log di trace di IIS, ma l’unica cosa che mi dice è questo

In cui non trovo nulla di utile. posso vedere altro?


(Riccardo Camanzi) #6

Ecco il log di una connessione fallita

  • [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.282284 2019] [socache_shmcb:debug] [pid 10269:tid 140266258204416] mod_socache_shmcb.c(495): AH00831: socache_shmcb_store (0xec -> subcache 12)
  • [Thu Jan 10 09:30:50.282353 2019] [socache_shmcb:debug] [pid 10269:tid 140266258204416] mod_socache_shmcb.c(849): AH00847: insert happened at idx=0, data=(0:32)
  • [Thu Jan 10 09:30:50.282374 2019] [socache_shmcb:debug] [pid 10269:tid 140266258204416] mod_socache_shmcb.c(854): AH00848: finished insert, subcache: idx_pos/idx_used=0/1, data_pos/data_used=0/180
  • [Thu Jan 10 09:30:50.282384 2019] [socache_shmcb:debug] [pid 10269:tid 140266258204416] mod_socache_shmcb.c(516): AH00834: leaving socache_shmcb_store successfully
  • [Thu Jan 10 09:30:50.282413 2019] [ssl:debug] [pid 10269:tid 140266258204416] ssl_engine_kernel.c(2042): [client 217.175.52.231:46081] AH02041: Protocol: TLSv1, Cipher: AES256-SHA (256/256 bits)
  • [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.411860 2019] [ssl:info] [pid 10269:tid 140266258204416] [client 217.175.52.231:46081] AH02221: Requesting connection re-negotiation
  • [Thu Jan 10 09:30:50.411906 2019] [ssl:debug] [pid 10269:tid 140266258204416] ssl_engine_kernel.c(973): [client 217.175.52.231:46081] AH02260: Performing full renegotiation: complete handshake protocol (client does support secure renegotiation)
  • [Thu Jan 10 09:30:50.411992 2019] [ssl:info] [pid 10269:tid 140266258204416] [client 217.175.52.231:46081] AH02226: Awaiting re-negotiation handshake
  • [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)
  • [Thu Jan 10 09:30:50.532611 2019] [ssl:error] [pid 10269:tid 140266258204416] [client 217.175.52.231:46081] AH02261: Re-negotiation handshake failed
  • [Thu Jan 10 09:30:50.532688 2019] [ssl:error] [pid 10269:tid 140266258204416] SSL Library Error: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate (SSL alert number 42)
  • [Thu Jan 10 09:30:50.606740 2019] [ssl:debug] [pid 10269:tid 140266258204416] ssl_engine_io.c(1308): (70014)End of file found: [client 217.175.52.231:46081] AH02007: SSL handshake interrupted by system [Hint: Stop button pressed in browser?!]
  • [Thu Jan 10 09:30:50.606775 2019] [ssl:info] [pid 10269:tid 140266258204416] [client 217.175.52.231:46081] AH01998: Connection closed to child 24 with abortive shutdown (server xxxx:443)

(Riccardo Camanzi) #7

Questo messaggio è stato segnalato dalla comunità ed è stato temporaneamente nascosto.


(Vladan Bato) #8

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é.


(Riccardo Camanzi) #9

Potrebbe essere che qualche server sia impostato male e tenti di usare il protocollo sslv3

Error: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate (SSL alert number 42)

Ho verificato che il mio openssl non lo supprta più.
Questo spiegherebbe l’evento random

Riccardo


(Mattia) #10

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)


(Vladan Bato) #11

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.


(Mattia) #12

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?


(Bruno) #13

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?


(Mattia) #14

Avevo già letto la vostra discussione, ho già disabilitato la CRL ma purtroppo il problema persiste…
CRL


(Mattia) #15

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”. :thinking:


(Gianluca_c) #16

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.


(Riccardo Camanzi) #17

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.


(Mattia) #18

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.


(Gianluca_c) #19

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).

Occhio quindi (anceh perchè qui si parla di random error 500)
https://boyan.io/random-500-errors-iis-client-certificates/


(Gianluca_c) #21

scusa …mi era partito l’invio prima (vedi spora) :slight_smile: