30 Settembre 2021

Let’s Encrypt DST Root CA X3 scaduto. Cosa fare per i vecchi dispositivi e i siti web ?

Un certificato root scaduto potrebbe causare problemi di accesso al Web per i vecchi dispositivi

Condividi su facebook
Condividi su twitter
Condividi su linkedin
Condividi su whatsapp
Condividi su email
Print Friendly, PDF & Email

Non è l’apocalisse dei dispositivi elettronici ma alcuni prodotti potrebbero visualizzare messaggi di errore da giovedì. In questione: la scadenza di un certificato di sicurezza digitale Let’s Encrypt  prevista per il 30 settembre 2021 alle 16:01.

 

Questo file, chiamato “IdentTrust DST Root CA X3”, è un certificato radice di Let’s Encrypt CA, un’organizzazione senza scopo di lucro che ha contribuito a democratizzare gratuitamente la crittografia di Internet per diversi anni. Sta per uscire dopo vent’anni di protezione delle connessioni tra dispositivi e siti web.

La conseguenza è che alla fine del mese, alcuni dispositivi avranno difficoltà ad accedere a Internet. Potresti visualizzare messaggi di errore che indicano che la connessione non è sicura. Tuttavia, gli utenti non saranno privati di Internet. Così come navigando con un browser obsoleto o su una pagina non sicura dovrebbero poter forzare la connessione scegliendo di non fidarsi del certificato, utilizzando il browser Firefox, che emette i propri certificati, oppure aggiornando il proprio sistema.

Questa situazione tuttavia non dovrebbe interessare un gran numero di persone.

Come sottolinea Scott Helme, il ricercatore di sicurezza che ha evidenziato questo evento sul suo blog, solo i dispositivi più vecchi ancora in circolazione sono minacciati. In Apple, sono presi di mira iPhone che non vengono aggiornati da cinque anni e non sono ancora stati aggiornati a iOS 10. Tutti i modelli avviati da iPhone 5 possono migrare a questa versione per correggere il problema.

È probabile che gli utenti di dispositivi meno recenti riscontrino problemi sul Web a partire da oggi, 30 settembre, alle 16:01. La scadenza di un certificato radice impedirà infatti a quasi tutti i browser di caricare siti Web su questi terminali. I vecchi iPhone e Mac sono potenzialmente interessati.

Prima di tutto, dovresti sapere che per la stragrande maggioranza degli utenti di Internet, questo 30 settembre sarà un giovedì come un altro. Coloro che possiedono un Mac con MacOS 10.12.1 (Sierra) e versioni successive, così come coloro che hanno un iPhone oltre iOS 10 (iPhone 5 può ospitare questa versione) saranno risparmiati, così come gli utenti Android 7.1.11 e versioni successive, come così come quelli che eseguono Windows XP SP3 e versioni successive.

Ciò significa che gli utenti di prodotti con versioni precedenti dei loro sistemi operativi avranno problemi su Internet da domani. Per i Mac, è sempre possibile modificare il certificato “a mano”, dall’applicazione Accesso Portachiavi. È necessario sostituire l’IdentTrust DST Root CA X3 con l’ISRG Root X1, fornito da Let’s Encrypt, la cui data di validità è fino al 2035. Ulteriori informazioni tecniche sono disponibili sul sito OpenSSL.

Un’altra soluzione: utilizzare Firefox che viene fornito con un proprio elenco di certificati di root, ricorda Let’s Encrypt. Per tutti gli altri dispositivi, non ci saranno problemi se vengono aggiornati regolarmente.

 

C’è un lungo retroscena

Sembra una presa spudorata, ma se vuoi davvero saperne di più su come funzionano le autorità di certificazione (CA) e le catene di certificati, dovresti considerare di unirti a me nel corso di formazione pratico TLS e PKI che offro e che è stato creato da Ivan Ristic , il creatore di SSL Labs e autore di Bulletproof SSL e TLS . Per tutti gli altri, questo post sul blog e i dettagli a cui mi collegherò dovrebbero essere sufficienti per capire cosa accadrà e perché.

