Installare mod_ssl su AlmaLinux 8 e Rocky Linux 8 con Apache

Quando Apache su AlmaLinux 8 e Rocky Linux 8 serve davvero con TLS

Su AlmaLinux 8 e Rocky Linux 8 Apache può servire traffico HTTP senza problemi, ma nel momento in cui il sito deve parlare in HTTPS il pacchetto mod_ssl diventa il pezzo che abilita il supporto TLS dentro httpd. Non è un “optional cosmetico”: senza quel modulo, la parte SSL/TLS di Apache non è disponibile in modo nativo e i virtual host su porta 443 non partono come ci si aspetta. In pratica: se devi pubblicare un sito con certificato, fare redirect corretto da HTTP a HTTPS, o terminare TLS direttamente sull’host, mod_ssl è il primo mattoncino da mettere a posto.

© TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster — https://trgtkls.it — tutti i diritti riservati.

Il punto operativo è banale solo in apparenza. Su EL8 il pacchetto si installa in fretta, ma il lavoro vero è verificare che il modulo sia caricato, che la configurazione del virtual host non sia incoerente, che i certificati siano leggibili da Apache e che il firewall non blocchi la 443. Se salti uno di questi passaggi, il risultato tipico è un servizio che resta su HTTP, un errore in fase di restart, oppure un browser che vede il certificato ma riceve una risposta sbagliata dal virtual host.

Pacchetto, servizio e differenza pratica rispetto a un Apache “solo HTTP”

Su AlmaLinux 8 e Rocky Linux 8 il flusso standard è questo: installi Apache, poi aggiungi mod_ssl, poi definisci il virtual host HTTPS. Il pacchetto porta con sé i moduli necessari e, in molte installazioni, crea anche un file di configurazione dedicato con impostazioni TLS di base. Questo è utile perché riduce il lavoro manuale, ma non sostituisce una verifica attenta dei parametri effettivi del server.

In ambiente production io distinguo sempre tre livelli: supporto TLS (mod_ssl installato), configurazione TLS (vhost, certificati, policy), esposizione (porta 443 raggiungibile e pubblicata). Installare il pacchetto risolve solo il primo livello. Se poi la 443 non ascolta, o il certificato è nel path sbagliato, l’utente vede comunque un guasto.

Verifica iniziale: stato atteso contro stato osservato

Stato atteso: Apache su EL8 deve accettare connessioni HTTPS su 443 con un virtual host valido, certificato leggibile e modulo SSL caricato. Stato osservato quando manca il pezzo giusto: il servizio httpd parte in HTTP, il vhost 443 non risponde, oppure il restart fallisce con errori legati a moduli mancanti, direttive TLS non riconosciute o certificati non accessibili.

Prima di cambiare qualcosa, conviene raccogliere due evidenze: il pacchetto è presente e il modulo è davvero attivo. Questo evita di confondere un problema di installazione con uno di configurazione del sito.

Installazione di mod_ssl su AlmaLinux 8 e Rocky Linux 8

La procedura base è diretta. Su entrambi i sistemi il pacchetto si installa con dnf. Se Apache è già installato, il modulo si aggancia al servizio esistente senza richiedere interventi invasivi.

sudo dnf install -y mod_ssl

Dopo l’installazione, verifica che il modulo sia visibile nella configurazione caricata da Apache:

httpd -M | grep ssl

Il risultato atteso è una riga simile a ssl_module (shared). Se non compare, il pacchetto è stato installato ma il modulo non è ancora caricato o stai leggendo una configurazione diversa da quella effettivamente usata dal servizio.

Se il comando httpd -M non è disponibile, il binario potrebbe non essere nel PATH o Apache non è installato correttamente. In quel caso il controllo minimo è:

rpm -q httpd mod_ssl

Qui il risultato sano è la presenza di entrambi i pacchetti. Se mod_ssl c’è ma httpd manca, la diagnosi è ovvia: il modulo è installato ma non c’è il server web che lo usa.

Cosa cambia nei file di configurazione dopo l’installazione

Su EL8 il pacchetto mod_ssl introduce in genere un file dedicato sotto /etc/httpd/conf.d/, spesso qualcosa come ssl.conf. Non conviene trattarlo come un blocco intoccabile: è solo una base da adattare al tuo dominio, ai certificati e alla policy di sicurezza. L’errore classico è lasciare la configurazione di esempio in produzione e poi aggiungere un secondo vhost senza capire quale dei due risponde davvero sulla 443.

