HSTS: attivarlo senza bloccare dominio e sottodomini

Questa guida approfondisce attivare HSTS sicurezza con controlli progressivi, modifiche reversibili e verifiche finali. Non inviare password, cookie, token, chiavi private o codici 2FA nei ticket.

Che cosa significa

HSTS deve essere inviato soltanto tramite una connessione HTTPS valida. L’opzione includeSubDomains estende la policy a tutti i sottodomini, compresi servizi dimenticati.

La registrazione preload è ancora più impegnativa: la rimozione non è immediata e richiede che l’intero dominio sia pronto per HTTPS.

Come riconoscere il problema

• Il browser passa direttamente a HTTPS.
• Un sottodominio HTTP non è più raggiungibile.
• Un certificato scaduto blocca senza eccezione.
• L’header appare duplicato.
• Cloudflare e origine impostano policy differenti.

Cause più frequenti

1. max-age troppo lungo subito

Una configurazione non testata resta memorizzata. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

2. includeSubDomains prematuro

Un servizio legacy non supporta HTTPS. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

3. Preload attivato senza piano

Il dominio viene incluso nelle liste browser. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

4. Header duplicati

CDN e origine inviano valori differenti. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

5. Certificato non valido

Il browser applica HSTS e rifiuta la connessione. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

6. Redirect incompleti

Alcune URL o host non raggiungono HTTPS corretto. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

Diagnosi passo per passo

1. Inventaria i sottodomini. Include webmail, API, staging e servizi esterni. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
2. Verifica HTTPS. Controlla certificato, catena e hostname su ogni servizio. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
3. Controlla redirect. HTTP deve raggiungere HTTPS senza loop. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
4. Leggi l’header. Usa curl e strumenti browser. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
5. Identifica chi lo aggiunge. Origine, plugin o CDN. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
6. Inizia con max-age breve. Osserva il comportamento prima di aumentarlo. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
7. Valuta preload separatamente. Controlla requisiti e conseguenze. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.

Metodo sicuro di diagnosi

Prima di applicare modifiche, registra lo stato iniziale: URL o servizio coinvolto, messaggio completo, data e ora, rete o client, ultima operazione eseguita e risultato da un secondo strumento. Questo consente di distinguere una causa locale da una configurazione condivisa e rende possibile il rollback.

Cambia un solo elemento alla volta. Dopo ogni intervento ripeti esattamente lo stesso test, controlla i log dello stesso intervallo temporale e annota il risultato. Modificare contemporaneamente DNS, cache, PHP, plugin e firewall rende impossibile stabilire quale correzione abbia avuto effetto.

Controllo incrociato

Usa almeno due fonti indipendenti. Per HTTP confronta browser, curl e log; per WordPress confronta frontend, wp-admin e WP-CLI; per DNS interroga nameserver autoritativo e resolver pubblico; per la posta confronta header, Webmail e Track Delivery. Cache e proxy possono mostrare stati differenti per alcuni minuti.

Quando il problema sembra risolto, ripeti il test con una seconda rete o un secondo account e verifica che le protezioni restino attive. Una soluzione che disabilita globalmente TLS, WAF, autenticazione o controlli di sicurezza non è considerata definitiva.

Procedura di risoluzione

1. Correggi tutti i certificati. Non attivare HSTS su servizi non pronti. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
2. Invia un solo header. Gestiscilo nel livello scelto. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
3. Aumenta max-age gradualmente. Passa da test breve a durata più lunga. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
4. Aggiungi includeSubDomains soltanto dopo inventario. Ogni sottodominio deve supportare HTTPS. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
5. Usa preload solo con decisione consapevole. Prevedi manutenzione continua del dominio. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
6. Monitora rinnovi. AutoSSL e CDN devono mantenere certificati validi. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
7. Documenta la policy. Evita rimozioni o duplicazioni accidentali. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.

Verifica della stabilità dopo l’intervento

Non fermarti al primo test riuscito. Ripeti l’operazione dopo aver aperto una nuova sessione, svuotato soltanto la cache pertinente e atteso l’eventuale scadenza del TTL o del rate limit. Controlla inoltre che una seconda pagina, un secondo utente o un secondo destinatario non presentino ancora il problema.

Conserva per almeno il tempo necessario il backup e la configurazione precedente. Se l’anomalia ricompare, confronta orario, log e processo pianificato: una ricorrenza regolare può dipendere da cron, rinnovi, rotazioni, cache rigenerate o servizi esterni.

Come procedere prima di aumentare la durata HSTS

Prima di portare max-age a diversi mesi, verifica il dominio principale e ogni sottodominio da reti differenti. Controlla che il certificato includa l’hostname corretto, che la catena sia completa e che il rinnovo automatico funzioni. Esamina anche servizi meno evidenti, come pannelli, API, aree clienti, ambienti di staging e applicazioni esterne collegate al dominio.

Durante la fase iniziale utilizza una durata breve e annota la data di attivazione. Se non emergono problemi, aumenta gradualmente il valore. L’opzione includeSubDomains deve essere aggiunta soltanto quando tutti i sottodomini, anche quelli non pubblicizzati, supportano HTTPS in modo permanente. Prima del preload controlla inoltre che il redirect HTTP verso HTTPS sia stabile e che nessun servizio dipenda ancora da collegamenti non cifrati.

Controlli finali

• HTTPS valido ovunque.
• Header unico.
• Redirect corretti.
• Nessun sottodominio legacy bloccato.
• Rinnovi monitorati.

Prevenzione

• Inventario sottodomini.
• AutoSSL funzionante.
• max-age graduale.
• Monitoraggio certificati.
• Documentazione preload.

Errori da evitare

• Non partire con due anni e preload.
• Non usare includeSubDomains senza test.
• Non inviare HSTS via HTTP.
• Non duplicare header.
• Non pensare che HSTS sostituisca il certificato.

Quando contattare l’assistenza Xlogic

Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi o richiede log e configurazioni non disponibili nel pannello. Indica:

• dominio e sottodomini
• header attuale
• uso Cloudflare
• certificato problematico
• data attivazione

Non inviare credenziali. URL, orari, codici, header non sensibili e messaggi di errore sono sufficienti per iniziare la diagnosi.

Fonti tecniche ufficiali

• MDN Strict-Transport-Security
• Cloudflare HSTS

Verifica prolungata dopo la correzione

Una singola prova riuscita non dimostra che il problema sia definitivamente risolto. Ripeti l’operazione dopo una nuova sessione, da una seconda rete o con un secondo utente quando applicabile. Per DNS e posta considera anche TTL, code e cache dei resolver; per HTTP e WordPress controlla una pagina dinamica, una funzione amministrativa e il relativo registro degli errori.

Conserva temporaneamente il backup, i valori precedenti e gli estratti dei log. Se l’anomalia ricompare, confronta l’orario con cron, backup, aggiornamenti, rinnovi SSL, rotazioni DNS, code email e servizi esterni. Una ricorrenza regolare è spesso più significativa del messaggio mostrato durante il singolo evento.

Prima di chiudere l’intervento verifica inoltre che le misure di sicurezza siano ancora operative: HTTPS valido, autenticazione richiesta, WAF attivo, permessi non eccessivi e nessun endpoint di debug o manutenzione lasciato pubblico. La soluzione deve correggere la causa senza ridurre stabilmente le protezioni del servizio.

Domande frequenti su attivare HSTS sicurezza