In definitiva, tutti i certificati che alimentano HTTPS sul Web sono emessi da una CA, un’organizzazione affidabile riconosciuta dal tuo dispositivo/sistema operativo. Qui puoi vedere l’elenco delle “Autorità di certificazione radice attendibili” sul mio attuale dispositivo Windows 10:

Questi certificati sono integrati nel tuo sistema operativo e vengono generalmente aggiornati come parte del normale processo di aggiornamento del tuo sistema operativo. Il certificato qui che causerà un problema è questo, IdenTrust DST Root CA X3.

Come puoi vedere, il tempo stringe e ci stiamo avvicinando alla data di scadenza del 30 settembre 2021 ma non è solo una data di scadenza, è un timestamp di scadenza che chiamiamo notAfter:

Questo viene convertito in BST per me, ma se analizzo il certificato utilizzando OpenSSL X509 puoi vedere il timestamp UTC per la scadenza:

Questo ci dà un tempo abbastanza specifico per la scadenza di questo certificato:

Validity
            Not Before: Sep 30 21:12:19 2000 GMT
            Not After : Sep 30 14:01:15 2021 GMT

Una volta scaduta questa CA radice, i client, come i browser Web, non riterranno più attendibili i certificati emessi da questa CA.

Il problema riguarda in linea di massima dispositivi non aggiornati per cinque anni

Sopra Android, i dispositivi interessati sono quelli che non hanno il versione 7.1 sistema, lanciato anche cinque anni fa. Ma un accordo firmato tra Google e un’autorità di certificazione consentirà ad alcuni dispositivi ancora più vecchi di poter utilizzare il certificato. I dispositivi lanciati dieci anni fa dovrebbero continuare a funzionare normalmente, secondo Let’s Encrypt. Poiché il ciclo di rinnovo dello smartphone oscilla tra i due e i cinque anni, a seconda del mercato, giovedì la stragrande maggioranza degli utenti non vedrà alcun cambiamento.

Oltre agli smartphone, la scadenza del certificato potrebbe causare problemi alle persone che stanno ancora giocando alle versioni del PS4 che non sono stati aggiornati dalla versione 5 del loro firmware, lanciata alla fine del 2017. Utenti di Mac che non sono stati aggiornati da macOS 10.12.1 e PC anche con Windows XP Service Pack 3 sono interessati.

Alla fine, troviamo qui principalmente macchine che non sono state aggiornate da almeno cinque anni, il che limita notevolmente la portata dell’evento.

Let’s Encrypt nel frattempi è diventato popolare

Solo nell’ultimo anno, Let’s Encrypt ha aumentato notevolmente la propria quota di mercato e man mano che una CA diventa più grande, i suoi certificati consentono a una parte maggiore del Web di operare e, di conseguenza, quando accade qualcosa del genere, hanno il potenziale per causare più i problemi. Questo non ha nulla a che fare con ciò che Let’s Encrypt ha fatto o non ha fatto, ma si tratta comunque dello stesso problema di fondo che i dispositivi nell’ecosistema non vengono aggiornati come dovrebbero.

 

 

Data la differenza di dimensione relativa tra Let’s Encrypt e AddTrust, ho la sensazione che la scadenza della radice di IdenTrust abbia il potenziale per causare più problemi. Nessuno sa davvero quanto potrebbe essere un problema, potrebbe avere conseguenze simili alla scadenza di AddTrust, o potrebbero esserci delle circostanze impreviste e potrebbe essere molto peggio, la tua ipotesi è buona quanto la mia.

Cosa sta facendo Let’s Encrypt al riguardo?

