Certificato TLS e header di sicurezza HTTP: che cosa succede dietro HTTPS

1. Che cosa fa il certificato durante una visita

Quando il browser si collega in HTTPS, TLS stabilisce un canale cifrato e il server presenta il proprio certificato. Il browser controlla che copra il nome richiesto, che sia nel periodo di validità e che risalga, attraverso la catena, a una CA (un’autorità che emette certificati) di cui si fida. Se uno di questi controlli fallisce, al posto della pagina compare un errore.

Fai l’elenco dei nomi pubblici: dominio principale, www e sottodomini di servizio come area clienti o assistenza. Per ognuno annota chi gestisce il certificato e come si rinnova. CDN e server di origine possono avere certificati distinti, con rinnovi separati: il visitatore vede quello della CDN, ma se la CDN si collega all’origine in HTTPS anche quel tratto usa un certificato che può scadere.

I rinnovi stanno diventando più frequenti. Secondo il calendario approvato dal CA/Browser Forum, i certificati pubblici emessi dal 15 marzo 2026 durano al massimo 200 giorni; il limite scende a 100 giorni dal 15 marzo 2027 e a 47 dal 15 marzo 2029. Let’s Encrypt, inoltre, ha smesso di inviare le email di avviso di scadenza nel giugno 2025. Conviene quindi affidarsi al rinnovo automatico e affiancargli un controllo indipendente della scadenza, che avvisi se il rinnovo non è avvenuto.

Sul protocollo, le linee guida dell’ACN su TLS (versione 2.0, maggio 2026) considerano obsolete tutte le versioni di SSL e TLS 1.0 e 1.1 e raccomandano TLS 1.3 e TLS 1.2, con preferenza per la prima; per TLS 1.2 ammettono solo un elenco ristretto di suite crittografiche, perché molte di quelle previste dal protocollo sono oggi considerate insicure. La guida TLS di OWASP aiuta a tradurre queste scelte nella configurazione del server. Annotare il protocollo negoziato in una connessione reale è un’osservazione concreta; una singola connessione, però, mostra solo la versione concordata, non tutte quelle che il server accetterebbe.

2. Che cosa aggiunge ogni livello

Considera questi controlli come istruzioni complementari. Il certificato riguarda la connessione; gli header descrivono come il browser deve trattare una risposta specifica. Pagine diverse hanno esigenze diverse: un articolo pubblico, l’area account e un widget pensato per essere incorporato altrove richiedono regole adatte al loro ruolo. Secondo OWASP, header configurati bene aiutano a prevenire problemi come cross-site scripting, clickjacking e divulgazione di informazioni; non sostituiscono però un codice scritto con attenzione.

3. Costruisci la CSP sulle risorse che usi davvero

La Content Security Policy dice al browser da quali origini la pagina può caricare script, stili, immagini, font, connessioni e frame. Il suo scopo principale è ridurre l’impatto di un cross-site scripting: se uno script estraneo finisce nella pagina, il browser si rifiuta di eseguirlo quando la policy non lo consente. Come ricorda la guida di MDN, è una difesa in profondità e non sostituisce la validazione dell’input.

Parti da un inventario di script, immagini, font, chiamate di rete e frame. Percorri tutto il flusso, non solo la home, così da includere pagamento, autenticazione e widget di assistenza che compaiono dopo un’interazione. Poi pubblica la policy proposta con l’header Content-Security-Policy-Report-Only: il browser segnala le violazioni nella console o all’endpoint configurato, senza bloccare nulla. Associa ogni segnalazione alla risorsa che la genera e decidi la regola. Quando i percorsi rappresentativi non producono più segnalazioni inattese, applica la policy con l’header Content-Security-Policy.

Alcuni dettagli che fanno risparmiare tempo:

• per gli script, MDN raccomanda una policy basata su nonce o hash, la cosiddetta strict CSP, invece di un lungo elenco di domini; con script di terze parti che ne caricano altri può essere difficile da applicare;
• 'unsafe-inline' annulla buona parte della protezione: evitalo dove puoi;
• la modalità Report-Only e la direttiva frame-ancestors funzionano solo come header HTTP, non dentro un tag <meta>;
• frame-ancestors non eredita da default-src: una policy con default-src 'none' lascia comunque incorporare la pagina da chiunque.

Un inventario documentato delle risorse rende più semplice valutare le aggiunte future e dà al team una spiegazione per ogni permesso concesso.

4. Fai di HTTPS un’abitudine del browser con HSTS

L’header Strict-Transport-Security dice al browser di usare solo HTTPS per quell’host per il numero di secondi indicato in max-age, trasformando in HTTPS anche i tentativi futuri in HTTP. Il browser impara la regola da una risposta HTTPS valida; se l’header arriva su HTTP, lo ignora. Per questo il redirect da HTTP a HTTPS resta necessario: meglio se permanente (301 o 308) e verso la stessa risorsa sullo stesso host. Il redirect non deve contenere l’header, che va invece sulla risposta HTTPS. HSTS non protegge la primissima visita, prima che il browser abbia ricevuto l’header.

C’è un effetto da conoscere prima di attivarlo: su un host con HSTS il browser non permette di proseguire ignorando un errore di certificato. Se il certificato scade, chi ha già visitato il sito non riesce ad aprirlo finché non viene rinnovato. Il registro dei certificati della sezione 1 diventa quindi parte integrante della gestione di HSTS.

Il sito hstspreload.org suggerisce di aumentare max-age per gradi (cinque minuti, una settimana, un mese), controllando a ogni passo che non si rompa nulla. L’opzione includeSubDomains estende la regola a tutti i sottodomini: confrontala con il tuo inventario, perché un sottodominio ancora servito solo in HTTP smetterebbe di funzionare. Anche con includeSubDomains, ogni sottodominio dovrebbe inviare il proprio header. Per disattivare HSTS si pubblica max-age=0, ma solo su HTTPS.

Il precaricamento (preload) inserisce il dominio in un elenco distribuito con i browser, valido anche per la prima visita. Oggi però lo stesso hstspreload.org raccomanda HSTS e sconsiglia il precaricamento: browser come Chrome e Safari portano già automaticamente su HTTPS le navigazioni in HTTP, e il preload serve solo quando questo passaggio fallisce per l’intervento di un attaccante. Uscire dall’elenco richiede mesi, e chi distribuisce configurazioni o strumenti non dovrebbe inserire preload per impostazione predefinita. La pagina di MDN su HSTS descrive tutte le opzioni.

5. Adatta cookie e header al percorso dell’utente

Un cookie di sessione permette al servizio di riconoscere una visita che prosegue. I suoi attributi decidono dove viaggia e chi può leggerlo (vedi MDN su Set-Cookie):

• Secure: il browser invia il cookie solo su HTTPS, con l’eccezione di localhost. Non lo nasconde agli script della pagina.
• HttpOnly: impedisce a JavaScript di leggere il cookie, per esempio tramite document.cookie. Il browser però continua a inviarlo con ogni richiesta pertinente, comprese quelle avviate da JavaScript, e il cookie non viene cifrato. Riduce il rischio che un attacco XSS rubi la sessione, ma non impedisce l’XSS.
• SameSite: decide se il cookie accompagna le richieste che partono da altri siti (Strict, Lax o None); None richiede anche Secure. Non tutti i browser applicano lo stesso valore predefinito, quindi conviene indicarlo esplicitamente. È una difesa aggiuntiva contro il CSRF, non un sostituto dei token anti-CSRF.

Scegli i valori in base al flusso reale. Il ritorno da un fornitore di pagamento o da un accesso esterno è una richiesta che arriva da un altro sito: con Strict il cookie non viene inviato e la sessione può sembrare persa, quindi prova questi passaggi prima di decidere. I prefissi __Host- e __Secure- nel nome del cookie fanno sì che il browser lo accetti solo se impostato con Secure da un’origine HTTPS.

