Accreditamento SdI, problemi con ricezione notifiche

Fatturazione Elettronica
1

Buongiorno

Sto cercando di accreditare un mio software per l’invio delle fatture.

La parte di invio nei test di interoperabilità funziona (vedo arrivare i file che vengono elaborati correttamente) ma al momento di ricevere le notifiche , sia quella di “invio fattura” che quella di “invio notifica mancata consegna” ai relativi endpoint di test assegnati falliscono

Il messaggio d’errore che vedo riportato dall’interfaccia del sistema dell’agenzia è

javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.ValidatorException: PKIX path building failed: com.ibm.security.cert.IBMCertPathBuilderException: unable to find valid certification path to requested target

Immagino (anche leggendo qualche informazione in giro) che questo indichi qualche problema con il certificato di autenticazione ma oltre quello brancolo nel buio

Il server su cui dovrebbe funzionare il tutto è ubuntu con nginx ed uno dei primi problemi che mi sta venendo segnalato da chi si occupa direttamente dell’impostazione del server è che noi abbiamo già dei certificati sul dominio che non possiamo rimuovere. Il tentativo che è stato fatto è stato creato un secondo dominio che punta agli endpoint senza però ottenere grandi cambiamenti

Al momento non saprei come essere pi specifico nella richiesta (purtroppo mi occupo del codice dell’applicazione,non del suo deploy quindi non ho a portata di mano le specifiche di come siano le impostazioni server/gli step effettuati),ogni aiuto è gradito e se servissero altre informazioni posso cercare di recuperarle

2

In questo lungo post:

sembrano esserci molte risposte riguardo ai problemi dei certificati da installare sul server (apache o nginx) che riceve i callback dello SDI. Da quello che ho capito il problema dei certificati si pone su due livelli:

  • a livello del server https si deve installare il certificato rilasciato da SDI con relativa root (il che rende il server stesso non riconosciuto nei browser che non hanno di sicuro quella root tra i trusted)
  • a livello di autenticazione della chiamata che deve essere fatta sempre sul certificato presentato da SDI per autenticare la connessione
    Se manca uno di questi due il callback non va a buon fine.

Mi spiace non poter essere di maggior aiuto, sto sviluppando anch’io un servizio simile ma non sono ancora arrivato alla parte di accreditamento sullo SDI (per ora uso OpenAPI), quello che ho scritto sopra l’ho dedotto leggendo il post e non per esperienza diretta, quindi prendilo cum grano salis!

Buon lavoro.

3

Grazie ma nessuna fortuna per il momento, continuiamo a ricevere lo stesso errore

4

Prova a usare openssl per connetterti al tuo server e vedi che certificato ti restituisce.
Tieni presente che il client del SdI non supporta SNI.

openssl s_client -connect example.com:443

Al posto di example.com metti il nome del tuo server (quello dell’endpoint che hai messo nella richiesta di accreditamento).

Se i certificati sono configurati correttamente, dovresti vedere qualcosa del tipo:

Certificate chain
 0 s:C = IT, O = Agenzia delle Entrate, OU = Fatturazione Elettronica, OU = Server, CN = SDI-12345678903
   i:C = IT, O = Agenzia delle Entrate, CN = CA Agenzia delle Entrate
 1 s:C = IT, O = Agenzia delle Entrate, CN = CA Agenzia delle Entrate
   i:C = IT, O = Agenzia delle Entrate, CN = CA Agenzia delle Entrate

(poi ci sarà anche un errore di certificato non valido, ma questo è normale perché la CA dell’AdE non è tra quelle riconosciute dai sistemi operativi/browser).

5

Grazie per il suggerimento

Quello che ottengo in risposta al momento è

Certificate chain
0 s:C = IT, O = Agenzia delle Entrate, OU = Fatturazione Elettronica, OU = Server, CN = SDI-xxxxxxxxxxxxxx
i:C = IT, O = Agenzia delle Entrate, CN = CA Agenzia delle Entrate
1 s:C = IT, O = Agenzia delle Entrate, CN = CA Agenzia delle Entrate
i:C = IT, O = Agenzia delle Entrate, CN = CA Agenzia delle Entrate
2 s:C = IT, O = Agenzia delle Entrate, OU = Servizi Telematici, CN = Sistema Interscambio Fattura PA
i:C = IT, O = Agenzia delle Entrate, CN = CA Agenzia delle Entrate
3 s:C = IT, O = Agenzia delle Entrate, CN = CA Agenzia delle Entrate Test
i:C = IT, O = Agenzia delle Entrate, CN = CA Agenzia delle Entrate Test

