Salve a tutti,
noi siamo accreditati da fine Ottobre, abbiamo passato la fase di test senza troppi problemi grazie a tutti i precursori/eroi di questo forum. In reale fino a Gennaio nessun problema anche perchè ci recapitavano poche fatture. Da gennaio il problema: circa il 30 % delle chiamate che viene effettuato da SDI verso il nostro WebService (sia ricevifatture che inviafatture) non passano.
Nel log di IIS vedo che viene chiusa la connessione con errore 403 sub 7 che sembrerebbe essere un errore sui certificati.
Non capisco come mai capiti!
Sembra quasi che SDI faccia chiamate con certificati non corretti.
Se fosse un problema nostro non dovrebbe capitare sempre?
Ho anche provato ad aprire un Ticket con il centralino dell’assistenza ma, si sono rifiutati di aprirmelo, dicendo, che essendo le fatture arrivate nel cassetto fiscale del Cliente per loro e tutto ok (ma l’assistenza ai poveri intermediari chi la fornisce???).
Grazie Vladan, li avevo già letti…
adesso ho provato ad abilitare il clientcertnegotiation… vedremo se risolve…
Intanto se qualcuno ha altri suggerimenti sono bene accetti…
Grazie ancora.
Aggiornamento:
Se a qualcuno capita il mio stesso problema sembrerebbe essere risolto avendo disabilitato il CRL e abilitato il clientcertnegotiation del certificato nel binding del mio webservice.
Da quando l’ho fatto (circa 18 ore) non ho più avuto errore 403…
Ciao Matteo,
sembra che sia lo stesso problema che capita a me su IIS.
Sto provando la tua soluzione…
Ho disabilitato il CRL per il sito, solo questa operazione non ha risolto…
ora volevo abilitare il clientcertnegotiation del certificato nel binding del web service ma non mi è chiaro come fare… è una impostazione a livello di web.config o si deve fare qualcosa da codice? Mi potresti dare qualche indicazione?
Salve Claudio è la stessa cosa del CRL va abilitato reinstallando il certificato con netsh e mettendo la relativa voce ad enable io personalemente ho preso spunto da questo link :https://boyan.io/random-500-errors-iis-client-certificates/
Per il momento non ho più riscontrato lerrore 403 Sub 7…
io quelle cose le ho toccate a dicembre, sembrava andare, ma quando sono iniziate ad arrivare le fatture in entrata seriamente il problema si è ripresentato…
Salve Bruno,
io da quando ho effettuato queste variazioni non ho più avuto il problema.
Hai provato a verificare con netsh se le impostazioni del certificato sono ancora quelle corrette?
Forse nella root dei certificati attendibili ha più di un certificato della CA Agenzia delle entrate?
si anche io avevo avuto il dubbio che IIS se lo fosse perso e ho già controllato nei giorni scorsi, e le impostazioni erano entrambe corrette
nella root avrei sia l’AGED che l’AGED di test (che però un certificato diverso ovviamente, non vedo sovrapposizioni salvo che il nome gli somiglia), potrebbe dargli problemi? perchè?
Io per sicurezza togliere quello di Test…
Ho la vaga idea che abbiamo dovuto aggiungere la negoziazione del protocollo perché fanno chiamate anche con i server che utilizzavano per i test e in quei server hanno anche il certificati client di test e negoziando magari prende prima quello rispetto a quello di produzione.
E’ solo una mia opinione ma vale la pena provare. Al massimo se dopo averlo tolto il problema persiste puoi sempre aggiungerlo.
Ciao,
se vi può essere utile, io ho risolto spostando la richiesta del certificato client da “Richiedi” (come sembrava essere obbligatorio) ad “Accetta”
Si purtroppo si. Ritengo sia un problema del Sdi che deve risolvere. Non è possibile che alcune richieste arrivino con autenticazione e altre no in maniera del tutto random.
A me tutte le richieste arrivano da un IP specifico. Ho fatto che mettere un filtro.
Anch’io mi trovo nella situazione di ricevere l’errore 403.7 in modo random, da Sogei ancora nessuna risposta se non rigirare la problematica. Purtroppo aumentando il numero di documenti scambiati, l’errore si sta presentando sempre più frequentemente ed alcuni miei clienti non stanno ricevendo le fatture sul mio canale. All’inizio mi auguravo che almeno una delle chiamate seguenti di consegna funzionasse ma non è così; la probabilità di non ricevere un file sta diventando molto alta. Trattandosi di un blocco nella fase di autenticazione non siamo a conoscenza del contenuto della chiamata SOAP (o c’è modo di recuperarlo comunque?) e quindi non riesco a fornire alcun riferimento a Sogei se non su segnalazione tardive di miei clienti che non ricevono le fatture attese. Mio malgrado penso che seguirò la strada di Antonio che è quella che dovrebbe far meno male… grazie
Salve Marcello e Massimiliano,
io da quando ho applicato le variazioni sopra descritte non ho più avuto alcun errore… Prima delle modifiche il 30% delle chiamate mi andava in errore.
Siete sicuri di aver fatto tutto? avete anche rimosso il certificato di test dalla root dei certificati ?
Io utilizzo IIS 10 su WinServer 2016…
Se posso essere di aiuto fatemi sapere.
Buon lavoro
Grazie, sto provando ora… vi farò sapere se nelle prossime ore la situazione si risolve.
… anche perché non mi è chiaro da dove prende i certificati… ho i certificati macchina, quelli dell’utente dell’application pool e quelli dell’utente impersonificato dopo l’autenticazione
Buongiorno a tutti, non vorrei essere troppo ottimista ma dopo che ho mandato il messaggio per la disperazione sabato mattina, prima di modificare il codice, ho provato ad eseguire le seguenti operazioni:
ho riportato IIS con la negoziazione client disattivata per il solo sito ove risiedono i servizi chiamati dallo SDI, ho installato il servizio di tracciatura di IIS sperando di avere maggiori info sull’errore, configurata la tracciatura completa da console IIS, ho riavviato la macchina, riportato IIS con abilitata la rinegoziazione client solo per il sito dei servizi SDI, riavviato IIS, qualche imprecazione finale ma da quel momento non ho avuto più errori random (forse hanno fatto la differenza le imprecazioni…). Non mi sembra quindi un problema legato ai certificati installati (li ho tutti installati sulla medesima macchina) ma alla rinegoziazione client che forse non era stata correttamente attivata sul server.
Vi riporto lista comandi utilizzato: netsh http show sslcert
copiarsi i vari riferimenti di hash ecc… che serviranno dopo netsh http delete sslcert ipport=0.0.0.0:443 netsh http add sslcert ipport=0.0.0.0:443 certhash=(quello annotato) appid={(quello annotato)} certstorename=(quello annotato) verifyclientcertrevocation=Enable VerifyRevocationWithCachedClientCertOnly=Disable UsageCheck=Enable clientcertnegotiation=Enable
Anch’io uso IIS 10 su winserver 2016.
Spero possa essere di aiuto.