Quando le Migrazioni della Catena CA Compromettono la Fiducia Mobile

Due clienti indipendenti hanno segnalato errori SSL che colpivano gli utenti Android, nonostante i loro certificati fossero validi e installati correttamente. I browser desktop non mostravano errori, mentre dispositivi mobili specifici rifiutavano le connessioni come non attendibili.

Riepilogo del Caso di Studio

• Problema: Le nuove catene CA non erano attendibili per i dispositivi Android più vecchi.
• Impatto: Gli utenti mobile vedevano errori SSL nonostante certificati validi.
• Causa principale: I trust store Android sono in ritardo rispetto alle migrazioni delle catene CA.
• Risoluzione: Riemettere utilizzando catene legacy o cross-signed, o migrare a una CA con migliore compatibilità mobile.
• Intuizione chiave: La fiducia SSL dipende dalle piattaforme client, non solo dalla validità del certificato.

---

Un certificato SSL può essere tecnicamente valido ma fallire comunque in produzione. La validità del certificato conferma solo che è stato emesso ed è crittograficamente solido. Non garantisce la fiducia universale su tutti i dispositivi.

Questo è esattamente ciò che accade durante le migrazioni delle catene CA. Le Certificate Authorities ruotano root e intermediari per sicurezza, conformità e sostenibilità a lungo termine. 

Ma le piattaforme client, specialmente i sistemi operativi mobile, aggiornano i loro trust store molto più lentamente e in modo inconsistente. Il risultato è una frattura tra l’infrastruttura di certificati moderna e la fiducia dei dispositivi legacy.

In questo caso di studio, esaminiamo due incidenti reali dove i cambiamenti delle catene CA hanno causato il fallimento di certificati SSL validi su dispositivi Android. Mostriamo come questi errori sono emersi in produzione, perché le diagnosi standard non hanno immediatamente rivelato la causa, e come diversi percorsi di risoluzione hanno ripristinato la compatibilità mobile in ogni caso.

Xamisoft: Quando un Aggiornamento Server ha Compromesso la Fiducia Android

Xamisoft sviluppa applicazioni per l’apprendimento linguistico utilizzate su piattaforme desktop e mobile. La loro infrastruttura funzionava senza problemi SSL su Windows Server 2019. I browser desktop e i dispositivi Android funzionavano normalmente, e il deployment dei certificati seguiva una configurazione IIS standard. Il problema è apparso solo dopo un aggiornamento di routine.

Il Problema

Hanno migrato il loro ambiente da Windows Server 2019 a Windows Server 2025 e reinstallato il certificato SSL utilizzando lo stesso metodo che aveva funzionato prima. Dal punto di vista del server, tutto era corretto. 

Il certificato era installato, i certificati root e intermedi erano presenti, e i browser desktop non mostravano avvisi. Nulla suggeriva una configurazione SSL compromessa.Poi gli utenti Android hanno iniziato a segnalare errori. Sulle versioni Android più vecchie, specialmente Android 6, il sito mostrava l’errore: “Questo certificato non proviene da un’autorità attendibile.”

In alcuni casi, errori simili apparivano anche su build Android più recenti. Ciò rendeva la situazione più difficile da interpretare. A prima vista, sembrava essere un server mal configurato o un file di certificato mancante.

Dal punto di vista del cliente, la situazione non aveva senso:

• Lo stesso certificato non aveva problemi su Windows Server 2019.
• Ora falliva su Windows Server 2025.
• I browser desktop funzionavano ancora.
• Solo gli utenti mobile erano bloccati.

Analisi della Causa Principale

Questo era il classico scenario “tutto è valido, eppure gli utenti sono bloccati”. A questo punto, due dimensioni tecniche hanno iniziato a emergere.

1. La Catena CA Stessa

Su Windows Server 2019, il certificato era stato emesso sotto la vecchia gerarchia CA Sectigo RSA Domain Validation Secure Server. Questa catena è ampiamente attendibile, incluse le versioni più vecchie.

Su Windows Server 2025, lo stesso certificato ora si collegava a: Sectigo Public Server Authentication CA DV R36.

Questa faceva parte della nuova gerarchia di fiducia di Sectigo. Era valida e attendibile dai sistemi moderni, ma alcuni trust store Android non la includevano ancora. Per quei dispositivi, la catena di certificati semplicemente non aveva un’ancora di fiducia.

2. Consegna della Catena di Certificati