Gli xxxxxxxxxx dopo lo SDI- sono ovviamnte il codice corretto in realtà

C’è anche tutta una serie di indicazioni sull’encryption / data validità per ognuno che ho omesso

La cosa che mi salta all’occhio è che rispetto a quanto indicato sopra noi abbiamo apparentemente 4 certificati nella chain e non 2

6

Per qualche motivo avete messo nella chain esposta dal server anche il certificato client del SdI (con relativo certificato CA), che non c’entra niente, ma non so se crea problemi.
In realtà dovrebbero esserci solo il certificato server vostro (SDI-xxxxxxxxxx_server.cer) e il certifica CA dell’AdE (CAEntrate_prod.der).

7

Facciamo qualche prova e vediamo se il problema è li, incrociando le dita

8

e il certifica CA dell’AdE (CAEntrate_prod.der)

Una domanda perchè anche leggendo in giro ho trovato informazioni contrastanti

Nel nostro pacchetto di certificati forniti all’inizio della procedura di test abbiamo CAentrate.cer e CAEntratetest.cer

Immagino siano gli stessi certificati con codifica diversa

1)E’ necessario che li convertiamo in .der?
2)Va effettivamente usato il file di produzione anche per i test? Ho visto che viene suggerito anche in altre risposte ma senza dare la motivazione e la cosa genera una certa confusione (a cosa serve il cer di test allora?)

9

È tutto un casino.

Primo: l’estensione del file non c’entra molto con quello che c’è dentro. Alcuni dei file sono informato der (binari) altri in formato pem (testo). Devi aprire il file per capire in che formato è. Sulla conversione, dipende da cosa si aspettano il vostro server e il vostro client. In ogni caso con openssl puoi facilmente convertirli da un formato all’altro.

Il file CAEntrate.cer e CAEntratetest.cer non sono lo stesso certificato.

CAEntrate.cer è il certificato della CA usata per firmare:

  • Il certificato client di SdI per l’ambiente di produzione
  • Il certificato server di SdI per l’ambiente di test
  • I certificati client e server del canale (quelli vostri)

CAEntratetest.cer è invece il certificato della CA usata per firmare il solo certificato client di SdI per l’ambiente di test.

Da notare che il server di SdI in ambiente di test usa un certificato firmato dalla CA di produzione, mentre il server SdI in ambiente di produzione usa un certificato firmato da una CA riconosciuta (e non quella dell’AdE).

Quindi nella fase di test, dovrai usare CAEntrate.cer come parte della chain sia per il tuo certificato server che quello client.
CAEntratetest.cer invece lo puoi usare per autenticare il client SdI quando si collega al tuo server, ma puoi anche fare a meno di fare l’autenticazione in fase di test.
Siccome però è auspicabile che tu lo faccia in produzione, ti conviene approfittare dei test per capire come va configurata l’autenticazione del client.

Aggiungo una cosa: se il server web che usi lo consente, per l’autenticazione del client SdI conviene usare il solo certificato CA + il CN=“Sistema Interscambio Fattura PA” del client, piuttosto che lo specifico certificato client che ti mandano. Questo perché il certificato client di SdI dura solo tre anni, quindi quando cambia ti tocca sostituirlo. Se invece ti basi sul CN, non serve fare niente. Il certificato CA scade nel 2038.

10

Niente, nn riusciamo ad uscirne

Abbiamo provato quanto sopra e nginx ci rifiuta il certificato dicendo che non valida con la server.key
Se passiamo di nuovo la chain con 4 certificati viene accettata ma poi torniamo al punto iniziale (le fatture di test in uscita vanno ma le notifiche che arrivano in risposta sui due endpoint di test non riescon ad arrivare con errore javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.j: PKIX path building failed: com.ibm.security.cert.IBMCertPathBuilderException: unable to find valid certification path to requested target)

Se qualcuno ha tempo per scriver passo passo come va generato il tutto partendo dai certificati originali perchè non saprei cos altro chiedere a questo punto,mi pare assurdo non vadano quindi mi vien da pensare stiamo sbagliando qualcosa di così stupido da passare inosservato

E si, mi rendo conto che il fatto io non sia direttamente chi sta lavorando sulla parte nginx non aiuta

11

Ma quali due certificati ci hanno messo? Sembra quasi che ci abbiano messo il terzo (“CN = Sistema Interscambio Fattura PA”) + la CA, per cui ovviamente non hai la chiave. La chiave privata è associata al certificato “SDI-xxxxxxxxxx”.

