menu di navigazione del network

SDICOOP (canale web services) - Rinnovo Certificati

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 :wink:

1 Like

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: OK

ci sono diversi fatti da considerare:

  1. 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
    

  1. https://letsencrypt.org/2019/04/15/transitioning-to-isrg-root.html

Sapranno aggiornare un certificato di CA senza creare disservizi … è il loro lavoro :wink:

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 :wink:

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.

@faktiva.com grazie, almeno adesso mi è chiaro cosa stanno facendo.

1 Like

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 :slight_smile:

$ 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 X1

Scusate, 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…

Altra ricezione 12.54… comunque ho messo un log che logga il certificato con cui chiamano, appena arriva la prossima chiamata lo scrivo qui.

Sul canale slack c’è chi dice che le chiamate arrivano ancora con l’issuer “/C=IT/O=Agenzia delle Entrate/OU=Servizi Telematici/CN=CA Agenzia delle Entrate”, e che quindi ha riportato la configurazione a come era prima.

Anche io ho rimesso la configurazione originale e ignorato quindi ciò che veniva richiesto dalla PEC, poi farò qualcosa se vedrò fallire le chiamate.

Confermo ricevute altre tre chiamate, tutte con certificati
{0,"/C=IT/O=Agenzia delle Entrate/OU=Servizi Telematici/CN=Sistema Interscambio Fattura PA","/C=IT/O=Agenzia delle Entrate/OU=Servizi Telematici/CN=CA Agenzia delle Entrate"}

Ieri ho notato anche io quel “dal”, ma dopo aver verificato che l’IP da cui arrivano le chiamate NON corrisponde al dominio in questione ho dedotto che, invece di supporre che tutta la mail fosse una farneticazione, ci fosse solo una “D” di troppo e si dovesse leggere “chiamata effettuata AL Sistema di Interscambio

In base a https://crt.sh/?q=servizi.fatturapa.it dobbiamo attenderci che il certificato server per servizi.fatturapa.it, in sostituzione di quello in scadenza il prossimo 26 gennaio 2020, sarà rilasciato da Actalis anziché Let’s Encrypt?

Si … è appena arrivata la comunicazione

anche in questo caso non dovrebbe esserci nulla da fare se non erro.

Si, Actalis è nelle distro linux dal 2012, per esempio … suppongo che l’abbiano cambiata di nuovo per evitarsi problemi.

Forse la filosofia di Let’s Encrypt si adattava male alla loro infrastruttura. Let’s Encrypt prevede un aggiornamento frequente dei certificati (max 3 mesi), cosa che di fatto costringe ad automatizzare la cosa se non si vuole diventare matti. Può darsi che l’architettura della loro infrastruttura renda difficile l’aggiornamento e l’installazione automatica dei certificati e dopo averlo fatto a mano una volta, si sono resi conto che era meglio un certificato tradizionale.