Windows Server 2019 riempie i certificati intermedi mancanti utilizzando il trust store di sistema. IIS poteva recuperare gli intermedi dietro le quinte e presentare una catena completa ai client, anche se l’amministratore non aveva esplicitamente installato ogni componente.Windows Server 2025 ha cambiato quel comportamento. Richiedeva che la catena completa fosse esplicitamente configurata. Se qualche certificato intermedio era mancante o ordinato incorrettamente, alcuni client fallivano la validazione anche se i browser potevano recuperare la catena attraverso il fetching AIA (Authority Information Access).

Ciò significava che Xamisoft stava affrontando due problemi sovrapposti:

1. Alcuni dispositivi Android non si fidavano della nuova gerarchia Sectigo.
2. Alcuni client non ricevevano correttamente la catena completa dal server.

Ognuno di questi problemi da solo può compromettere SSL. Insieme, oscurano la vera causa.

Questo spiegava perché:

• I browser desktop funzionavano ancora.
• Gli strumenti di test SSL mostravano per lo più risultati verdi.
• I dispositivi Android fallivano imprevedibilmente, a seconda della versione e della build del fornitore.

La Nostra Diagnosi

Prima di tutto, abbiamo chiarito che i dispositivi Android non usano mai il trust store del server. L’installazione di certificati root su Windows non fa nulla per Android. La decisione di fiducia viene presa interamente sul dispositivo.

Secondo, abbiamo spiegato che Windows Server 2025 richiedeva completezza esplicita della catena. Il server doveva presentare:

• Il certificato del server
• I certificati intermedi corretti
• Nell’ordine corretto

Affidarsi al recupero implicito non era più praticabile.

La Risoluzione

Invece di cercare di forzare IIS a gestire questo in modo affidabile, Xamisoft ha implementato una correzione strutturale. Hanno posizionato Nginx davanti a IIS come proxy e configurato Nginx per servire esplicitamente la catena completa di certificati.

Questo ha raggiunto due obiettivi:

• La catena completa veniva consegnata costantemente a ogni client.
• I dispositivi Android che si fidavano ancora delle parti più vecchie della gerarchia potevano validare correttamente.

Dopo il cambiamento, gli errori SSL sono scomparsi e i dispositivi Android 6 potevano accedere nuovamente al sito. Non è stato necessario alcun cambiamento al certificato stesso.

Questo caso ha evidenziato che i fallimenti SSL spesso non sono causati da un singolo errore, ma emergono dalle interazioni tra evoluzione delle catene CA, trust store delle piattaforme, comportamento del software server e meccaniche di consegna dei certificati.La correzione di Xamisoft ha riparato il percorso di consegna tra l’infrastruttura CA moderna e la fiducia dei client legacy.

Coppernic: Android 6 Falliva Dopo una Riemissione del Certificato

Coppernic è un’azienda tecnologica francese che progetta e sviluppa soluzioni hardware e software mobili professionali per sistemi di identificazione, controllo accessi e raccolta dati.

Il Problema

Il problema è apparso durante una sostituzione di routine del certificato solo sui dispositivi Android legacy. Coppernic era nel processo di passaggio da un certificato SSL esistente a uno appena ordinato. 

L’installazione stessa è andata come previsto. I browser desktop accettavano il certificato senza avvisi. Nessuna configurazione errata lato server era visibile. Tuttavia, i terminali Android 6.0.1 non riuscivano più a stabilire una connessione attendibile. 

Il certificato era valido, installato correttamente e emesso da una Certificate Authority legittima, eppure quei dispositivi lo rifiutavano. Il certificato precedente aveva funzionato. Nient’altro nell’infrastruttura era cambiato.

Analisi della Causa Principale

L’unica differenza era la catena. Il nuovo certificato era stato emesso sotto la gerarchia aggiornata di Sectigo, utilizzando l’intermedio R46. Questa catena fa parte del processo di migrazione root di Sectigo. È conforme e attendibile dalle piattaforme moderne, ma molti trust store Android più vecchi non contengono le ancore necessarie per validarla.

Coppernic ha identificato la situazione precisamente:

“Sembra che il nuovo certificato CA (R46) non sia incorporato.”

Hanno tentato di ripristinare la compatibilità aggiungendo il certificato USERTrust, ma questo non ha aiutato. I dispositivi Android rifiutavano ancora la catena. Il problema non erano file mancanti sul server, ma l’assenza di un percorso di fiducia compatibile sui dispositivi stessi.

A quel punto, la questione si è spostata dall’installazione alla compatibilità.

La Nostra Diagnosi

