menomale che hanno dato un ampio preavviso e che i file sono esattamente gli stessi, così fare le modifiche è un attimo 
Qualcuno ha un’idea di come usare DST.pem e Intermediate.der?
Se per validare il certificato di servizi il tuo software usa le facility del sistema operativo allora devi controllare se quella CA è riconosciuta (basta provare a vedere se il certificato di servizi viene validato). Se non è riconosciuta devi aggiungerla (basta la CA cioè DST) a quelle riconosciute dal S.O…
Se invece usi un insieme di certificati di trust apposito allora devi aggiungere quei due al trust.
1 Mi Piace
ho configurato apache seguendo le varie guide e le CA venivano aggiunte direttamente nella configurazione del virtual host.
Sono perplesso: ho provato a validare il file con openssl verify servizi.fatturapa.it.pem (il cer non lo riconosceva) ma restituisce verification failed 
ma lo stesso succede specificando -CApath e -CAfile (e ovviamente indicando rispettivamente il path della cartella coi certificati nuovi e il DST.pem) Non dovrebbe validarmeli specificando le CA? (sui certificati sono un novellino, sorry!)
Comunque dal punto di vista di apache dovrebbe bastare usare DST.pem come SSLCACertificateFile e la concatenazione delle due CA su SSLCertificateChainFile, no?
Grazie 
P.s. mi viene in mente un’altra cosa: se aggiungo le due CA direttamente alle facility dell’OS, in teoria la configurazione di apache sulle CA dovrebbe diventare inutile, o sbaglio?
Non sono certificati per il tuo server (apache o NGINX), ma sono loro che hanno cambiato i loro certificati sul loro server.
Quei file nel 90% dei casi non servono a nulla … si può semplicemente NON FARE NULLA.
Nel caso in cui invece il tuo CLIENT che fa richieste a servizi.fatturapa.it abbia bisogno di una configurazione custom OPPURE il sistema operativo non ha già installato il certificato della root CA (DST) allora dovrai aggiungerlo o passarlo al client come parametro nel modo opportuno.
Verifica che il DST sia installato nel sistema operativo.
Il check più semplice che possiamo fare è una CURL da linea di comando al sito di test di Let’s Encrypt, che ha la stessa identica chain che avrà domani il sito dello SDI:
curl -iLs -D - -o /dev/null https://helloworld.letsencrypt.org/
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 07 Nov 2019 17:50:47 GMT
Content-Type: text/html
Content-Length: 5313
Se questa chiamata non va in errore allora al 99,99% non bisogna fare nulla di nulla.
1 Mi Piace
Ciao Emiliano
Giusto per conferma… nel caso in cui ho un’applicazione client dove sono io a configurareun un truststore con in certificati per la connessione SSL dovrò aggiornalo aggiungendo anche questi nuovi certificati … giusto ?? E la parte server dove io espongo i web service invocati dal SDI ?? anche li devo configurare il nuovo certificato CA che mi consente di autenticare il SDI… Giusto ???
Da quanto ho capito io il cambiamento interessa solo il loro server, come erogatore di servizio cioè quando tu fai connessioni a loro e non viceversa.
Quindi sono abbastanza certo che nessuna modifica vada fatta su alcuna infrastruttura server lato nostro (utenti).
Per la parte client si devi assicurarti che il tuo truststore contenga il certificato della nuova root CA (DST Root CA) in modo tale che il tuo SW client sia in grado di verificare il nuovo certificato dello SDI domani. Il test che puoi fare è sempre quello verso helloworld.letsencrypt.org perché usa la stessa “intermediate CA” che useranno loro domani (Let’s Encrypt Authority X3)
Il fatto che il certificato del loro server scada ogni 3 mesi è solo una maggiore sicurezza e non causa alcun problema.
Oggi abbiamo il problema perché c’è un passaggio di root CA (per di più da una root diretta ad una con intermediate di mezzo) … ma una volta fatte le eventuali modifiche il cambio anche ogni ora del cert sul server sarà trasparente ai client (a noi).
Per una volta non è un prob “all’italiana” 
Sulla parte client provvedo … Per quanto riguarda la parte server loro nella pec di oggi pomeriggio mi dicono
"Si ricorda che non occorre richiedere alcun rinnovo di certificati perché la sostituzione riguarda il Sistema di Interscambio e che il secondo certificato non deve essere usato se non è necessario effettuare riconoscimento puntuale della chiamata del SdI.
Saluti
Segreteria Tecnica SDI"
Il nostro http server apache è configurato per accettare client certificate rilascia dalla CA precedente (CA Entrate) … questo da domani non andrà più bene ??? Inoltre vorrei chiedere a tutti se la comunicazione di tale modifica l’avete avuta oggi pomeriggio con scadenza domani … Ciao Grazie
Le loro chiamate ai nostri endpoint non avranno modifiche. Ovviamente questo è quanto ho capito e fatto io sui miei sistemi (dopo un paio di ore di verifiche tecniche e lessicali ;))
Peccato che la root scade a settembre 2021 (la precedente nel 2028). Quindi a meno di auto-aggiornamenti, anche tutti quelli che fanno riferimento al sistema operativo o eventuale toolkit / framework avranno comunque il problema nel 2021.
E anche chi usa direttamente il certificato su un trust apposito dovrà stare attento alla scadenza ravvicinata del certificato di servizi.
Da un ente “nazionale” mi sarei aspettato una visione un po’ più ampia.
Ho fatto il controllo che dicevi ed è andato tutto liscio! Tengo d’occhio la situazione giusto per sicurezza, ma visto quanto detto dovremmo essere apposto!
Grazie mille per la spiegazione
1 Mi Piace
Hanno appena effettuato il cambiamento:
$ openssl s_client -connect servizi.fatturapa.it:443 | grep ^Verification
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = servizi.fatturapa.it
verify return:1
Verification: OKci sono diversi fatti da considerare:
-
La intermediate di Let’s Enccrypt è cross signed anche da
ISRG Root X1, che è già largamente supportata.$ trust list | grep ISRG label: ISRG Root X1
Sapranno aggiornare un certificato di CA senza creare disservizi … è il loro lavoro
Non mi è chiaro se noi dobbiamo fare qualcosa.
Nel mio caso, su Apache ho questa configurazione:
SSLEngine On
# certificato firmato dall'Agenzia (fompato ASCII/PEM)
SSLCertificateFile "/app/srv-sdi/CERT/sdi/SDI-XXXXXXXXX-Server.pem"
# chiave privata usata per generare la richiesta di certificato
SSLCertificateKeyFile "/app/srv-sdi/CERT/sdi/key_sdi.key"
# certificato dell’autorità di certificatione dell’agenzia
SSLCertificateChainFile "/app/srv-sdi/CERT/sdi/caentrate.der"
# concatenazione del certificato dell'autorità di certificazione dell'agenzia
# più il certificato dell’autorità di certificazione di test (caentrate.der + CAEntrateTest.der).
# In questo modo lo stesso server accetta le chiamate sia dal servizio di test che dal servizio di produzione
SSLCACertificateFile "/app/srv-sdi/CERT/sdi/CA_Agenzia_delle_Entrate_all.pem"
SSLStrictSNIVHostCheck off
dove caentrate.der e CAEntrateTest.der ci sono stati forniti dallo SDI al momento dell’attivazione del nostro SDI-COOP.
A me sembra che nel mio caso non devo far nulla… Che dite?
che se leggi il tread abbiamo già risposto 
Per carità non vorrei incaponirmi su sta cosa…
Ma da come hanno mandato la mail, con i certificati della root, della intermediate ecc… sembra fatto per chi ha un suo trust apposito dove carica i vari certificati.
E in questo caso le scadenze corte sono un problema.
Potevano invece dire “fate in modo che il vostro software usi il trust del sistema operativo / toolkit e assicuratevi che ISRG o DST siano riconosciute”. Questo chiaramente con un po’ di anticipo rispetto alla scadenza… invece la mail arriva 3 gg prima della scadenza e richiede di caricare nuove CA se uno ha il suo trust.
Ecco l’italianata… come i seggiolini per bimbi obbligatori dal giorno dopo e senza che i produttori abbiano avuto il tempo di adeguarsi alle specifiche tecniche… e giù tutti di notte a ordinare i cuscini online (noi abbiamo un sito di e-commerce, non avete idea di quante richieste sono arrivate tra il 6 pomeriggio e il 7 mattina), cuscini che poi magari non sono nemmeno a norma!
Comunque il fatto che usino un ente non commerciale per i certificati è anche una buona idea… andava gestito tutto un po’ meglio secondo me, tutto qua.
Si sono d’accordo sulla gestione di questo case alla carlona (volendo essere buoni e gentili).
Comunque ISRG scade nel 2035, non credo vi sarà alcun problema coi cert in futuro… LE non è italiano ehehhe 
$ openssl x509 -text -in /etc/ssl/certs/ISRG_Root_X1.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
82:10:cf:b0:d2:40:e3:59:44:63:e0:bb:63:82:8b:00
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = Internet Security Research Group, CN = ISRG Root X1
Validity
Not Before: Jun 4 11:04:38 2015 GMT
Not After : Jun 4 11:04:38 2035 GMT
Subject: C = US, O = Internet Security Research Group, CN = ISRG Root X1Scusate, ma la PEC che ho ricevuto dice:
I certificati in allegato servono per:
- DST.pem e intermediate.der: per verificare la validità della chiamata effettuata DAL Sistema di Interscambio con il nuovo certificato (sono i certificati di CA del nuovo certificato);
Quindi il testo dice inequivocabilmente che quei due certificati (letsencrypt e la sua CA) servono per fare l’autorizzazione del client quando riceviamo una fattura o uno stato tramissione.
Da quello che leggo qui sopra invece mi state dicendo che semplicemente loro hanno cambiato CA per i certificati del loro SERVER (non client) e quindi, a meno che nelle nostre chiamate (e non nel nostro SERVER) non avessimo dei check sulla CA non dobbiamo fare nulla.
Ma è possibile che l’email l’abbia scritta qualcuno che non aveva idea di cosa fosse necessario fare? Se è così perchè non ci mandano semplicemente una email di “errata” rispetto a ciò che ci hanno detto?
Io seguendo l’email avevo messo quei due certificati come SSLCACertificateFile ma la cosa non ha alcun senso visto che così facendo si perde l’autenticazione (chiunque abbia un certificato letsencrypt può ora inviarmi fatture al posto dello SdI).
In effetti leggendo bene la mail sembra come dici tu… Io ho visto ‘servizi.fatturapa.it’ e visto che quel certificato scadeva il giorno 10/11 ho associato la cosa.
Le chiamate che arrivano ai “nostri” end-point io le ho sempre validate con la CA dell’agenzia entrate che ci hanno dato in accreditamento (CA che scade a marzo 2021, con certificato SistemaInterscambioFatturaPA ad oggi già scaduto). E finora ho sempre ricevuto tutto (ultima connessione oggi 11.54).
Mi auguro che non abbiano cambiato questo altrimenti è un bel problema…