Come ho detto sopra, questo problema non si verifica a causa di qualcosa che Let’s Encrypt ha o non ha fatto, sta accadendo perché tutti i certificati alla fine scadono e se i dispositivi non vengono aggiornati, non riceveranno i nuovi certificati sostitutivi. Detto questo, Let’s Encrypt non si è seduto a girare i pollici mentre si avvicinava la data di scadenza, ha lavorato duramente cercando di trovare una soluzione.

Nell’aprile 2019  Let’s Encrypt propose di passare a ISRG root , dove Let’s Encrypt aveva pianificato di spostarsi dalla radice IdenTrust alla propria radice, ISRG Root X1, che scade il 4 giugno 2035, dandoci un bel numero di anni. Il problema era che non molti dispositivi avevano ricevuto gli aggiornamenti necessari che includono questo nuovo ISRG Root X1, rilasciato 4 anni prima nel 2015! Se un’ampia selezione di dispositivi non ha ricevuto un aggiornamento per includere questo nuovo certificato radice, semplicemente non si fiderà di esso. Questo è fondamentalmente lo stesso problema che stiamo riscontrando ora con la scadenza del root IdenTrust, perché i dispositivi client non sono stati aggiornati, e non hanno nemmeno ricevuto il nuovo ISRG Root X1. La transizione è stata rinviata.

A settembre 2020 Let’s Encrypt aveva nuovamente posticipato la transizione. Hanno citato le seguenti preoccupazioni:

A causa delle preoccupazioni per un’insufficiente propagazione della radice ISRG sui dispositivi Android, abbiamo deciso di spostare la data in cui inizieremo a servire una catena alla nostra radice all’11 gennaio 2021.

 

Questo si traduce vagamente in dispositivi Android che non hanno ricevuto un aggiornamento per oltre 4 anni, il che significa che quei dispositivi non avevano ancora ricevuto ISRG Root X1, il che significa che non si fidavano di esso. Let’s Encrypt non può passare all’emissione dalla nuova radice, ma la radice IdenTrust ha ancora 1 anno di vita e il tempo stringe davvero.

Alla fine, è successo qualcosa di un po’ inaspettato che potrebbe solo ridurre il grave impatto di questo evento e renderlo un po’ più appetibile. Poiché i vecchi dispositivi Android non controllano la data di scadenza di un certificato radice quando lo utilizzano, Let’s Encrypt potrebbe essere in grado di continuare a concatenare il certificato radice scaduto senza alcun problema su quei dispositivi meno recenti. Ciò introduce una certa complessità in futuro, ma alla fine l’obiettivo è estendere la compatibilità dei dispositivi Android per i certificati Let’s Encrypt .

Perché questo funzioni, Let’s Encrypt ha dovuto ottenere un segno incrociato per il proprio certificato ISRG Root X1 dalla IdenTrust DST Root CA X3 in scadenza, ma ciò non sarebbe stato di alcun aiuto a meno che la radice con segno incrociato non fosse valida più a lungo del radice della firma, che è. Il nuovo certificato ISRG Root X1 è valido più a lungo dell’IdenTrust DST Root CA X3 che lo ha firmato!

Questa pagina dei documenti di Let’s Encrypt contiene un elenco di client che si fidano solo del certificato IdenTrust DST Root CA X3 e successivamente c’è l’elenco delle piattaforme che si fidano di ISRG Root X1. Ho unito questi due elenchi per produrre il seguente elenco di client che si interromperanno dopo la scadenza di IdenTrust DST Root CA X3.

  • OpenSSL <= 1.0.2
  • Windows < XP SP3
  • macOS < 10.12.1
  • iOS < 10 (iPhone 5 è il modello più basso che può arrivare a iOS 10)
  • Android < 7.1.1 (ma >= 2.3.6 funzionerà se servito ISRG Root X1 cross-sign)
  • Mozilla Firefox < 50
  • Ubuntu < 16.04
  • Debian < 8
  • Java 8 < 8u141
  • Java 7 < 7u151
  • NSS < 3,26
  • Amazon FireOS (browser di seta)

