Quando un server smette di ospitare "un sito" e comincia a ospitarne dieci, venti, cinquanta — sotto-domini per clienti diversi, ambienti di test, servizi interni — la gestione manuale delle configurazioni Apache diventa rapidamente caotica. Il pattern virtual host multipli con SSL indipendenti è quello che permette di scalare senza perdere il controllo.
Un file di configurazione per ogni dominio
La convenzione più solida è un file separato per ogni sito in /etc/apache2/sites-available/, attivato singolarmente con a2ensite. Questo evita che un errore di sintassi in un dominio blocchi anche gli altri, e rende semplicissimo disattivare un sito senza toccare gli altri:
sudo nano /etc/apache2/sites-available/clienteA.miodominio.it.conf
<VirtualHost *:80>
ServerName clienteA.miodominio.it
DocumentRoot /var/www/html/clienteA.miodominio.it
ErrorLog ${APACHE_LOG_DIR}/clienteA-error.log
CustomLog ${APACHE_LOG_DIR}/clienteA-access.log combined
</VirtualHost>
sudo a2ensite clienteA.miodominio.it.conf
sudo systemctl reload apache2
Log separati per dominio (ErrorLog/CustomLog distinti) sono fondamentali quando il numero di siti cresce: senza, diagnosticare un problema su un singolo cliente significa filtrare un unico log gigante condiviso da tutti.
Il ruolo di ServerName nella scelta del virtual host giusto
Apache seleziona il virtual host da servire in base all'header Host: della richiesta HTTP, confrontandolo con ServerName (e con ServerAlias, se presente). Se due file hanno lo stesso ServerName o se manca del tutto, Apache serve semplicemente il primo virtual host caricato in ordine alfabetico — un errore molto comune che fa "sparire" un sito dietro un altro senza errori evidenti nei log.
Certificati SSL indipendenti con Certbot
Con Certbot (client Let's Encrypt) ogni sotto-dominio ottiene il proprio certificato, e Certbot stesso può creare automaticamente il blocco <VirtualHost *:443> corrispondente:
sudo apt install certbot python3-certbot-apache
sudo certbot --apache -d clienteA.miodominio.it
Certbot rileva il virtual host HTTP esistente, ne crea uno gemello per la porta 443 con i percorsi ai certificati già configurati, e aggiunge un redirect automatico da HTTP a HTTPS (se lo confermi durante la procedura interattiva).
Rinnovo automatico, da verificare davvero
I certificati Let's Encrypt durano 90 giorni: il pacchetto installa un timer systemd che tenta il rinnovo periodicamente, ma vale la pena verificarlo esplicitamente invece di darlo per scontato:
sudo systemctl list-timers | grep certbot
sudo certbot renew --dry-run
Il comando --dry-run simula il rinnovo di tutti i certificati senza modificarli davvero: è il modo più sicuro per scoprire un problema di configurazione (es. una porta 80 bloccata da un firewall) prima che il certificato scada per davvero, magari di venerdì sera.
Isolare i siti anche a livello di permessi
Se i sotto-domini appartengono a clienti diversi, vale la pena eseguire PHP-FPM con pool separati per utente invece del classico www-data condiviso da tutti: un bug o una vulnerabilità in un sito non deve poter leggere i file di un altro cliente sullo stesso server. È un passo in più nella configurazione, ma su un server multi-tenant è la differenza tra un incidente isolato e uno che coinvolge tutti i clienti ospitati.