Altri header completano il quadro:

• X-Content-Type-Options: nosniff fa sì che il browser blocchi script e fogli di stile serviti con un tipo MIME errato e non cerchi di indovinare il tipo delle altre risposte; funziona solo se il Content-Type è corretto ovunque.
• Referrer-Policy stabilisce quanta parte dell’indirizzo viene inviata nell’header Referer. Se la policy non è indicata, i browser applicano strict-origin-when-cross-origin; OWASP suggerisce comunque di inviarlo in modo esplicito.
• Per decidere chi può incorporare la pagina usa la direttiva CSP frame-ancestors; X-Frame-Options con DENY o SAMEORIGIN resta come ripiego per i browser più vecchi. Il valore ALLOW-FROM è obsoleto e fa ignorare l’intero header, e X-Frame-Options inserito in un tag <meta> non ha effetto.
• X-XSS-Protection è deprecato e può introdurre problemi: non inviarlo, oppure impostalo a 0, e affidati alla CSP.

Il riferimento OWASP sugli header aiuta a scegliere i valori. Documenta lo scopo di ogni header, così che applicazione, proxy e CDN esprimano una policy coerente. Un dettaglio pratico: in nginx, add_header senza il parametro always invia l’header solo con alcuni codici di stato, quindi le pagine di errore possono restarne prive.

6. Osserva il risultato come lo vede il visitatore

Apri gli strumenti per sviluppatori del browser, carica una pagina normale e segui i reindirizzamenti fino alla risposta finale. Esamina il certificato, gli header e i cookie effettivamente consegnati. È il modo più diretto per collegare la configurazione all’esperienza del visitatore e per capire quale componente, tra applicazione, proxy e CDN, aggiunge ciascuna impostazione.

1. Visita via HTTPS tutti i nomi pubblici previsti, e prova anche l’indirizzo con http:// per controllare il redirect.
2. Annota i dettagli del certificato e gli header della risposta finale.
3. Completa accesso, recupero della password, pagamento incorporato e ritorni da servizi esterni.
4. Controlla la console e la destinazione delle segnalazioni CSP.

Conserva una copia datata della configurazione e indica chi gestisce ogni livello. Quando cambia l’hosting o arriva una nuova integrazione, ripeti lo stesso percorso per verificare che il comportamento sia quello previsto. Un rilascio pianificato e la configurazione precedente a portata di mano permettono di tornare indietro senza improvvisare. La checklist che ne risulta è anche una buona introduzione al sito per chi lo gestirà in futuro.

Per controllare subito gli header di un sito, usa la verifica degli header di sicurezza HTTP gratuita.

7. Tieni la mappa delle protezioni vicino al sito

Raccogli in un unico posto nomi pubblici, responsabili dei certificati, risorse caricate dal browser e percorsi importanti. Per un primo controllo dall’esterno puoi usare lo snapshot gratuito di Sitelemetry: otto controlli passivi su un’origine pubblica, senza registrazione; non è un penetration test. Restituisce un punteggio, un voto separato di rafforzamento (hardening) per header di sicurezza e TLS e al massimo tre segnali da guardare per primi. Per TLS esegue un solo handshake e verifica che la catena sia attendibile, che il certificato non sia scaduto né in scadenza entro 30 giorni e che il protocollo negoziato sia TLS 1.2 o 1.3; non elenca tutte le versioni e le suite accettate dal server. Per gli header guarda la risposta finale dopo al massimo 5 reindirizzamenti e controlla soprattutto la presenza di CSP, HSTS, protezione dai frame, nosniff e Referrer-Policy, oltre ai cookie privi di HttpOnly o Secure; SameSite non viene valutato. Il redirect da HTTP a HTTPS viene provato solo se inserisci un indirizzo che inizia con http://, e in quel caso il controllo TLS viene saltato. La guida all’audit di sicurezza del sito collega questi livelli ad account, permessi e manutenzione quotidiana.