Le piattaforme di cui non sono ancora sicuro e che avranno bisogno di ulteriori indagini per vedere se falliranno dopo la scadenza di IdenTrust DST Root CA X3 sono:

  • Cyanogen > v10
  • Sistema operativo Jolla Sailfish > v1.1.2.16
  • Kindle > v3.4.1
  • Mora >= 10.3.3
  • Console di gioco PS4 con firmware >= 5.00
  • IIS

La risposta alla domanda “cosa succederà alla scadenza della radice IdenTrust?” dipende da quanto sono diffuse le tipologie di clienti sopra elencate. Non so cosa stia circolando là fuori sul Web, e non so nemmeno cosa dipenda da queste cose. Una cosa che so, però, è che almeno qualcosa, da qualche parte, si romperà.

Quali problemi per gli Hosting Provider derivati dalla scadenza della DST Root CA X3 Let’s Encrypt ?

Sicuramente il problema non è passato inosservato considerando le decine e decine di telefonate che già dalle 16 del 30 Settembre ci hanno preso d’assalto il sistema di Ticketing online e il supporto telefonico.

Alcuni utenti con dispositivi non aggiornati come qualche Mac OS Yosemite e qualche Chrome che usavano hanno sin da subito lamentato l’errore del certificato scaduto che si presentava nel tentar di raggiungere i siti che adottavano i certificati gratuiti di Let’s Encrypt.

Abbiamo avuto difficoltà nel mettere a fuoco subito la problematica e riuscire ad argomentare prontamente sia il motivo di ciò che la relativa soluzione.

Tuttavia non è stato l’unico problema.

Quello apparentemente più ostico riguardava infatti alcuni siti Web che adottavano client SMTP e che utilizzavano il protocollo SSL o TLS per l’inoltro della posta in uscita a server mail che utilizzavano certificati SSL di Let’s Encrypt.

Immaginiamo quelle classiche form web che una volta compilate e premuto il tasto “Invia” si adoperano di inviare un messaggio mail ad un indirizzo. Normalmente sfruttano la libreria PHP PHPMailer, che incontrando un certificato SSL scaduto rifiutava la connessione evitando l’inoltro della mail in uscita verso il mail server configurato.

Nei sistemi più moderni come RedHat RHEL 7 e successive che adoperiamo in azienda è bastato tuttavia aggiornare i certificati delle Certification Authority lanciando il comando :

yum update ca-certificates

Esso ha permesso di aggiornare all’ultima release la lista delle Certification Authority che escludevano logicamente la CA X3 di Let’s Encrypt scaduta.

Per i sistemi più obsoleti ormai in EOL da diverso tempo (End Of Life) abbiamo dovuto invece mettere in blacklist la CA scaduta per evitare di negoziare con un certificato non più utile ormai.

Quale soluzioni per i possessori di MacOS per l’errore di certificato ?

net error Mac OS

La soluzione unica per le vecchie versioni di MacOS, è quella di aggiornare il sistema operativo almeno alla release El Captain.

Alternativamente si può installare Firefox browser che come abbiamo già detto utilizza le CA memorizzate nell’installazione del browser e NON quelle del sistema operativo.

 

Quale soluzione per gli Hosting Provider e per i siti internet ?

Se hai un sito Web e vuoi mantenere la compatibilità con questi vecchi dispositivi, il miglior consiglio che possiamo darti è quello di passare ad un certificato SSL DV Domain validated commerciale come Comodo, Verisign, RAPIDSSL.

Ad esempio noi di Managedserver.it in ottica di fornitori di Hosting provider e di servizi mail con i relativi protocolli sicuri e crittografati tra i quali :

SMTP AUTH: Port 25 o 587
SMTP SSL: Port 465
SMTP StartTLS: Port 587
POP3: Port 110
IMAP: Port 143
IMAP SSL: Port 993
IMAP StartTLS: Port 143

