Inventaria host, dipendenze e responsabilità
Elenca ogni hostname che visitatori o integrazioni usano: dominio apex, www, sottodomini, API, host di asset, portali e nomi regionali. Per ciascuno registra dove termina TLS, chi può modificarlo, la copertura e la scadenza del certificato, il metodo di rinnovo e le dipendenze che generano URL. Un certificato deve coprire l'hostname richiesto nella lista Subject Alternative Name (SAN). Includi il CMS, il CDN, il tag manager, l'object storage, il fornitore di pagamenti, i template email e gli embed di terze parti; questi introducono comunemente URL HTTP dopo la prima pubblicazione HTTPS.
Seleziona un hostname canonico — www o apex — e reindirizza l'alternativa direttamente a quello su HTTPS.
Distribuisci il certificato e le versioni TLS correnti
Configura il web server, il reverse proxy, il CDN o il load balancer che risponde alla richiesta pubblica. Installa il certificato e la catena richiesta, associali ai nomi previsti e verifica dall'esterno della rete di hosting. Il browser controlla la catena, l'hostname e le date; un avviso pubblico è un blocco per il rilascio. Imposta come predefinito TLS 1.3 e mantieni TLS 1.2 solo quando la compatibilità lo richiede. Disabilita SSL e TLS 1.0 e 1.1. Usa le linee guida delle piattaforme manutenute invece di copiare una lista di cifrari legacy e tieni aggiornati server e librerie TLS.
Limita l'accesso alle chiavi private e registra ogni sistema che condivide una chiave in modo che la sostituzione raggiunga tutti i target.
Reindirizza HTTP una sola volta e rendi HTTPS canonico
Restituisci un reindirizzamento lato server permanente, normalmente 301 o 308, da ogni URL HTTP al suo equivalente HTTPS. Evita catene: aggiungono latenza e più punti di guasto. Pubblica URL canonical HTTPS nei link interni, tag canonical, sitemap, dati strutturati, tag social, email e link assoluti generati dall'applicazione. Testa la home page, una pagina profonda, un URL con query, rotte di errore e varianti di hostname. Quando TLS termina su un proxy, configura una gestione affidabile dell'intestazione relativa al protocollo inoltrato, in modo che l'applicazione non entri in un loop tra HTTP e HTTPS.
Può rimanere disponibile solo per il reindirizzamento o per completare una challenge del certificato, non per servire un sito pubblico separato.
Trova e correggi il contenuto misto alla fonte
Il contenuto misto (mixed content) è una pagina HTTPS che richiede una risorsa via HTTP o tramite un altro protocollo insicuro. I browser possono aggiornare automaticamente alcuni media, ma bloccano molte richieste rischiose, inclusi script, fogli di stile, frame, fetch, e font. Sostituisci ogni riferimento con un URL HTTPS testato, un URL relativo per i contenuti propri o un'alternativa approvata. Crawla template rappresentativi e ispeziona gli strumenti per sviluppatori mentre completi i percorsi chiave. Controlla CSS, JavaScript, blocchi CMS, manifest degli asset, voci del tag manager, download e embed dei vendor. Una pagina sicura non dovrebbe offrire un download via HTTP.
L'upgrade automatico del browser può comunque lasciare una dipendenza di terze parti non disponibile o non supportata; correggi l'URL memorizzato.
Automatizza il rinnovo e prova il recupero dei certificati
Tratta il rinnovo come una distribuzione automatizzata, non come un promemoria sul calendario. L’automazione deve rinnovare il certificato, distribuirlo a ogni livello che eroga il servizio e ricaricare il servizio in sicurezza. Testa lo stesso percorso di convalida prima della scadenza del certificato in produzione. Let’s Encrypt, per esempio, raccomanda di rinnovare i suoi certificati di 90 giorni ogni 60 giorni; segui il ciclo di vita previsto dal tuo emittente e dalla tua piattaforma. Conserva in un inventario i nomi dei certificati, gli account dell’emittente, il metodo di challenge, l’automazione, la posizione della chiave, le destinazioni di distribuzione e i contatti di emergenza. Verifica le date dall’endpoint pubblico dopo la distribuzione.
Per un rinnovo fallito, controlla DNS, instradamento della challenge, permessi, accesso all’emittente, limiti di frequenza e distribuzione tra CDN e origine.
Usa HSTS solo quando l'ecosistema HTTPS è pronto
HTTP Strict Transport Security, o HSTS, è un header di risposta HTTPS che indica ai browser di usare HTTPS nelle visite successive a un host. I browser poi non offrono ai visitatori un bypass per errori di certificato. Invia l'header solo su HTTPS e mantieni il reindirizzo HTTP perché HSTS viene appreso dopo una risposta sicura a meno che non si applichi una lista di preload. Inizia con un max-age limitato e aumentalo dopo aver dimostrato i rinnovi e le rotte richieste. Non aggiungere includeSubDomains finché ogni sottodominio presente e futuro non può servire un HTTPS valido. Il preload non fa parte della specifica HSTS e merita una revisione separata e di lungo periodo.
max-age=0 funziona solo dopo che un browser raggiunge una risposta HTTPS valida; non può riparare un host sicuro irraggiungibile.
Rilascia, testa e rollback senza indebolire il trasporto
Cattura la configurazione nota-funzionale del certificato, dell'edge e dei reindirizzamenti prima del cambiamento. Definisci chi approva un rollback, effettua un rollout graduale dove possibile e modifica una classe di controllo alla volta. Controlla immediatamente gli endpoint pubblici da più di una rete, segui i reindirizzamenti, ispeziona il certificato e completa le azioni importanti del visitatore. Testa i browser e i gruppi di client che contano per il tuo pubblico. Per flussi di pagamento o regolamentati, chiedi al provider di pagamenti e a un professionista della sicurezza qualificato di rivedere i requisiti applicabili. Se un cambiamento rompe HTTPS, ripristina una configurazione sicura validata; non rendere le pagine cliente HTTP come soluzione alternativa.
Cattura hostname, orario, client, errore, cambiamento e risultato così che il prossimo rinnovo o migrazione sia più facile da diagnosticare.