Quando cambi hosting, il vecchio certificato TLS continua a lavorare? Scopri perché l’autenticazione non segue subito il dominio

Quando sposti un sito web, pensi che tutto cambi subito. In realtà, il certificato TLS potrebbe rimanere attivo più a lungo. Le piattaforme gestite TLS generano chiavi e certificati per conto tuo. Quando decidi di cambiare hosting o CDN, il vecchio certificato continua a funzionare fino alla scadenza. Nessuna piattaforma lo revoca o lo sostituisce automaticamente. Questo crea una finestra di tempo in cui sia il vecchio che il nuovo servizio possono autenticare lo stesso dominio. Durante questo periodo, i browser potrebbero ancora accettare il vecchio certificato, anche se puntano al nuovo hosting. La situazione è sicura ma può confondere gli utenti e lasciare un piccolo rischio di attacchi man-in-the-middle. I ricercatori hanno osservato questo comportamento in diversi provider, evidenziando la necessità di meccanismi di ritiro più rapidi. Capire questo passaggio aiuta a proteggere meglio la propria presenza online.

Le piattaforme di Managed TLS semplificano la gestione delle chiavi crittografiche delegando la generazione, la conservazione e il rinnovo dei certificati X.509 a un fornitore terzo. Questo modello si basa su un'autorità di certificazione (CA) controllata dal provider, che emette certificati vincolati al nome di dominio piuttosto che alle chiavi private dell'operatore del dominio. Quando un dominio viene "delegato" a una piattaforma, il fornitore installa un certificato TLS firmato dalla propria CA sui server di origine, permettendo ai client di stabilire connessioni HTTPS sicure senza interventi manuali.

La migrazione away da una piattaforma di questo tipo può avvenire per vari motivi: cambio di CDN, adozione di un nuovo servizio di hosting o consolidazione di più domini sotto un unico gestore di certificati. Lo studio ha monitorato otto piattaforme popolari utilizzando un ambiente di misurazione controllato. Per ogni dominio, i ricercatori hanno prima ottenuto un certificato emesso dalla piattaforma, poi hanno reindirizzato il DNS verso una nuova infrastruttura gestita da un concorrente, mantenendo il vecchio certificato attivo. Sono stati osservati i log dei server e i modelli di handshake TLS per l'intera durata di validità del certificato (fino a 90 giorni).

I risultati mostrano che nessuna delle piattaforme monitorate ha revocato il certificato delegato, emesso un nuovo certificato o attivato meccanismi di "certificate pinning" dopo la migrazione. I server originali continuavano a presentare lo stesso certificato, e i client che risolvevano ancora l'indirizzo IP vecchio (o che mantenevano una cache DNS obsoleta) completavano il handshake TLS senza errori. Solo dopo la scadenza naturale del certificato il vecchio materiale di autenticazione è scomparso, lasciando che il nuovo provider emettesse un certificato fresco.

Dal punto di vista della sicurezza, questo comportamento crea una "finestra di autenticazione" in cui più entità controllano lo stesso dominio dal punto di vista crittografico. Un attaccante in grado di ottenere l'accesso all'infrastruttura precedente (ad esempio tramite un compromesso di un server legacy) potrebbe continuare a presentare un certificato valido, eludendo i controlli che si basano esclusivamente sul DNS per l'autorità. Inoltre, i servizi che si affidano al certificate pinning o alla verifica out-of-band (come le app mobili) potrebbero continuare a fidarsi di chiavi obsolete, aumentando la superficie d'attacco.

Per ridurre questo rischio, i fornitori stanno esplorando meccanismi di ritiro più rapidi: HTTP-based Certificate Status Protocols (OCSP Push, Must-Staple), revoca basata su blockchain e chiavi "ephemeral" che vengono scartate automaticamente dopo un cambio di provider. Gli operatori dei domini, dal canto loro, possono adottare pratiche come il "certificate rotation" automatico, il monitoraggio continuo della catena di fiducia e l'uso di più CA per i propri servizi critici. Comprendere la discrepanza tra controllo DNS e controllo delle chiavi è fondamentale per costruire una PKI resiliente nell'era del cloud.