abbiamo decido di affidarsi ad un rapido ed economico quanto robusto e compatibile Positive SSL della Comodo comprato per due anni ad appena circa 5 dollari annui su SSLS.COM

Il costo in se è davvero contenuto se si lavora su un singolo dominio, tuttavia la procedura di installazione su Webserver e sopratutto SMTP Server e IMAP e POP3 Server potrebbe essere non proprio alla portata di tutti soprattutto se alle prime armi magari con un pannello di controllo amatoriale come Plesk o cPanel di cui abbiamo ampiamente parlato (male) se adottato in ambienti professionali.

Tuttavia parliamo di un certificato commerciale che seppur estremamente economico potrebbe non essere la soluzione ideale (o semplicemente quella voluta), che richiede un certo dispendio di tempo, denaro ed energie per :

  1. Comprare il certificato SSL online e pagarlo.
  2. Generare il CSR per poter successivamente generare il certificato (normalmente tramite la utility openssl)
  3. Verificare la proprietà del dominio tramite DNS o tramite ricezione mail ad indirizzi del tipo admin@nomedominio.it
  4. Aspettare la validazione e la mail con il certificato
  5. Installarlo e configurarlo.

Una serie di operazioni insomma che richiedono nella migliore delle ipotesi almeno 30 minuti per singolo dominio. Se si vuol operare su grossi volumi e molti domini come nel caso di clienti che hanno molti domini, la soluzione più veloce è quella di usare i certificati CloudFlare come vedremo di seguito.

Usare i certificati SSL CloudFlare in modalità reverse proxy.

Se non vuoi spendere un solo euro ma sai come fare, puoi abilitare CloudFlare in modalità Reverse Proxy e la loro catena di certificati che non è basata su LetsEncrypt.

CloudFlare memorizza nella cache contenuti statici del sito e li distribuisce su una rete di centinaia di server in tutto il mondo, su una CDN globale alimentata da 30 data center. Quando l’utente visita il sito web, non deve raggiungere il server di origine, perché il contenuto memorizzato nella cache gli viene consegnato dal server Cloudflare a lui più vicino, con un caricamento due volte più veloce!E’ uno dei modi più semplici per migliorare le prestazioni e ridurre il carico sui server web.

Nulla avviene a livello di file e sistema del vostro sito, tutti i dati che passano attraverso il sistema DNS vengono intercettati e gestiti dalla rete di CloudFlare che in questo modo vi applica alcune importanti operazioni di ottimizzazione, su Javascript, immagini, dei contenuti per il mobile, per i browser.

  • Cache pagine statiche
  • CDN
  • Ottimizzazione immagini
  • Ottimizzazione Javascript
  • Ottimizzazione mobile
  • Contenuti bilanciati

Abbiate ovviamente l’accortezza di connettere le API con i relativi moduli per i principali CMS.

Se non sapete come fare contattateci pure per una consulenza sistemistica. Risolveremo il problema in pochi minuti.

 

17279

Vuoi ricevere i migliori consigli ?

Ogni settimana nuovi consigli e novità !

Hai dei dubbi? Non sai da dove partire? Contattaci


Abbiamo tutte le risposte alle tue domande per aiutarti nella giusta scelta.

Scrivici

Chatta direttamente con il nostro supporto tecnico.

0256569681

Chiamaci subito negli orari d’ufficio 9:30 – 19:30

Ricevi assistenza

Apri un ticket direttamente nell’area di supporto.

INFORMAZIONI

ManagedServer.it è il principale provider italiano di soluzioni hosting ad alte performance. Il nostro modello di sottoscrizione ha costi contenuti e prevedibili, affinché i clienti possano accedere alle nostre affidabili tecnologie di hosting, server dedicati e cloud. ManagedServer.it offre, inoltre, eccellenti servizi di supporto e consulenza su Hosting dei principali CMS Open Source come WordPress, WooCommerce, Drupal, Prestashop, Magento.

Torna su