Purtroppo noi non usiamo nginx, quindi non saprei darti le istruzioni passo passo.
Noi usiamo HAProxy, e lì abbiamo semplicemente usato un unico file pem, ottenuto concatenando SDI-xxxxxxxxx_server.pem + CAEntrate_prod.pem + SDI-xxxxxxxxxxx_server.key.

12

I file dovrebbero essere quelli giusti, per lo meno da quel che mi è stato detto hanno usato i file che suggerivi sopra per la chain

Giusto per riverificare riducendo la domanda all’osso:

  • per riuscire a ricevere le notifiche di consegna soltanto in test (il cielo ci aiuterà in futuro per la produzione,per ora cerchiamo di far andare questo) quali certificati vanno usati? (si, lo so che son scritti qua sopra ma giusto per esser sicuro al 10% che ci siamo capiti correttamente)

Perchè se i certificati sono definitivamente,assolutamente quelli a quel punto o è sbagliata qualche conf. in nginx o non so dove sbattere la testa

13

Da quello che ho visto dando un’occhiata veloce alla documentazione, la configurazione di nginx prevede di specificare due file: uno con la catena dei certificati e l’altro con la chiave privata.
Quindi le istruzioni passo passo dovrebbero essere:

  • Convertire il certificato server fornito (SDI-xxxxxxxxxxx_server.cer) in formato pem (SDI-xxxxxxxxxxx_server.pem)
  • Concatenare il file così ottenuto con il certificato della CA di produzione dell’AdE (CAEntrate_prod.der o caentrate.cer, entrambi già in formato pem) per produrre il bundle da usare in nginx: SDI-xxxxxxxxxxx_server.pem + CAEntrate_prod.der → server.crt
  • Mettere la chiave privata usata per generare la csr per il certificato server (attenzione che il certificato server e client usano chiavi diverse) in formato pem in server.key.
  • Usare i due file nella configurazione nginx:
ssl_certificate     server.crt;
ssl_certificate_key server.key;
14

Provato ma niente da fare

Se provo a creare la catena con quei due file tra l’altro mi da di nuovo l’errore sulla key per qualche motivo appena provo a riavviare nginx

Abbiamo anche provato a seguire SDICoop Ricezione - 2024 English / French tutorial - Nginx, uwsgi, Python, Django quella procedura scritta lo scorso anno qua sul forum ma niente, sempre stesso errore

L’unica cosa è che,guardando quello, se non abbiamo interpretato male dobbiamo passare la parte che dovrebbe autorizzare le notifiche sotto l’ozione ssl_client_certificate invece che ssl_certficate (dove va “il resto”,chiamiamolo così)

P.s: al netto dell’ultimo test la configurazione è così

server {
  listen 443 ssl ;
  server_name dominio.it;

ssl_protocols SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_certificate /path/chain-server2cert.crt;
ssl_certificate_key /path/server.key;



ssl_verify_client on;
ssl_verify_depth 5;
ssl_client_certificate /path/chain-client.cer;

ssl_stapling off;
ssl_stapling_verify off;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DES-CBC3-SHA:!ADH:!AECDH:!MD5;


#  ssl_stapling on;
 resolver 8.8.8.8 8.8.4.4;

  location / {
    proxy_pass main_dominio.it/;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forward-Proto http;
    proxy_set_header X-Nginx-Proxy true;
    proxy_redirect off;
  }

}




server {
  listen 0.0.0.0:80;
  server_name dominio.it;
  return 301 https://$server_name$request_uri;
}

E questo è quello che mi arriva facendo la richiesta openssl di cui si parlava sopra per il check

Certificate chain
0 s:C = IT, O = Agenzia delle Entrate, OU = Fatturazione Elettronica, OU = Server, CN = SDI-PIVA
i:C = IT, O = Agenzia delle Entrate, CN = CA Agenzia delle Entrate
1 s:C = IT, O = Agenzia delle Entrate, CN = CA Agenzia delle Entrate
i:C = IT, O = Agenzia delle Entrate, CN = CA Agenzia delle Entrate

15

Hmm, il problema potrebbe essere l’autenticazione del client SdI.
Prova a mettere ssl_verify_client off

16

Provato anche quello,niente da fare

17

Mi dispiace ma non ho altre idee.

Volevo suggerirti di contattare l’assistenza di SdI perché magari il problema è sul lato loro (ogni tanto l’ambiente di test ha problemi e non lo sistemano finché qualcuno non lo segnala), ma ho appena fatto una prova con il nostro canale in ambiente di test e funziona tutto regolarmente.