Come configurare correttamente i certificati SSL

Pubblicato il 3 giugno 2026

Una configurazione SSL funzionante non è semplicemente “installa il certificato e hai finito”. Il certificato deve corrispondere al dominio, la chiave privata deve rimanere sul server corretto, il DNS deve puntare dove pensi che punti e il server web deve presentare il certificato giusto per il nome host corretto. Se stai cercando come configurare i certificati SSL senza sorprese alle 2 del mattino, questo è il percorso pratico.

Come configurare i certificati SSL senza andare a tentoni

Inizia con una domanda: che cosa stai proteggendo esattamente? Un singolo dominio come example.com richiede un ambito di certificato diverso rispetto a una configurazione con www.example.com, app.example.com e shop.example.com. Se scegli il tipo di certificato sbagliato all'inizio, potresti ritrovarti a riemetterlo cinque minuti dopo, cosa non tragica, ma neanche elegante.

Per la maggior parte delle aziende, ci sono tre opzioni comuni. Un certificato per dominio singolo copre un nome host. Un certificato wildcard copre i sottodomini come anything.example.com, ma non sempre il dominio radice a meno che non sia incluso specificamente. Un certificato multidominio o SAN copre diversi nomi host specificati. La scelta giusta dipende dal tuo reale modello di traffico, non da ciò che sembra più avanzato.

Il controllo successivo è la convalida della proprietà. Le autorità di certificazione hanno bisogno della prova che controlli il dominio. Di solito questo avviene tramite convalida HTTP, convalida DNS o talvolta convalida tramite email. HTTP è spesso il metodo più rapido quando il sito web è già raggiungibile sul server. Il DNS è più affidabile per i wildcard e per gli ambienti dietro proxy, bilanciatori di carico o regole di staging che rendono disordinata la convalida web. A volte non è la situazione DNS più bella, ma è sotto controllo se sai quale metodo si adatta alla configurazione.

Prepara il server prima di installare qualsiasi cosa

Prima di generare una CSR o fare clic su un pulsante di installazione automatica, verifica quattro cose. Il dominio deve risolversi nell'IP pubblico corretto. Le porte 80 e 443 devono essere aperte nel firewall. Il server web dovrebbe già sapere quale host virtuale o server block risponderà per il dominio. E l'ora di sistema sul server deve essere corretta, perché SSL e ora sbagliata hanno vecchie discussioni in sospeso.

Se stai eseguendo Nginx o Apache, controlla prima la configurazione del sito esistente. Un certificato può essere perfettamente valido e comunque non funzionare nel browser se il server web invia un certificato predefinito di un altro sito sulla stessa macchina. Questo è particolarmente comune sui nodi VPS che ospitano più domini. SNI risolve il problema, ma solo se la mappatura del vhost è corretta.

Dovresti anche decidere se vuoi una gestione manuale dei certificati o un rinnovo automatico. La gestione manuale può essere accettabile per un singolo ambiente con poche modifiche, ma crea un rischio operativo. La maggior parte dei team non dimentica i rinnovi di proposito. Li dimentica perché è impegnata a svolgere attività che generano ricavi invece di fare da babysitter alle date di scadenza.

Genera correttamente la richiesta di certificato

Se il tuo pannello di controllo gestisce questo, usalo. In caso contrario, genera una chiave privata e una CSR sul server in cui il certificato verrà usato. La chiave privata non dovrebbe essere inviata via email, buttata in una chat condivisa o copiata su portatili casuali. I log raccontano sempre la stessa storia: la gestione delle chiavi diventa troppo disinvolta subito prima che qualcuno passi una brutta settimana.

La CSR dovrebbe includere il common name corretto e tutti i subject alternative name richiesti. Per i browser moderni, le voci SAN contano più del vecchio campo common name. Se ti servono sia example.com sia www.example.com, assicurati che siano inclusi entrambi. Dimenticare un nome host è una classica fonte di confusione del tipo “per me funziona, per i clienti no”.

Per l'emissione automatizzata, strumenti come i client ACME gestiscono questo passaggio per te. Possono generare chiavi, completare la convalida, installare certificati e pianificare i rinnovi. Questo è il percorso più pulito per molti ambienti VPS e di hosting gestito, soprattutto dove il tempo di attività e la ripetibilità contano più della cerimonia manuale.

Installa il certificato SSL sul tuo server web

Una volta emesso il certificato, installa il file del certificato insieme a qualsiasi bundle intermedio richiesto e alla chiave privata corrispondente. I percorsi dei file esatti e le direttive dipendono dal server web.

Su Nginx, definisci il certificato e la chiave nel server block per la porta 443. Su Apache, configuri il file del certificato, il file della chiave e la chain nel VirtualHost pertinente. Se stai usando un pannello di controllo, il pannello potrebbe inserire questi valori per te e ricostruire automaticamente la configurazione.

Dopo l'installazione, ricarica il server web in modo controllato invece di eseguire un riavvio forzato, a meno che non ci sia una ragione. Un reload applica il nuovo certificato riducendo al minimo l'interruzione. Poi verifica ciò che il server sta realmente presentando, non ciò che pensi dovrebbe presentare. I browser usano una cache aggressiva e i reverse proxy possono nascondere gli errori più a lungo di quanto sia salutare.

