Buongiorno, sì per quanto riguarda la nostra configurazione con Tomcat abbiamo inserito i certificati della chain nel cacerts di Java, indicandolo nel server.xml con l’attributo trustoreFile ed il certificato server pfx creato come indicato da Dario come keystoreFile, poi all’avvio di Tomcat abbiamo indicato come parametri Java il pfx client che serve per inviare i file al SdI.
Ciao, non so se qualcuno può rispondermi, ma quando Dario al punto 3 srive:
Creare il file MORECERT.PEM
copy /b caentrate.cer
sarebbe il file caetrante.der non .cer, è corretto?
si è il file caentrate.der
Avrei bisogno di un chiarimento, non riusciamo a far funzionare il nostro web service trasmissionefatture con l’autenticazione client su IIS.
Allora il sito con il web service deve avere un certificato per ssl, va bene uno qualunque o serve il sdi-[partitaiva]-server.pfx (creato con le indicazioni di Dario)?
al momento stiamo usando questo altrimenti ci viene errore:
General SSLEngine problem
Poi abbiamo abilitato l’autenticazione con certificato client, ma non funziona, da browser chiamando il nostro web service, non viene richiesto il certificato e infatti le notifiche dello sdi danno errore:
org.apache.axis2.AxisFault: HTTP ( 500 ) Internal Server Error address : https://26.2.162.231:80
Quale certificato usa il client sdi per autenticarsi? occorre in qualche modo includere un certificato nella configurazione web.config del sito?
Se qualcuno ha risolto con IIS batta un colpo
Grazie mille
Buongiorno a tutti,
ho delle domande riguardo la produzione dei certificati pfx.
E’ corretto utilizzare il file caentrate.der nella creazione del file morecert.pem ?
Devo generare la chiavi private con convertendo i certificati in formato .pem?
Vi ringrazio per l’aiuto che eventualmente vorrete darmi.
Per quanto mi riguarda seguendo le istruzioni di Dario all’inizio della discussione ho risolto la parte client (chiamata verso web service sdi) e ho usato caentrate.der.
Ho problemi per la parte server, sdi che chiama nostro web service, non ho ancora trovato la soluzione.
Anche noi siamo impantanati nella fase di ricezione. Riusciamo ad inviare le fatture e per farlo usiamo solo il file .pfx che abbiamo generato direttamente da IIS usando i .cer che ci ha inviato SDI. Credo che sia equivalente alla procedura di Dario.
Il problema, come per Giulio e per altri, è la fase di ricezione, quando SDI deve richiamare il nostro web service per la ricezione delle fatture e delle notifiche.
In questo caso riceviamo sempre l’errore:
javax.net.ssl.SSLHandshakeException: General SSLEngine problem
Abbiamo fatto mille prove, ma ancora non ci è chiaro come configurare IIS e quali certificati utilizzare. Dall’assistenza ci hanno detto che, via browser il nostro web service dovrebbe richiedere il certificato da usare, come fa quello di SDI, ma non ci è chiaro come configurare il tutto.
Per chi è riuscito a ricevere le chiamate da SDI: che certificate utilizzate sul vostro server Apache o IIS?
Scusate, sono nuovo sto cercando di fare l’accreditamento, ed in attesa del certifiato server mi sto portando avanti con i passaggi. leggo che al punto 3 delle dritte di Dario che fa un copy /b, nn ho questo comando e non riesco a creare il file morecert.pem, avete idee? ho provato anche con cp (comando classico ma restituisce l’obbiettivo morecert.pem non è una directory. altra domanda la chiave poi da usare me la darà una volta avuto il certificato server?
il comando COPY è per windows. se non lo hai probabilmente stai usando linux. quindi il comando è CP
Il comando COPY comunque non fa altro che concatenare i vari certificati tra loro.
probabilmente lo puoi fare anche in manuale copiando il contenuto dei vari certificati in formato PEM
assicurandoti che ci sia un ritorno a capo tra un certificato e l’altro
NO
-----END CERTIFICATE----- -----BEGIN CERTIFICATE-----
SI
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
e che ci sia una riga vuota alla fine.
per la chiave penso tu intenda la chiave che hai usato per generare i file CSR
1 Mi Piace
Buongiorno, stavo provando a generare i file .pfx come mostrato da @dgbzerod, il mio problema è che non ho nessun file .key, il csr li ho generati direttamente da iis.
Come posso generare il file .key?
Grazie
Il File Key è quello che hai generato nella richiesta di accreditamento.
Recupera quei file e sei apposto.
Ciao Dario,
ho seguito le tue istruzioni ma sull’ultimo comando mi compare la scritta " No certificate matches private key". Sono sicuro di aver utilizzato la stessa key utilizzate per creare i files CSR .
Come posso risolvere ?
grazie
Buongiorno,
anche io ho lo stesso problema.
avete Risolto?
Mi accodo alla lista di combattenti.
Stiamo cercando di certificarci. L’invio fatture funziona, seguendo la nota procedura di produzione del PFX client, fra l’altro noi usiamo ASP .NET CORE che non supporta MTOM per cui abbiamo dovuto fare un accrocchio vergognoso. Ora lo SdI quando contatta il nostro endpoint TrasmissioneFatture ha problemi nella comunicazione SSL. Come e cosa si installa su IIS
come certificato? Abbiamo chiarissimo come imporre e validare il certificato client che SdI Usa per chiamarci, ma noi non capiamo come costruire il nostro certificato SERVER!
Vedo che molti sono già in produzione, sapete aiutarci?
Grazie mille
mi accodo anchio… qualcuno riesce a fornire una guida su come installare il ws su iis sopratutto quanto riguarda la gestione dei certificati (quali installare sul server e in che modo?)
Ciao @computerscenter ,
dopo un po’ di penare ce l’abbiamo fatta.
Abbiamo abbandonato l’idea di una web app di Azure, in quanto questa non consente l’installazione di una root certificate authority e quindi non consente l’esposizione di un certificato “custom” come quello che serve (il famoso SDI-01234567890-SERVER.PFX) . Sono stato tutta una notte con l’assistenza di Azure senza uscirne vivo. Abbiamo così usato IIS su una macchina virtuale.
Il servizio lo puoi fare come ASMX o come WCF, devi rispettare l’endpoint che hai messo nella richiesta ufficiale di accreditamento, se lo vuoi cambiare, devi rifare la richiesta da capo.
Io ti dico come abbiamo fatto con ASMX ma il passaggio verso WCF non è troppo dissimile.
I certificati: la macchina che ha IIS deve avere i due root cert necessari installati (caentrate.der e caentratetest.cer) e deve avere installato il certificato SDI-…-SERVER di cui sopra. Noi li abbiamo installati proprio a livello di macchina.
A questo punto in IIS devi fare alcuni passaggi.
Creare il sito e agire sui “Bindings”, associando al binding che metti (es. https://www.miosito.com/) una porta e un certificato e… guarda un po’, quel certificato è proprio SDI-…-SERVER in oggetto. Così chi ti chiama sa che parlerà con quel certificato lì. Se lo priovi da un browser esterno, di una macchina vergine, vedrai che la connessione non è sicura, perché la CA del certificato è l’agenzia delle entrate, che non è universalmente riconosciuta come autorità in grado di rilasciare certificati. Ma nelle chiamate dal SdI, va bene e anzi, è richiesto.
Però non ti basta. Devi andare in “impostazioni SSL” e dire che vuoi che le chiamate al tuo sito arrivino in HTTPS (Require SSL) e con certificato client: puoi scegliere se mettere Accept o Require, ti consiglierei di mettere Accept almeno finché sei in test, così puoi chiamare il tuo servizio anche senza certificato client. Loro, SdI, ti chiameranno sempre con un certificato client, del quale tu sai poco, ma quel poco che sai è fondamentale per la verifica della bontà della chiamata (che puoi fare a livello di global.asax o di arrivo chiamata nel WCF): hai infatti la parte pubblica del certificato client che loro useranno per chiamarti (SistemaInterscambioFatturaPATest.cer e SistemaInterscambioFatturaPA.cer) e puoi filtrare lato codice ogni chiamata verificando che la chiave pubblica corrisponda a quanto atteso. Noi, per non sbagliare, verifichiamo anche che il certificato sia stato emesso secondo alcuni criteri, tipo il soggetto, la ca, eccetera. Questo filtro lo puoi mettere anche in IIS direttamente, qualcuno qui sul forum ha fatto così, la soluzione impedirebbe il transito di richieste indesiderate verso il tuo codice, ma il filtro è un po’ più difficile da descrivere (specie se complesso) con gli strumenti di IIS.
Da lì in poi è tutto codice e fortuna di riuscire a riprodurre tutti i test utili a trasformare le crocette rosse in spunte verdi.
Se hai bisogno di spunti sul codice, scrivimi pure in privato. Vale anche per gli altri utenti, ovviamente.
Noi comunque ancora non siamo certificati: non abbiamo idea di come simulare un flusso verso la PA, a questo punto vado dalla direttrice delle elementari di mio figlio e le dico che in queste settimane le arriveranno una serie di fatture da 1 euro 
2 Mi Piace
Ciao a tutti.
Io riesco a inviare la fattura, ma SDI non chiama il servizio che io espongo, TrasmissioneFatture.
Nel dettaglio del messaggio, sulla pagina dei test di interoperabilità, si vede quest’errore:
org.apache.axis2.AxisFault: WSWS7092E: The HTTP(S) proxy information for the proxy connection was not received.
Non riesco a capire di quale proxy si tratta! A me sembra un errore lato loro. Qualcuno ha mai incontrato questo problema?
Qualsiasi aiuto sarebbe molto gradito. Grazie mille, Felix
Ciao a tutti,
dopo aver attivato un dominio di 3 terzo livello, fatto il binding con l’apposito certificato sdi-[Partita iva]-server e in impostazioni SSL selezionato “Richiedi SSL” selezionando “Accetta/Richiedi”, in fase di ricezione notifica scarto stiamo ricevendo il seguente errore:
org.apache.axis2.AxisFault: HTTP ( 403 ) Forbidden address : https://26.2.162.231:80.
Premetto che abbiamo installato i certificati forniti tra le radici attendibili e che da browser il tutto sembra funzionare regolarmente, cosa diavolo vuol dire quel messaggio di errore espresso in “linguaggio agenzia delle entrate”?
Grazie infinite per la collaborazione.
Ciao Colmar,
credo che l’errore si riferisca alla porta 80 indicata nell’URL. I servizi devono essere pubblicati sulla porta di default del protocollo HTTPS, che è la porta 443.
L’URL (e di conseguenza il servizio) dovrebbero quindi rispondere ad un indirizzo che non abbia la parte finale (:80).
s.
1 Mi Piace
Ciao, quello non è ne il nostro indirizzo ne il nostro protocollo.
I servizi li abbiamo pubblicati sul protocollo https e sul nostro ip pubblico.
Non sappiamo come mai si verifichi quest’errore.
Grazie per la collaborazione.