stiamo eseguendo i test di iteroperabilità con lo SDI e la nostra architettura di funzionamento prevede un nostro server centrale (responsabile della comunicazione con lo SDI e su cui abbiamo installato i certificati prodotti da SDI) e una serie di server (che fungono da client) che comunicano con il server centrale in modalità REST per la trasmissione delle fatture. Una volta comunicate al server centrale , le fatture verrebbero inviate tramite SOAP allo SDI.
Il problema è che il certificato server che SDI ci ha comunicato (in formato _nome_host_server.PEM) e che noi abbiamo configurato sul nostr Apache Tomcat sembra che non permetta le comunicazioni dai client in formato HTTPS. Questo perchè nel certificato server manca il campo SAN (Subject Alternative Name).
Il SAN non c’entra niente. Comunque per me non riuscirai mai a fare quello che dici se usi lo stesso sito Web sia per l’endpoint dello SDI che quello dei tuoi client.
L’endpoint SDI deve essere accessibile con la cifratura fatta con le chiavi firmate da loro e l’autenticazione con i certificati client emessi da loro. Tutto questo non andrà mai con i tuoi client.
Devi fare sul tuo Wen server due siti diversi, uno per lo SDI e uno per i tuoi client, e poi far funzionare una applicazione distribuita su più moduli per tenere assieme il tutto. Questo perlomeno se teniamo conto delle notifiche e altre comunicazioni in entrata dallo SDI. Se ragioni solo per la spedizione vera e propria, puoi chiaramente fare un hub centrale REST per i tuoi client, e da lì far partire le fattura in uscita allo SDI via SOAP. Ma in questo scenario i certificati SSL dello SDI non c’entrano niente e non li devi montare sul tuo Web server che eroga il servizio REST.
Se proprio vuoi, puoi anche fare tutto con un solo sito, ma devi intervenire sul lato client, disabilitando la normale verifica del certificato server (perché la verifica del nome del host fallirà sempre) e facendola tu esplicitamente (verificando che il certificato sia esattamente quello che hai sul server).
Però concordo con Bruno… secondo me ti conviene creare due siti distinti per la comunicazione con SdI e la comunicazione con i tuoi client.
Anche noi pensavamo di usare un solo sito per entrambe le cose, prima di scoprire come funziona veramente SdI. Il problema è che a quel punto era troppo tardi per cambiare gli endpoint, a meno di non annullare la procedura di accreditamento e ricominciare da capo, quindi abbiamo “sprecato” il nome host fatture.nostrazienda.com per la comunicazione con SdI.
Oggi spesso provvediamo a fare i primi test con un doppio application server, uno “fronte” client" e l’altro “fronte” SDI.
Spero che il tutto vada liscio
Il problema è sempre il client dell’AdE. Siccome non supporta SNI, devi dargli il certificato giusto senza sapere per quale hostname deve fare la richiesta.
Una possibile soluzione (di cui si era già parlato nel forum) è quella di abilitare l’SNI sul server e mettere come certificato di default quello dell’AdE. In questo modo, quando si collega il client del SdI, senza SNI, gli viene passato il certificato loro, mentre i client che supportano SNI (qualsiasi cosa non troppo vetusta) ricevono il certificato in base al hostname.
Non ne sono sicuro, ma mi pare che con apache, se abiliti SNI e definisci più virtual host, il certificato di default che viene usato quando non è specificato un hostname è quello del primo virual host, quindi basta mettere quello usato per la comunicazione con il SdI per primo.
si teoricamente è possibile mettere sullo stesso binding un sito con SSL “senza SNI”, e altri siti con SSL “con SNI”, e usare tassativamente il primo per AGED. Perlomeno in IIS è abbastanza facile.
Cmq che complicazioni inutili nel 2018…
