[FatturaPA] Sostituzione certificato server SDI

Fatturazione Elettronica
22

Anche io sul server ma non ho rimosso nulla e sprattutto non ho cambiato i certificati client e server SDI-XXXXXXXXXXX.
Quindi all’atto pratico ho installato sul “computer locale” i tre certificati inviati nell’ordine corretto di percorso (UserTrustCA.cer > Sectigo RSA.cer > servizi.fatturapa.it.cer) e ho riassegnato hai certificati SDI-XXXXXXXXXXX i permessi dell’utente che esegue il codice dell’applicativo server perchè ne ho trovato uno senza permessi.

Ma secondo me nessuna di queste operazioni è stata risolutiva per la problematica e vi invito a leggere il mio posto nell’altro thread a riguardo (SDI EndPoint Down? - n°40 da Massimo.B)

:man_facepalming:

oggi mi sa che se ne va così

1 Mi Piace
23

Quella di installare i tre certificati ricevuti nella CA root authority del computer locale l’ho fatto anche io venerdi scorso, ed anzi mi ha bloccato la ricezione delle fatture e notifiche. Una volta rimossi è tornato a funzionare tutto, almeno fino a questa mattina. Ora sono stato ricontattato dal supporto al quale hanno detto i tecnici Sogei che i cambi che hanno fatto non inficiano sul mio server e che devo controllare la mia configurazione. Eppure io non ho cambiato nulla e mi sembra di capire che in questa situzione siamo in parecchi.

24

ATTENZIONE!
Confermo di aver cancellato tutti i certificati ricevuti, tra l’altro installati e reinstallati almeno 4 volte. Ho persino rimosso le CA precedenti, quelle installate con i certificat client e server e senza quelle non ha funzionato più nulla. Poi ho ripristinato tutto alla situazione di settimana scorsa e così è restato fino a questa mattina quando ha smesso da solo di ricevere notifiche fatture.

Questa mattina poi ho provato di tutto, meno male senza toccare i certificati client e server. Ho aperto anche una segnalazione.
Da qualche minuto ora sto ricevendo le notifiche senza di fatto aver fatto nulla.
Mistero. Sicuramente i tecnici Sogei hanno fatto qualcosa ma non si sa cosa.
Comunque devo ringraziare la Sig.ra (non so il nome) del supporto che si è presa a cuore la questione e la sta ancora seguendo. Mi ha persino richiamato in pausa pranzo.

25

Anche a me più o meno è successa la stessa cosa.
Dalle 04.00 di stanotte non arrivava più niente, chiamo lo SDI e poco dopo averlo chiamato verso le 12.00 ha ricominciato a funzionare regolarmente.
In pausa pranzo mi ha ricontattato il supporto SDI dicendo che ora vedevano che aveva ripreso a funzionare senza che i loro sistemisti toccassero nulla (neanche io ho toccato nulla).
Ci siamo lasciati con un “boh, meglio così” che fa un po’ sorridere.

Da quello che dicono loro comunque non sembra un problema generalizzato perchè di solito quando capita ricevono una marea di segnalazioni, mentre in questo caso sembrava ci fosse solo la mia… boh…

1 Mi Piace
26

Anche a me ha ripreso a funzionare ora. Non so se ha risolto lo SDI o sono state le mie mosse di fatto a uso di chi magari ha ancora il problema vi espongo cosa ho fatto.
Ambiente Windows IIS 8.
In pratica ho rimosso ogni traccia dei nuovi certificati inviati dallo SDI via pec giorni scorsi.
Dalla macchina server tramite console certificati ho individuato tramite la funzione cerca per “issued by” e “issued to” i nuovi certificati confrontato le date di emissione e scadenza per conferma fossero proprio i nuovi ed eliminati…
Poi improvvisamente sono tornati i 200 puliti…

1 Mi Piace
27

Ovviamente quando alle 5 ha cominciato a dare errore non avevo ancora installato i nuovi ma avendo fatto 1 +1 tra pec da SDI e la data immaginavo che la soluzione fosse quella più logica.
Mi è sempre più chiaro che quando si parla di SDI la logica non centra una fava…

28

Ciao a tutti, a seguito della email che hanno inviato riguardante la sostituzione dei certificati avrei alcune domande, spero possiate aiutarmi.

il nostro web server nginx incaricato di ricevere le notifiche di SDI e’ configurato nel seguente modo:

server {
        listen 80;
        listen 443 ssl;
        ssl_certificate /etc/ssl/SDI-<piva>-server.pem;
        ssl_certificate_key /etc/ssl/SDI-<piva>-server.key;
        ssl_protocols SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2;
        ssl_verify_client optional;
        ssl_verify_depth 5;
        ssl_client_certificate /etc/ssl/CAEntrateAll.pem;

CAEntrateAll.pem e’ letteralmente la concatenazione dei seguenti certificati:

  • CAEntratetest.cer
  • caentrate.cer

Questo setup ha sempre funzionato fino al 26 Settembre 2023, giorno del cambio dei certificati.
Ad oggi non ricevo piu le notifiche.

Sapete dirmi cosa devo fare con i file ricevuti per email da SDI? (Sectigo RSA.cer, UserTrustCA.cer).
Devo accodarli al CAEntrateAll.pem che ho generato?
Non riesco a capire cosa ci devo fare con questi file che ci hanno inviato :smiley: .

Grazie in anticipo

29

Ciao, hai smesso di ricevere le notifiche esattamente dal giorno e dall’ora del cambio certificati o successivamente?

30

@manuel.esse dopo, non esattamente stesso giorno e ora.

31

Con quei certificati non devi fare niente. Come la Sogei ha puntualizzato più volte, quei certificati non c’entrano col tuo server ma colo loro. Sono i certificati che il loro server ti fa vedere quando chiami il web service per inviare le fatture.
I certificati sul tuo server rimangono gli stessi di prima, dato che scadono l’anno prossimo.

Noi non abbiamo toccato nulla né sul server né sul client e continua a funzionare tutto come prima.

Detto questo, rimane il fatto che qualcosa deve essere cambiato perché più di qualcuno ha avuto problemi a ricevere fatture e notifiche senza aver toccato la propria configurazione. Finora avevo visto solo casi di IIS, ma a quanto pare ci sono problemi anche con nginx.

Nella mia esperienza, quando ci sono problemi con SSL/TLS, è sempre un casino capire dove sta il problema.

32

Vladan, e questo casino fa il pari con quello delle API che a qualcuno sono aperte, ad altri no, mah…

33

Credo che siano due cose diverse. Nel caso delle API, la scelta di farle vedere a qualcuno sì e a qualcuno no è probabilmente fatta di proposito.
I problemi con i certificati SSL invece non credo lo siano. O è un problema tecnico che si verifica casualmente (per esempio alcuni dei loro server, ma non tutti, potrebbero avere un errore di configurazione), oppure c’è qualcosa di particolare nella configurazione dei server riceventi che, in combinazione con qualche modifica da parte loro, causa il problema.

34

L’unico modo per capire cosa causa esattamente il problema sarebbe attivare sul server un logging di debug dettagliato delle richieste, che includa tutta la parte della negoziazione TLS/SSL, in modo da vedere cosa il server manda al client e cosa il client manda al server e perché l’autenticazione fallisce.

Anche se non è il massimo, per tamponare il problema si potrebbe disabilitare l’autenticazione del client tramite certificato.

35

Questo lo so.
La gravità del fatto è proprio questa imprevedibilità - e talvolta disparità - nei comportamenti politici e tecnici da parte di chi dovrebbe offrire un servizio pubblico efficace, paritario, trasparente.
Aggiungi che da stamattina alle 6 non arriva più nulla come notifiche e fatture ricevute, e cadi anche in un altro grande dramma stradibattuto qui sul forum circa questi lunghi silenzi: ma come si fa???

36

Purtroppo ci siamo accorti che ancora oggi ogni tanto compaiono errori 413 sul canale di ricezione delle fatture. Sempre su IIS su win2016. Sembrava risolta la problematica dal loro lato ma evidententemente hanno fatto ulteriori modifiche. Non si capisce il motivo. Lato nostro nulla cambia, i certificati famosi del 26/9 non sono stati implementati come specificato da Sogei e tutte le configurazioni sono sempre quelle da anni. E’ evidente che stanno facendo qualcosa ma non dicono cosa e soprattutto non si capisce come mai alcuni hanno problemi e altri no. Qualcuno sta riavendo gli stessi problemi del 26/9?

37

Immagino tu intenda errore 403.13.
Non uso IIS, ma ho fatto una veloce ricerca e vedo molti risultati relativi alla verifica della CRL (Certificate Revocation List).
Il certificato client del SdI ha in effetti specificato un indirizzo (ldap!) per la verifica della CRL e può essere che se ci sono problemi a raggiungere quell’indirizzo, IIS generi automaticamente l’errore 403.13.

38

ciao a tutti, il giorno 23 aprile 2024 abbiamo ricevuto il seguente messaggio via PEC da SDI:
Il certificato “Sistema di InterscambioFatturaPa.cer”, prossimo alla scadenza, parte pubblica del certificato CLIENT utilizzato dal Sistema di Interscambio per invocare i servizi da voi esposti, verrà sostituito il 29 aprile 2024 nella fascia oraria 10,00 – 11,00.
Si ricorda che il nuovo certificato non comporta modifiche ai vostri sistemi a meno di avere implementato un controllo esplicito del vecchio certificato in scadenza.
In allegato il nuovo certificato e la CA emittente.
Abbiamo importato il certificato nel nostro sistema ma dal 29 non riceviamo nessun feedback da parte di SDI, nel senso che riusciamo ad inviare ma non a ricevere, qualcuno si è trovato nella stesa situazione? Come fare per risolvere l’errore e ritornare a ricevere i file da parte di SDI? Grazie

39

Ciao Giovanni, purtroppo lo Sdi ha rigenerato il certificato “Sistema di InterscambioFatturaPa.cer”, il giorno dell’entrata in vigore 29/04/2024 14:56:11 senza ridistribuirlo, perchè da quel che ho capito quello distribuito aveva qualche grana.

il nuovo certificato ha questi dati (io non c’e’ l’ho altrimenti te lo allegavo visto che non lo verifico):

[Subject]
CN=Sistema Interscambio Fattura PA, OU=Servizi Telematici, O=Agenzia delle Entrate, C=IT

[Issuer]
CN=CA Agenzia delle Entrate, O=Agenzia delle Entrate, C=IT

[Serial Number]
59CA87329068382E

[Not Before]
29/04/2024 14:56:11

[Not After]
29/04/2027 14:56:10

[Thumbprint]
ABF6D2BAD3629B452FA1B9E10352963C6A57D640

Dovresti contattare l’agenzia per farti mandare questo certificato.

40

Magari qualcuno di quelli che hanno ottenuto il certificato “corretto” dall’AdE, potrebbe postarlo qui in formato pem…

41

Ho esattamente lo stesso problema anche io. Per caso sei riuscito a risolverlo?