# Problema Test Interoperabilità **URL:** \ **Category:** Fatturazione Elettronica\ **Created:** [3 Ottobre 2025, 7:27am UTC](https://forum.italia.it/t/problema-test-interoperabilita/45870 "2025-10-03T07:27:16Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Carmine1](https://forum.italia.it/letter_avatar_proxy/v4/letter/c/ebca7d/32.png) [@Carmine1](https://forum.italia.it/u/Carmine1)\ **Post date:** [3 Ottobre 2025, 7:27am UTC](https://forum.italia.it/t/problema-test-interoperabilita/45870/1 "2025-10-03T07:27:16Z")
Ciao a tutti, dopo aver registrato il canale, ho iniziato con i test di interoperabilità. Simulando l’invio di fatture dall’ambiente di test dello SDI al mio webservice, riscontro però il seguente 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 Ho letto vari argomenti a riguardo su questo forum, e il problema sembra essere legato all’handshake che fallisce. Se ho capito bene, i certificati con cui si presenta il Client (SDI) al mio Server sembrano non combaciare. Il webservice che espongo per ricevere le fatture dallo SDI è di questo tipo: [https://CUSTOMDOMAIN/cxf/test/ReceiveInvoice](https://CUSTOMDOMAIN/cxf/test/ReceiveInvoice), dove CUSTOMDOMAIN presenta la seguente concatenazione di certificati: Certificato Server (firmato dall’Agenzia delle Entrate) + caentrate.cer (Root) Il certificato Server inoltre ha una configurazione TLS dove nella Trust List ho aggiunto sia caentrate.cer che caentratetest.cer. Qualcuno di voi ha riscontrato un problema simile e ha risolto? ---
**Author:** ![vbato](https://forum.italia.it/letter_avatar_proxy/v4/letter/v/3e96dc/32.png) [@vbato](https://forum.italia.it/u/vbato)\ **Post date:** [6 Ottobre 2025, 9:33am UTC](https://forum.italia.it/t/problema-test-interoperabilita/45870/2 "2025-10-06T09:33:18Z")
> [@Carmine1](#): > > Il webservice che espongo per ricevere le fatture dallo SDI è di questo tipo: [https://CUSTOMDOMAIN/cxf/test/ReceiveInvoice](https://CUSTOMDOMAIN/cxf/test/ReceiveInvoice), dove CUSTOMDOMAIN presenta la seguente concatenazione di certificati Assicurati che il certificato venga presentato anche quando ti colleghi direttamente all’indirizzo IP corrispondente a CUSTOMDOMAIN (`https://x.y.z.w/cxf/....`), perché il client usato da SdI non usa SNI e quindi non puoi usare il dominio per decidere di presentare il certificato del tuo canale. Deve essere quello di default associato all’indirizzo IP (se il client non richiede un altro dominio con SNI). ---
**Author:** ![Carmine1](https://forum.italia.it/letter_avatar_proxy/v4/letter/c/ebca7d/32.png) [@Carmine1](https://forum.italia.it/u/Carmine1)\ **Post date:** [6 Ottobre 2025, 9:47am UTC](https://forum.italia.it/t/problema-test-interoperabilita/45870/3 "2025-10-06T09:47:27Z")
Ciao Vladan, grazie per la risposta. Ma non credo di aver capito precisamente cosa intendi. Purtroppo su questa questione dei certificati non me ne intendo. Potresti essere più preciso su quello che dovrei fare? ---
**Author:** ![vbato](https://forum.italia.it/letter_avatar_proxy/v4/letter/v/3e96dc/32.png) [@vbato](https://forum.italia.it/u/vbato)\ **Post date:** [6 Ottobre 2025, 12:09pm UTC](https://forum.italia.it/t/problema-test-interoperabilita/45870/4 "2025-10-06T12:09:16Z")
La gestione dei certificati è la parte più complessa della configurazione di un canale e non sempre è facile venirne fuori se non si ha esperienza. Cosa bisogna fare esattamente dipende dall’ambiente e dai software usati. Per verificare se la configurazione è corretta, puoi eseguire i seguenti due comandi con `openssl`: ```auto openssl s_client -connect CUSTOMDOMAIN:443 -servername CUSTOMDOMAIN openssl s_client -connect CUSTOMDOMAIN:443 ``` In entrambi i casi dovresti ottenere lo stesso output. In particolare, dovrebbe esserci qualcosa del genere: ```auto Certificate chain 0 s:C = IT, O = Agenzia delle Entrate, OU = Fatturazione Elettronica, OU = Server, CN = SDI-99999999999 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 ``` Ovvero, dovrebbero esserci il certificato CA dell’AdE e il certificato server del tuo canale (il CN potrebbe anche avere il tuo dominio invece della partita IVA , se hai creato il CSR così). Ti darà anche errore di validazione del certificato, ma è normale, perché la CA dell’AdE non è tra quelle riconosciute dal sistema operativo (e dai browser). Se l’output del secondo comando non contiene il certificato server del tuo canale, allora hai il problema che dicevo, ovvero che il server non presenta il certificato a meno che il client non indichi esplicitamente il hostname durante il handshake TLS, cosa che il client SDI non fa. In questo caso devi scoprire come fare ad impostare un certificato “di default”, non legato ad uno specifico hostname (che viene usato nel caso in cui il client non lo specifica). ---
**Author:** ![Carmine1](https://forum.italia.it/letter_avatar_proxy/v4/letter/c/ebca7d/32.png) [@Carmine1](https://forum.italia.it/u/Carmine1)\ **Post date:** [6 Ottobre 2025, 12:42pm UTC](https://forum.italia.it/t/problema-test-interoperabilita/45870/5 "2025-10-06T12:42:56Z")
Ho fatto la prova che mi hai suggerito: **openssl s\_client -connect [sdi.hipoges.com:443](http://sdi.hipoges.com:443) -servername [sdi.hipoges.com](http://sdi.hipoges.com)** CONNECTED(0000019C) depth=1 C = IT, O = Agenzia delle Entrate, CN = CA Agenzia delle Entrate verify error:num=19:self signed certificate in certificate chain verify return:1 depth=1 C = IT, O = Agenzia delle Entrate, CN = CA Agenzia delle Entrate verify return:1 depth=0 C = IT, O = Agenzia delle Entrate, OU = Fatturazione Elettronica, OU = Server, CN = [SDI.HIPOGES.COM](http://SDI.HIPOGES.COM) verify return:1 Certificate chain 0 s:C = IT, O = Agenzia delle Entrate, OU = Fatturazione Elettronica, OU = Server, CN = [SDI.HIPOGES.COM](http://SDI.HIPOGES.COM) 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 **openssl s\_client -connect [sdi.hipoges.com:443](http://sdi.hipoges.com:443)** CONNECTED(000001B0) depth=1 C = IT, O = Agenzia delle Entrate, CN = CA Agenzia delle Entrate verify error:num=19:self signed certificate in certificate chain verify return:1 depth=1 C = IT, O = Agenzia delle Entrate, CN = CA Agenzia delle Entrate verify return:1 depth=0 C = IT, O = Agenzia delle Entrate, OU = Fatturazione Elettronica, OU = Server, CN = [SDI.HIPOGES.COM](http://SDI.HIPOGES.COM) verify return:1 Certificate chain 0 s:C = IT, O = Agenzia delle Entrate, OU = Fatturazione Elettronica, OU = Server, CN = [SDI.HIPOGES.COM](http://SDI.HIPOGES.COM) 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 ed effettivamente entrambi contengono il certificato server firmato dall’AdE. Però ho approfondito la questione dello SNI di cui mi parli. Il dominio [sdi.hipoges.com](http://sdi.hipoges.com) è un dominio custom che uso per mascherare il reale endpoint del mio Server (lavoro su SAP e questo era un prerequisito fondamentale da implementare). Quindi se chiamo l’endpoint [https://sdi.hipoges.com/cxf/hiplaw/ItalyReceiveInvoice](https://sdi.hipoges.com/cxf/hiplaw/ItalyReceiveInvoice) vengo direzionato correttamente al vero endpoint del server (ho testato questa cosa tramite Postman). Ma visto che SDI non invia il campo SNI, invece di richiedere [sdi.hipoges.com](http://sdi.hipoges.com) lo SDI si connette direttamente all’indirizzo IP del dominio. Infatti facendo il seguente test trovo: **openssl s\_client -connect 20.82.83.59:443** CONNECTED(0000015C) Can’t use SSL\_get\_servername depth=1 C = US, O = DigiCert Inc, CN = DigiCert Global G2 TLS RSA SHA256 2020 CA1 verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = DE, ST = Baden-W\C3\BCrttemberg, L = Walldorf, O = SAP SE, CN = \*.cf.eu20-001.hana.ondemand.com verify return:1 Certificate chain 0 s:C = DE, ST = Baden-W\C3\BCrttemberg, L = Walldorf, O = SAP SE, CN = \*.cf.eu20-001.hana.ondemand.com i:C = US, O = DigiCert Inc, CN = DigiCert Global G2 TLS RSA SHA256 2020 CA1 1 s:C = US, O = DigiCert Inc, CN = DigiCert Global G2 TLS RSA SHA256 2020 CA1 i:C = US, O = DigiCert Inc, OU = [www.digicert.com](http://www.digicert.com), CN = DigiCert Global Root G2 e qui giustamente il certificato firmato dall’AdE non c’è. Mi confermi di aver capito bene il problema? Se ho capito bene dovrò essere io a trovare una soluzione, tramite magari un reverse proxy. Cosa che però mi sembra abbastanza strana, perchè nella guida ufficiale SAP che ho seguito non fa nessun riferimento a questo. ---
**Author:** ![Carmine1](https://forum.italia.it/letter_avatar_proxy/v4/letter/c/ebca7d/32.png) [@Carmine1](https://forum.italia.it/u/Carmine1)\ **Post date:** [6 Ottobre 2025, 12:48pm UTC](https://forum.italia.it/t/problema-test-interoperabilita/45870/6 "2025-10-06T12:48:36Z")
Ovviamente intendevo dire “Mi confermi che ho capito bene IO il problema?”😂 ---
**Author:** ![vbato](https://forum.italia.it/letter_avatar_proxy/v4/letter/v/3e96dc/32.png) [@vbato](https://forum.italia.it/u/vbato)\ **Post date:** [6 Ottobre 2025, 4:49pm UTC](https://forum.italia.it/t/problema-test-interoperabilita/45870/7 "2025-10-06T16:49:48Z")
Sì, hai capito bene. Però sono io che non avevo capito come funziona il comando `s_client` di openssl. Le due prove che ti ho detto di fare sono equivalenti. Se non viene specificata l’opzione `-servername`, openssl usa comunque SNI con il nome host specificato in `-connect`. Per non farglielo usare, bisogna fare come hai fatto tu (usare l’indirizzo IP), oppure specificare l’opzione `-noservername`. Siccome senza SNI il server SAP restituisce un certificato generico (e non quello tuo), mi sa che serve un reverse proxy che gestisca la parte SSL. Non so come mai la guida non menziona la cosa (o se c’è qualche altro modo per aggirare il problema, tipo un indirizzo IP dedicato su cui mettere il proprio certificato). Mi è anche venuto il dubbio che magari nel frattempo il client SDI è stato aggiornato e ora usa SNI, ma no. Ho appena controllato e continua a non usarlo.