Il nostro team di supporto ha confermato che il comportamento corrispondeva alla migrazione delle catene CA di Sectigo. A partire dalla metà del 2025, i nuovi certificati venivano emessi sotto gerarchie aggiornate per impostazione predefinita, inclusa la catena R46. Sebbene valido e attendibile dalle piattaforme moderne, quel percorso di fiducia non era presente in molti trust store Android più vecchi.

Abbiamo anche chiarito che aggiungere certificati come USERTrust non avrebbe influenzato i dispositivi Android. Android valida la fiducia esclusivamente contro il suo store interno. Se il dispositivo non riconosce il percorso di emissione, nessun cambiamento lato server può superare il fallimento.

La Risoluzione

La soluzione pratica era riemettere il certificato utilizzando una CA cross-signed.

Dopo che Coppernic ha contattato Sectigo, il certificato è stato riemesso sotto una catena cross-signed che preservava un percorso verso un root più vecchio, ancora attendibile. Non sono state necessarie modifiche all’infrastruttura. Solo il percorso di fiducia è stato regolato.

Una volta distribuito il certificato riemesso:

• I dispositivi Android 6.0.1 si connettevano normalmente.
• Le piattaforme desktop continuavano a fidarsi del certificato.
• L’incompatibilità è scomparsa immediatamente.

Questo caso è importante perché isola il problema a una singola variabile. Non c’era migrazione del server o inconsistenza nella consegna della catena. Entrambi i certificati erano validi, ma solo uno era utilizzabile in produzione.

L’esperienza di Coppernic mostra quanto rapidamente la compatibilità può crollare quando una Certificate Authority sposta la sua emissione predefinita in avanti. Un percorso di fiducia più nuovo non è automaticamente più ampio. In ambienti che dipendono ancora da flotte Android legacy, può essere più stretto e più fragile.

Come i Dispositivi Decidono se Fidarsi di un Certificato

Quando un dispositivo controlla un certificato SSL, costruisce un percorso di fiducia dal certificato del sito attraverso uno o più intermedi a un certificato root già presente nel suo trust store. Se il dispositivo non può completare quel percorso utilizzando certificati di cui si fida, la connessione fallisce, anche se il certificato stesso è valido.

Android è frammentato per design. I produttori spediscono versioni diverse, i programmi di aggiornamento variano, e molti dispositivi smettono di ricevere aggiornamenti di sistema molto prima di essere sostituiti. Un telefono può rimanere attivo per anni dopo il suo ultimo aggiornamento di sicurezza o del trust store. Dal punto di vista dei certificati, quel dispositivo diventa una capsula del tempo.

I trust store vivono all’interno del sistema operativo. Se l’OS non viene aggiornato, nemmeno il trust store lo è. Ciò significa che un dispositivo può continuare a fare affidamento su root di certificati e percorsi di fiducia che erano attuali anni fa, ma non si allineano più con come le moderne Certificate Authorities emettono le catene.

Perché Questi Problemi Sono Difficili da Diagnosticare

Le diagnosi SSL standard confermano che il certificato è valido, la catena è completa e il server lo sta servendo correttamente. Quello che non validano è se ogni dispositivo client nell’ecosistema può fidarsi di quella catena.

Nei nostri casi, tutti i controlli convenzionali sono passati. Gli strumenti di test SSL hanno restituito risultati verdi, la configurazione del server era corretta e i browser desktop funzionavano senza errori. Dal punto di vista dell’infrastruttura, nulla era compromesso.

Il fallimento si verificava al di fuori del campo delle diagnosi tradizionali. Solo specifiche classi di dispositivi (versioni Android più vecchie con trust store obsoleti) erano interessate. Poiché la maggior parte dei flussi di lavoro di validazione non include test di compatibilità di fiducia a livello di dispositivo, il problema rimaneva invisibile finché gli utenti reali non lo incontravano.Questo crea un punto cieco diagnostico: un certificato può essere valido, installato correttamente e completamente conforme, pur continuando a generare errori per utenti ignari.

Come Abbiamo Diagnosticato il Problema

Abbiamo identificato il problema attraverso il riconoscimento di pattern.

Quando un certificato valido funziona su piattaforme desktop ma fallisce su specifici ambienti mobili, indica un allontanamento dalla configurazione del server verso la compatibilità del trust store. Questo non è ovvio a meno che non si abbia precedente esposizione alle migrazioni CA e al comportamento della fiducia a livello di piattaforma.

L’apparizione di errori specifici per Android insieme a una catena CA appena introdotta ha immediatamente ristretto il campo di indagine. Il problema non era più “perché SSL è rotto,” ma “quali trust store non accettano più questo percorso di fiducia.”

