Certificati pubblici SDI non funzionanti

Fatturazione Elettronica
1

Buongiorno a tutti,
abbiamo sviluppato un web service per l’invio e la ricezione di fatture elettroniche. Abbiamo già accreditato un canale, effettuando tutti i test per il passaggio in produzione con successo.

Una volta in produzione, però, abbiamo riscontrato problemi nell’accesso ai servizi esposti dal SDI.

Il certificato client di test, con il quale riuscivamo ad autenticarci con successo ai servizi di test (testservizi.fatturapa.it), era costituito dal certificato CAEntrateTest (già fornito con il Kit di Test) concatenato al nostro certificato SDI-xxxxxxxxxx (sempre fornito da SDI in seguito alla richiesta di accreditamento).

In seguito al passaggio in produzione, abbiamo sostituto il certificato client con un certificato generato seguendo la medesima procedura usata per generare quello di test, con l’unica differenza che abbiamo sostituito il certificato CAEntreateTest con il certificato CAEntrate (già presente nel Kit di Test), concatenato sempre allo stesso nostro certificato SDI-xxxxxxxxxx.

Fatta eccezione per tale certificato e chiaramente per l’endpoint utilizzato (servizi.fatturapa.it), non abbiamo effettuato alcun altra modifica alle modalità di accesso ai servizi SDI, correttamente funzionanti in fase di test.

Tuttavia il tentativo di accedere ai sistemi SDI (in questo caso all’endpoint ricevi_file) con il certificato di produzione, fallisce sempre con errore 403 Forbidden, il quale chiaramente sembrerebbe suggerire un problema con i certificati client.

Vi è capitato qualcosa di simile? avete qualche suggerimento da darci? abbiamo usato i certificati client/server corretti da utilizzare in produzione? o potete suggerirci altre possibili cause del problema?

ps. aggiungo che testando il tutto direttamente con openSSL otteniamo la stessa risposta:

HTTP/1.1 403 Forbidden
Date: Thu, 06 Dec 2018 08:46:33 GMT
Content-Length: 13
Keep-Alive: timeout=10, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

403 Forbidden

ringraziamo tutti in anticipo per chiunque vorrà darci un suggerimento gradito.
Claudio C.

2

Il certificato client che vi hanno fornito è firmato col certificato CA in caeentrate.der, non quello in CAEntratetest.cer, quindi semmai non vi doveva funzionare in ambiente di test.
Noi, lavorando con .NET, abbiamo creato un file .pfx contenente il certificato client fornitoci, il certificato CA in caentrate.der e la nostra chiave privata. Con questo ci siamo autenticati sia sui server di test che quelli di produzione.

Ora ho provato anche con openssl e con questi parametri riesco ad autenticarmi:
openssl s_client -connect servizi.fatturapa.it:443 -CAfile caentrate.der -cert SDI-9999999999-client.pem -key SDI-99999999999.key

dove SDI-9999999999-client.pem è il nostro certificato client (in formato pem) e SDI-99999999999.key è la corrispondente chiave privata.

3

Grazie per la celere risposta.

Sì confermiamo, il certificato client SDI-xxxxxxxxxx in nostro possesso è firmato con il certificato di produzione caeentrate.der. Tuttavia in ambiente di test utilizzavamo un file .pfx contenente lo STESSO certificato SDI-xxxxxxxxxx e il certificato CAEntratetest.cer. Effettivamente i due certificati non hanno nulla a che vedere l’uno con l’altro, ma per quanto assurdo possa sembrare, siamo comunque riusciti a completare la fase di test con questa configurazione.

Si tratta esattamente della procedura che abbiamo seguito anche noi, usiamo anche noi .NET (WCF su .NET Framework 4.6.1).

Il vs comando openSSL è identico a quello che abbiamo provato noi. Nel nostro caso, tuttavia, inviando una richiesta SOAP completa all’endpoint ricevi_file, riceviamo errore 403 Forbidden.

Avete qualche suggerimento ulteriore?
grazie ancora
Claudio C.

4

Cosa succede se provi a scaricare il wsdl con il browser.
Usando Firefox, se inserisco l’url https://servizi.fatturapa.it/ricevi_file?wsdl mi dà errore 403.
Se però installo in Firefox il certificato client (lo stesso .pfx che usiamo nel programma), riesco a scaricarlo (fa un redirect ad un altro url, ma non dà più l’errore 403).

5

Questa prova è interessante.
Abbiamo fatto quanto da te gentilmente descritto, usando lo stesso .pfx che usiamo nel programma e nei test con openSSL, installato su Firefox ovviamente, ed effettivamente…. funziona. Ovvero, si autentica sull’endpoint e compare a video il wsdl. Niente più errore 403 forbidden….

A questo punto ci vengono altri dubbi. Il problema potrebbe essere nel contenuto della richiesta SOAP che mandiamo (nella fattispecie una fattura xml che tentiamo di inviare in produzione). Possibile?.. ma perché dovrebbe generare un 403 forbidden?.. Qualche suggerimento?

nel frattempo, infinite grazie per l’aiuto.
Claudio C.

6

Purtroppo non ho altre idee. L’unica cosa che mi viene in mente è che stiate usando l’url sbagliato per l’endpoint. Se ci sono problemi con la fattura, vi manda una notifica di scarto, non un errore 403. E anche se fossero sbagliati i parametri della richeista SOAP, vi darebbe un errore SOAP, non un errore HTTP 403.
Noi per il passaggio in produzione abbiamo solo cambiato gli url degli endpoint. Tutto il resto (codice generato da svcutil, binding e certificato) è rimasto uguale.

7

Vladan,
molte grazie per il tempo che ci hai dedicato e per le tue indicazioni.
Sono state comunque preziose perché ci hanno guidato alla fine ad analizzare meglio il tutto e a identificare l’errore, che solo ora possiamo dire, ovviamente, non aver nulla a che fare con i certificati.
Se può essere utile, l’errore era legato ad uno “slash” di troppo alla fine della URL dell’endpoint contattato.
Ora siamo riusciti a terminare il tutto e a passare effettivamente in produzione.

ancora grazie
Claudio C.