La regola pratica è semplice: un solo punto di ingresso per ogni nome host, un solo certificato valido per quel nome, una sola definizione chiara del virtual host SSL. Se hai più siti sullo stesso server, usa SNI in modo pulito, non sovrapporre ascolti e non duplicare direttive a caso.

Configurare un virtual host HTTPS senza lasciare ambiguità

Una configurazione minimale e leggibile per un dominio singolo può stare in un file dedicato, ad esempio /etc/httpd/conf.d/example.com-ssl.conf. L’obiettivo non è copiare un template lungo, ma rendere esplicito dove vive il certificato, quale document root viene servita e come si gestisce il redirect da HTTP a HTTPS.

<VirtualHost *:443> ServerName example.com ServerAlias www.example.com DocumentRoot /var/www/example.com/public_html SSLEngine on SSLCertificateFile /etc/pki/tls/certs/example.com.crt SSLCertificateKeyFile /etc/pki/tls/private/example.com.key SSLCertificateChainFile /etc/pki/tls/certs/example.com-chain.crt <Directory /var/www/example.com/public_html> AllowOverride All Require all granted </Directory>
</VirtualHost>

Quel frammento è volutamente essenziale. In produzione spesso preferisco separare il redirect HTTP in un vhost dedicato sulla 80, così il comportamento è chiaro e non dipende da rewrite sparsi nel sito principale.

<VirtualHost *:80> ServerName example.com ServerAlias www.example.com Redirect permanent / https://example.com/
</VirtualHost>

Se usi rewrite più complessi, va bene, ma il redirect semplice è più prevedibile e riduce il rischio di loop. Dopo ogni modifica, il controllo non è “se il file è bello”, ma se Apache lo accetta e risponde sulla porta giusta.

Certificati: dove metterli e cosa controllare davvero

Il certificato può arrivare da Let’s Encrypt, da una CA commerciale o da una PKI interna. Indipendentemente dalla fonte, Apache deve poter leggere il file della chiave privata e il file del certificato, e il percorso deve essere corretto nella configurazione. Su EL8 è frequente vedere errori non per colpa del certificato in sé, ma per permessi sbagliati o path incoerenti dopo un rinnovo.

Il controllo minimo sui file è questo:

ls -l /etc/pki/tls/certs/example.com.crt /etc/pki/tls/private/example.com.key

Il certificato pubblico può essere leggibile da tutti, la chiave privata no. Se la chiave è troppo aperta, Apache può rifiutarla o la policy di sicurezza può impedirne l’uso. Se invece il file non esiste, il problema è banale ma bloccante: il vhost non parte.

Per validare la relazione tra chiave e certificato, il controllo più utile resta un confronto con OpenSSL:

openssl x509 -noout -modulus -in /etc/pki/tls/certs/example.com.crt | openssl md5
openssl rsa -noout -modulus -in /etc/pki/tls/private/example.com.key | openssl md5

Gli hash devono coincidere. Se non coincidono, stai abbinando certificato e chiave diversi. Non è un dettaglio: Apache non può terminare TLS con una coppia incoerente.

Firewall e SELinux: i due punti che fanno perdere tempo quando si ignorano

Su AlmaLinux e Rocky, la 443 deve essere consentita nel firewall attivo. Se usi firewalld, il test è immediato:

sudo firewall-cmd --list-services
sudo firewall-cmd --list-ports

Se https non compare tra i servizi o 443/tcp non compare tra le porte, il traffico può arrivare fino al server ma non completare la connessione. L’apertura corretta, se necessaria, è una modifica reversibile:

sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

SELinux è l’altro classico. Se la document root o i certificati sono in percorsi non standard, Apache può fallire anche con permessi Unix apparentemente corretti. Il controllo minimo è leggere gli audit recenti:

sudo ausearch -m avc -ts recent

Se trovi denial relativi a httpd, non forzare tutto in permissive come scorciatoia permanente. Meglio correggere il contesto SELinux o usare i percorsi standard dove possibile. Per verificare il contesto dei file:

ls -Z /etc/pki/tls/certs/example.com.crt /etc/pki/tls/private/example.com.key

Se il contesto non è coerente, il fix va fatto in modo preciso, non con un giro di permissive che poi resta dimenticato in produzione.

Sequenza di verifica dopo l’installazione