Questo richiede di separare due concetti che spesso vengono confusi:

• validità del certificato (correttezza crittografica)
• fiducia del dispositivo (accettazione della piattaforma)

Riconoscere quella differenza ci ha permesso di diagnosticare il problema rapidamente e accuratamente.

I Percorsi di Risoluzione che Abbiamo Offerto

Una volta confermato il problema di compatibilità di fiducia, risolverlo è diventato una questione di strategia piuttosto che di riparazione. Ogni opzione rappresentava un diverso equilibrio tra stabilità a breve termine e allineamento a lungo termine con l’ecosistema di fiducia.

1. Riemettere utilizzando la catena legacy: Questo ha ripristinato immediatamente la compatibilità con i dispositivi Android più vecchi. Era il modo più veloce per rimuovere gli errori rivolti all’utente e stabilizzare il traffico di produzione.
2. Accettare compatibilità parziale: Alcuni ambienti scelgono di prioritizzare le piattaforme moderne e accettare che i dispositivi più vecchi incontreranno errori SSL. Questo semplifica l’infrastruttura, ma limita la portata del pubblico.
3. Passare a una diversa Certificate Authority: Migrare a un’altra CA può fornire compatibilità mobile a lungo termine e ridurre la dipendenza da catene di fiducia di transizione.

Pianificare migrazione a fasi: Anche quando si utilizza temporaneamente una catena legacy, è richiesta una pianificazione a lungo termine. Il modello di fiducia sottostante continuerà a evolversi, e gli amministratori di siti web devono affrontare la compatibilità strutturalmente.

Perché Riemettere il Certificato Non è una Correzione Permanente

Riemettere con una catena legacy o cross-signed posticipa il problema di compatibilità; non lo rimuove. Queste catene esistono per creare ponti di transizione, non per sostituire i percorsi di fiducia moderni.

Man mano che le Certificate Authorities continuano a modernizzare le loro gerarchie, gli intermedi più vecchi e i percorsi di compatibilità saranno ritirati. Quando ciò accadrà, gli stessi pattern di fallimento torneranno se i sistemi rimangono dipendenti da essi.

Riemettere è quindi uno stabilizzatore, non una soluzione. Guadagna tempo. La stabilità a lungo termine richiede allineamento con come evolvono gli ecosistemi di fiducia, non resistenza a essi.

Questa è la lezione strutturale dietro entrambi i casi di studio.

Considerazioni Finali: Perché i Certificati “Validi” Falliscono Ancora nel 2026 

Questo caso mostra come funziona SSL/TLS nella pratica nel 2026. Le Certificate Authorities si muovono velocemente. Ruotano le catene, modernizzano i percorsi di fiducia e rispondono a nuovi requisiti di sicurezza. I dispositivi non lo fanno. Sugli smartphone, molti utenti rimangono ancorati a modelli di fiducia che sono anni indietro rispetto all’infrastruttura CA attuale.

Per questo motivo, “valido” non significa più automaticamente “utilizzabile”.

Le organizzazioni non dovrebbero trattare SSL come una configurazione una tantum. Deve essere gestito come un livello di compatibilità tra:

• Certificate Authorities
• Sistemi operativi
• Cicli di vita dei dispositivi
• Ambienti utente

Ciò significa:

• Sapere quali dispositivi i tuoi utenti effettivamente utilizzano, non solo i browser in cui testi.
• Testare i certificati contro piattaforme mobili reali, incluse le versioni Android più vecchie.
• Tracciare annunci CA e migrazioni di catene come rischi operativi, non rumore di fondo.
• Evitare dipendenza da un singolo percorso di fiducia o una singola CA quando possibile.

La flessibilità diventa una proprietà di sicurezza. Ed è qui che il supporto diventa un livello di stabilità, non solo una funzione di helpdesk.

In SSL Dragon, il nostro team di supporto traduce i cambiamenti dell’ecosistema in decisioni attuabili:

• riconoscendo i problemi di compatibilità di fiducia
• separando il comportamento della piattaforma dagli errori del server
• scegliendo strategie di mitigazione
• proteggendo l’accesso degli utenti mobile

Colmiamo il divario tra standard e realtà di produzione. Se stai vedendo problemi SSL inaspettati su mobile o vuoi verificare come si comporta il tuo certificato dal vivo, fai passare il tuo dominio attraverso il nostro SSL Checker per vedere esattamente quello che vedono i dispositivi dei tuoi utenti.