Indice dei contenuti
Questo articolo è una piccola anticipazione di una guida molto più ampia, di prossima pubblicazione, nella quale spiegheremo come implementare il servizio SDICoop (modalità trasmissione e ricezione) per la connessione al Sistema di Interscambio (SdI) di Agenzia delle Entrate, superare il test di accreditamento e accedere alla fase di sperimentazione e, successivamente, di produzione.
Per il momento, ci limiteremo a pubblicare una breve guida che spiega come ottenere i certificati SSL da installare sul proprio web service per poter effettuare i test di accreditamento del servizio SDICoop.
Prima di continuare, ricordiamo una serie di articoli che abbiamo pubblicato in passato e che possono risultare utili a chiunque voglia approfondire il discorso relativo ai certificati SSL, alle loro tipologie di utilizzo principale e ai principali formati e standard ad oggi esistenti:
- Certificati SSL: come funzionano e perché sono importanti, che spiega il funzionamento dei certificati SSL e la loro utilità in termini di sicurezza.
- Certificati SSL: Standard, formati ed estensioni principali, che spiega il significato delle sigle relative ai vari formati: PEM, CER, CRT, DER, P7B, PFX, P12, etc.
- OpenSSL – Come convertire un certificato SSL e relativa chiave privata nei vari formati, che spiega l'utilizzo dello strumento OpenSSL - protagonista indiscusso anche di questa guida - per convertire i vari certificati nei vari formati discussi e spiegati nell'articolo precedente.
Introduzione
All'interno di questa guida ci riferiremo ai due certificati necessari per effettuare l'autenticazione con il software del Sistema di Interscambio, necessaria sia per poter inviare al SdI le nostre fatture e ricevute che per ricevere da SdI le fatture e ricevute a noi indirizzate:
- Il certificato CLIENT, ovvero quello necessario per autenticarsi ai Web Service del Sistema di Interscambio dal nostro client, il quale avrà il compito di trasmettere le nostre fatture e ricevute: i file necessari per la generazione e l'installazione di questo certificato avranno il nomefile con prefisso sdi-<PIVA>-client (dove <PIVA> è ovviamente la partita IVA della società che intende effettuare i test).
- Il certificato SERVER, ovvero quello che sarà utilizzato dal client del Sistema di Interscambio per autenticarsi al nostro Web Service e trasmettere le fatture e ricevute a noi dirette: i file necessari per la generazione e l'installazione di questo certificato avranno il nomefile con prefisso sdi-<PIVA>-server (dove <PIVA> è ovviamente la partita IVA della società che intende effettuare i test).
Non faremo invece distinzione tra i file da configurare nell'ambiente di test e quelli da configurare nell'ambiente di produzione: nel caso in cui il vostro sistema preveda l'utilizzo di due server distinti, sarà quindi necessario ripetere le operazioni per due volte: la prima per richiedere e installare i certificati necessari all'ambiente di test, la seconda per quelli relativi all'ambiente di produzione.
Per svolgere le attività elencate di seguito sarà necessario dotarsi di OpenSSL, uno strumento open-source che consente di effettuare una serie di operazioni di conversione sui vari formati dei certificati SSL: il tool è presente nativamente all'interno di tutte le principali distribuzioni Linux, mentre il porting per Windows (e altri OS) può essere scaricata gratuitamente da qui:
#1. Generare i file KEY
La prima cosa da fare è generare le chiavi RSA necessarie per crittografare i certificati.
1 2 |
> openssl genrsa -out sdi-<PIVA>-client.key 2048 > openssl genrsa -out sdi-<PIVA>-server.key 2048 |
#2. Creare i file CSR
Subito dopo potremo creare le Certificate Signing Request (CSR), necessarie per l'emissione dei certificati:
1 2 |
> openssl req -new -key sdi-<PIVA>-client.key -out sdi-<PIVA>-client.csr > openssl req -new -key sdi-<PIVA>-server.key -out sdi-<PIVA>-server.csr |
#3. Inviare i file CSR al SdI
Una volta pronti, i file CSR dovranno essere inviati ad Agenzia delle Entrate utilizzando la pagina di configurazione del canale SDICoop, così da completare il processo di richiesta accreditamento: al termine del processo, si otterranno i file .CER relativi ai CSR da noi inviati e il Kit di Test, contenente una serie di file relativi ai certificati CA (anch'essi in formato .CER).
Se vogliamo installare i file CER ricevuti da Agenzia Entrate su un Web Server IIS, sarà necessario effettuare alcune attività di conversione: per la precisione, da CER a PEM e poi da PEM al formato finale PFX/P12, che dovrà contenere anche la chiave e a tutti i certificati CA intermedi.
#4. Convertire i file CER in formato PEM
La prossima cosa da fare è convertire i file CER in formato PEM, operazione che può essere effettuata tramite le seguenti righe di comando:
1 2 |
> openssl x509 -inform der -in sdi-<PIVA>-client.cer -out sdi-<PIVA>-client.pem > openssl x509 -inform der -in sdi-<PIVA>-server.cer -out sdi-<PIVA>-server.pem |
#5. Creare il file dei certificati CA
Prima di poter procedere alla creazione del file PFX/P12 è necessario "accodare" i vari certificati intermedi inviati da Agenzia delle Entrate, così da poterli inserire all'interno del file di destinazione. Per far questo, è possibile utilizzare la funzionalità di binary copy fornita dal comando DOS copy con l'ausilio dell'opzione /b nel seguente modo:
1 |
copy /b caentrate.cer+CAEntratetest.cer+servizi.fatturapa.it+testservizi.fatturapa.it.pem+SistemaInterscambioFatturaPA.cer+SistemaInterscambioFatturaPATest.cer ca-all.pem |
Questa operazione provocherà la scrittura su disco di un nuovo file - denominato ca-all.pem - contenente la somma binaria di tutti i certificati intermedi.
#6. Verifica del file ca-all.pem
Il binary copy funziona piuttosto bene, ma è opportuno verificare il contenuto del file risultante per assicurarsi che i certificati ivi contenuti siano stati "accodati" correttamente. E' quindi opportuno aprire il file ca-all.pem appena creato con un editor di testo e assicurarsi che:
- Non vi siano righe che abbiano le diciture -----END CERTIFICATE----- e -----BEGIN CERTIFICATE----- sulla stessa riga: nel caso in cui ve ne fossero alcune, è importante separarle con una riga vuota.
- E' necessario che vi sia una riga vuota alla fine del file.
#7. Creare i file PFX/P12
A questo punto è finalmente possibile utilizzare i file PEM relativi ai nostri certificati (cfr. step #4), la chiave RSA generata all'inizio della procedura (cfr. step #1) e i file PEM relativi alla somma dei certificati intermedi (cfr. step #7), per creare un bundle completo in formato PFX/P12.
1 2 |
> openssl pkcs12 -export -out sdi-<PIVA>-client.pfx -inkey sdi-<PIVA>-client.key -in sdi-<PIVA>-client.pem -certfile ca-all.pem > openssl pkcs12 -export -out sdi-<PIVA>-server.pfx -inkey sdi-<PIVA>-server.key -in sdi-<PIVA>-server.pem -certfile ca-all.pem |
I file PFX/P12 così creati potranno essere così importati e configurati sul web server che dovrà comunicare al servizio SdI utilizzando la funzionalità "Importa Certificato" presente nello strumento di gestione di IIS, noto anche come IIS Manager.
Conclusioni
Per il momento è tutto: mi auguro che questa guida possa essere d'aiuto agli sviluppatori che hanno necessità di configurare il proprio sistema per poter effettuare i test di accreditamento previsti dal Sistema di Interscambio di Agenzia Entrate così da poter ricevere l'abilitazione del servizio SDICoop. Nei prossimi giorni pubblicheremo numerosi altri articoli sul tema, quindi... stay tuned!
Grazier per la guida. C’é un errore al punto 4: due volte client nella riga di comando, quando la seconda dovrebbe essere relativa al server.
Corretto: grazie per la segnalazione!
Buongiorno. Grazie per la guida. Segnalo un possibile refuso, nella parte iniziale al punto “Il certificato server”, quando viene indicato “avranno il nomefile con prefisso sdi–client” al posto di “client” va indicato “server”.
Grazie.
Fixato, grazie!
Buongiorno. Cortesemente, segnalo un altro possibile refuso, nella frase “La prossima cosa da fare è convertire i file CER in formato P7M” al posto di “P7M” indicare “PEM”. Grazie.
Fixato, grazie ancora :)
Buonasera,
ho un errore con il certificato server di produzione riemesso in quanto scaduto.
Seguendo la vostra guida nell’ultimo passaggio ho messo nel -certfile solo la CA che mi hanno dato insieme al nuovo certificato Server. Navigando sul indirizzo in https con firefox mi genera un errore “SEC_ERROR_UNKNOWN_ISSUER” eppure da server windows sembra tutto ok. Il certificato pfx è installato in Personal (della macchina locale) e la CA l’ho messa in Trusted Root Autority. Ho modificato anche il relativo binding su IIS . Qual è la catena giusta per i certificati in produzione ?
Salve,
anche noi ci siamo limitati ad aggiungere il file CAEntrate_prod.der allo Store “Trusted Root Certification Autorities” della macchina Windows ma non visualizziamo l’errore in oggetto. Ovviamente abbiamo anche la vecchia certificate chain di intermedi (quella riportata nella nostra guida), ma considerando che ormai quei certificati sono tutti scaduti non penso proprio che averla oppure no faccia alcuna differenza…
Hai provato a lanciare SigCheck per verificare se la chain è correttamente installata?
https://docs.microsoft.com/en-us/sysinternals/downloads/sigcheck?WT.mc_id=DT-MVP-5003202
Ti metto qui cosa dice a noi (sigcheck64 -tv):
Machine\CA:
CA Agenzia delle Entrate
Cert Status: Valid
Valid Usage: All
Cert Issuer: CA Agenzia delle Entrate
Algorithm: sha256RSA
Valid from: 15:53 06/12/2018
Valid to: 15:53 01/12/2038
Machine\MY:
SDI-05191920874
Cert Status: Valid
Valid Usage: Server Auth
Cert Issuer: CA Agenzia delle Entrate
Algorithm: sha256RSA
Valid from: 09:21 27/04/2021
Valid to: 09:21 26/04/2024
Machine\ROOT:
CA Agenzia delle Entrate
Cert Status: Valid
Valid Usage: All
Cert Issuer: CA Agenzia delle Entrate
Algorithm: sha256RSA
Valid from: 15:53 06/12/2018
Valid to: 15:53 01/12/2038
Buon giorno,
ho seguito l’intera procedura riuscendo a generare il file .pfx che ho poi importato con successo nel server (in MMC).
Tuttavia, quando tento l’importazione in IIS10 viene restituito errore con il seguente messaggio: “Impossibile utilizzare il certificato come certificato del server SSL”.
Potete aiutarmi a risolvere il problema?
Consigliamo di NON utilizzare MMC ma la funzionalità “Server Certificates” presente all’interno di IIS Manager, appositamente pensata per l’importazione di certificati PFX a uso HTTPS/TLS.