La sequenza che uso di solito è sempre la stessa, perché riduce i falsi positivi e ti dice subito dove si rompe la catena.

1. Verifica pacchetti: rpm -q httpd mod_ssl. Atteso: entrambi installati.
2. Verifica modulo: httpd -M | grep ssl. Atteso: ssl_module presente.
3. Verifica sintassi: sudo apachectl configtest. Atteso: Syntax OK.
4. Verifica servizio: sudo systemctl restart httpd e poi sudo systemctl status httpd. Atteso: servizio attivo senza errori recenti.
5. Verifica porta: ss -ltnp | grep :443. Atteso: Apache in ascolto su 443.
6. Verifica risposta reale: curl -Ik https://example.com. Atteso: status 200, 301 o 302 coerente con il redirect previsto, certificato presentato correttamente.

Questo ordine conta. Se fai prima il restart e poi scopri che il certificato è errato, hai già introdotto rumore nei log. Se fai prima apachectl configtest, hai un segnale pulito e reversibile.

Errori tipici e lettura rapida dei sintomi

Se httpd non riparte dopo l’installazione di mod_ssl, la causa più probabile è un errore di configurazione nel file TLS, non il pacchetto in sé. Il comando da guardare è:

sudo journalctl -u httpd -xe

Nel log spesso trovi direttive non valide, path non trovati o problemi di lettura delle chiavi. Se vedi AH00526 o messaggi simili, il problema è quasi sempre nella sintassi o in una direttiva che Apache non riconosce nel contesto in cui l’hai messa.

Se invece il servizio è up ma la 443 non risponde dall’esterno, il sospetto si sposta su firewall, security group, routing o bilanciatori intermedi. In quel caso il test locale con curl -Ik https://127.0.0.1 o curl -Ik https://localhost ti dice subito se il problema è dentro il server oppure fuori.

Rollback pulito se qualcosa rompe il servizio

Installare mod_ssl di per sé è un cambio piccolo, ma la configurazione HTTPS può avere impatto diretto sul sito. Se dopo la modifica il servizio non sale, il rollback deve essere semplice: disabilitare il file di vhost problematico, ripristinare una copia nota buona della configurazione e riavviare solo dopo un configtest positivo.

sudo mv /etc/httpd/conf.d/example.com-ssl.conf /etc/httpd/conf.d/example.com-ssl.conf.disabled
sudo apachectl configtest
sudo systemctl restart httpd

Se il problema nasce dal pacchetto e vuoi tornare indietro, il rollback è più drastico ma sempre reversibile:

sudo dnf remove -y mod_ssl

Prima di farlo, però, verifica che non ci siano altri vhost o servizi che dipendono da quella configurazione. In una macchina con più domini, togliere mod_ssl significa spegnere ogni sito che termina TLS localmente.

Scelta pratica: quando usare la configurazione di default e quando no

La configurazione installata dal pacchetto è utile come base, ma raramente è quella finale. Se stai gestendo un singolo sito di test, puoi partire da lì e adattare i percorsi. Se sei in produzione, conviene definire un file dedicato per ogni dominio e tenere separati i blocchi HTTP e HTTPS. Questo rende più facile l’audit, il debug e il rollback.

Un dettaglio che vale spesso più di cento tweak: non mischiare file di esempio, redirect, certificati e rewrite nello stesso blocco senza una logica precisa. La configurazione TLS deve essere leggibile in pochi secondi, perché quando il sito è giù il tempo si perde proprio nel dover capire quale blocco stia davvero servendo traffico.

Conclusione operativa: installare mod_ssl è facile, gestirlo bene no

Su AlmaLinux 8 e Rocky Linux 8 l’installazione di mod_ssl è un’operazione rapida, ma il risultato corretto dipende da una catena completa: pacchetto, modulo, virtual host, certificato, permessi, firewall e verifica finale. Se tratti questi passaggi come una checklist tecnica e non come una routine da eseguire a memoria, riduci parecchio il rischio di portare in produzione un HTTPS che “sembra” configurato ma non lo è davvero.

La regola da tenere a mente è semplice: dopo ogni modifica, verifica sempre con un comando concreto e con una risposta attesa chiara. Se il comando non conferma il risultato, non andare avanti per inerzia. In ambito Apache/TLS, il debug fatto bene all’inizio vale più di tre riavvii e un certificato reinstallato a caso.