Forza HTTPS con attenzione, non alla cieca

Dopo che il certificato è attivo, reindirizza il traffico HTTP verso HTTPS. Questo è standard, ma il tempismo conta. Non forzare HTTPS prima che il certificato sia valido e servito correttamente, altrimenti crei una corsia rapida verso gli avvisi del browser.

Imposta un reindirizzamento 301 da HTTP a HTTPS a livello di server web oppure a livello applicativo, ma evita di sovrapporli entrambi a meno che tu non abbia una ragione. Troppe regole di reindirizzamento creano loop, nomi host misti o comportamenti che cambiano tra ambienti. Mantieni le cose semplici.

Se il sito usa risorse da vecchi URL HTTP, aggiornali. Gli avvisi di contenuto misto si verificano quando la pagina viene caricata tramite HTTPS ma recupera script, immagini, font o fogli di stile tramite HTTP. Il certificato può essere perfetto e il lucchetto sembrare comunque scontento. I checkout e-commerce e le dashboard SaaS in particolare dovrebbero essere controllati pagina per pagina, non solo sulla homepage.

Testa la configurazione come una persona che non si fida della fortuna

Apri il sito in un browser e ispeziona i dettagli del certificato. Conferma che il nome host corrisponda, che le date di validità siano corrette e che venga presentata la chain completa. Poi esegui il test dalla riga di comando, se possibile. Vuoi vedere esattamente quale certificato il server restituisce per il nome host richiesto.

Controlla questi punti pratici dopo l'installazione:

• Il dominio radice e la versione www funzionano entrambi come previsto
• La chain del certificato è completa
• HTTP reindirizza a HTTPS una sola volta, non tre
• Il server web serve il certificato previsto per ogni nome host
• Il rinnovo è configurato ed è effettivamente pianificato

Se stai usando una CDN o un reverse proxy, assicurati che il certificato esista nel posto giusto. Alcune configurazioni terminano SSL sul proxy e poi inviano HTTP in chiaro all'origine. Altre usano la crittografia end-to-end con certificati sia sul proxy sia sull'origine. Nessuna delle due è universalmente giusta o sbagliata. Dipende dal tuo modello di sicurezza, dalla fiducia nella rete interna e dalle esigenze dell'applicazione.

Problemi SSL comuni e cosa significano di solito

Un avviso del browser relativo a una mancata corrispondenza del nome host di solito significa che viene servito il certificato sbagliato, spesso perché il vhost predefinito intercetta la richiesta. Un avviso di “chain incompleta” significa che mancano gli intermedi. Un certificato scaduto è evidente, anche se in qualche modo è ancora popolare. I fallimenti di convalida spesso indicano record DNS che non corrispondono al server previsto, cache a livello DNS o un firewall che blocca le richieste di challenge HTTP.

I fallimenti di rinnovo meritano un'attenzione speciale. Se fai affidamento su SSL automatizzato e poi cambi DNS, aggiungi un proxy o irrigidisci le regole del firewall, il percorso di rinnovo può rompersi silenziosamente. La prima installazione ha funzionato, tutti si sono rilassati e sessanta giorni dopo il problema ritorna nel momento peggiore. Per questo il monitoraggio della scadenza dei certificati non è facoltativo in produzione. È igiene operativa di base.

Configurazione SSL gestita o autogestita

Se gestisci il tuo stack, configurare SSL manualmente ti dà il pieno controllo. Scegli il metodo di convalida, l'archiviazione delle chiavi, la policy dei cipher, il comportamento dei reindirizzamenti e il processo di distribuzione. Questo è utile per infrastrutture personalizzate, servizi in cluster o ambienti con requisiti di conformità rigorosi.

Il compromesso è la responsabilità operativa. Qualcuno deve monitorare i rinnovi, confermare la corretta riemissione e intercettare i cambiamenti che interrompono la convalida. Per piccoli team, agenzie e founder che già indossano cinque cappelli, l'hosting gestito con automazione SSL è spesso l'opzione più tranquilla. Una buona piattaforma elimina il lavoro ripetitivo senza nascondere il comportamento sottostante del server. Su kodu.cloud, questo è di solito il punto: meno stress, ma comunque controllo sufficiente.

Come configurare i certificati SSL per una stabilità a lungo termine

L'installazione è solo il primo passaggio. Una configurazione stabile include il rinnovo automatico, il monitoraggio della scadenza, mappature vhost chiare e l'abitudine di ricontrollare SSL dopo modifiche al DNS o al proxy. Se il sito è critico per l'azienda, tratta lo stato del certificato allo stesso modo in cui tratti i backup e gli avvisi sul tempo di attività. I sistemi silenziosi sono buoni sistemi.

Mantieni protette le tue chiavi private, rendi automatico il processo di rinnovo dove possibile e mantieni il metodo di convalida allineato a come il traffico raggiunge davvero il tuo server. Se dopo questo il servizio è di nuovo tranquillo, hai fatto bene.

Andres Saar Customer Care Engineer