Uno degli aspetti fondamentali relativi alla sicurezza dei servizi sulla rete oggi è quello del ricorso all’uso di connessioni adeguatamente protette, sia in termini di verifica del corretto corrispondente, che di  riservatatezza dei dati inviati.

Questo viene realizzato nella gran parte dei casi facendo ricorso alla suite di protocolli denominata TLS/SSL (Transport Layer Security/Secure Socket Layer), che permette di utilizzare i certificati SSL e viene impiegata ad esempio per realizzare l’accesso ai siti con “https”. 

Oltre all’utilizzo per il web, questa suite di protocolli viene impiegata da una grande varietà di servizi (posta elettronica, VPN, chat, ecc.), e la sua realizzazione è ormai quasi sempre basata sul software sviluppato dal progetto OpenSSL, che fornisce anche una serie di tool a riga di comando che sono essenziali in fase di configurazione e di diagnostica di eventuali problematiche. 

Questo articolo è il primo di una serie di articoli, in cui esamineremo in che maniera utilizzare questi “attrezzi di lavoro”, forniti dal pacchetto openssl.

Quando si lavora nella gestione di certificati SSL con file in formato .pem , che è il formato più diffuso, può capitare di confondere i vari file, soprattutto quando arriva il momento di cambiare i certificati su un server, ad esempio perché i certificati precedenti sono scaduti, non è usato Let’s Encrypt, che consente una gestione automatica, ed il fornitore da cui li abbiamo acquistati ci ha mandato quelli rinnovati. In questi casi potremmo non essere più sicuri di aver associato correttamente un certificato alla sua chiave, o comunque potremmo volerne verificare il funzionamento. 

La modalità più immediata per verificare che il certificato contenuto nel file server-cert.pem sia effettivamente quello associato alla chiave contenuta nel file server-key.pem è quella di usare il comando s_server della suite di openssl, in pratica basta eseguire:

openssl s_server -cert server-cert.pem -key server-key.pem 

se l’abbinamento è corretto si otterrà:

Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT

altrimenti si otterrà:

Using default temp DH parameters
Using default temp ECDH parameters
error setting private key
26606:error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch:x509_cmp.c:406:

E’ importante considerare che se, come avviene ormai da parte di tutte le Certification Authority, un certificato è stato firmato da un certificato intermedio, l’associazione fra quest’ultimo e la chiave non è sufficiente a garantirne la sua validità nell’utilizzo da parte di un servizio, occorre anche vericare la correttezza di tutta la catena di certificazione. 

Questo è possibile ottenerlo attraverso il comando verify della suite di openssl, percorrendo la catena di certificazione. Il caso più frequente è quello in cui esiste un solo passo attraverso un certificato intermedio server-interm.pem fornito dalla propria Certification Authority insieme al certificato firmato server-cert.pem.

In questo caso occorrerà prima verificare la validità generale del certificato intermedio con:

# openssl verify server-interm.pem 
server-interm.pem: OK

e poi per verificare il certificato finale utilizzando il certificato intemedio con:

# openssl verify -CAfile server-interm.pem server-cert.pem
server-cert.pem: OK

dove appunto con -CAfile si indica di voler usare server-interm.pem per la verifica e non il default, che significa fare riferimento ai certificati delle Certification Authority riconosciute. Questi su Debian sono installati sotto /etc/ssl/certs/ che è dove vengono cercati dai default del comando, ma qualora fossero altrove anche nel primo comando si sarebbe dovuto specificarlo con l’opzione -CApath.

Quando avremo stabilito la correttezza e la corrispondenza di tutti i file, si dovrà tener presente che molti server richiedono che nel file del certificato (quello da indicare ad esempio nelle direttive smtpd_tls_cert_file di Postfix o ssl_cert di Dovecot) venga inserito non il certificato finale, ma tutta la catena, pertanto si dovrà creare un file contenente tutti i certificati della catena di certificazione con qualcosa come:

cat server-cert.pem server-interm.pem > server-chained.pem

ed usare server-chained.pem nelle direttive citate. E’ importante tenere sempre presente che l’ordine conta: si deve risalire all’indietro la catena, dal proprio certificato fino a quello pubblico della Certification Authority, omettendo quest’ultimo.

Alla fine, dopo che avremo configurato il servizio, ne potremo controllare il funzionamento e la correttezza dei certificati installati, con il comando s_client di openssl; ad esempio per verificare il funzionamento di Postfix si potrà usare il comando:

# openssl s_client -connect localhost:25 -starttls smtp -CApath /etc/ssl/certs/
CONNECTED(00000003)
[...]
    Compression: 1 (zlib compression)
    Start Time: 1415887713
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
250 DSN

avendo cura di indicare con -starttls il tipo di protocollo usato quando si opera con STARTLS (altri valori possibili sono pop3, imap e ftp). Bisogna notare che in questo caso è necessario indicare con -CApath la directory dove sono mantenuti i certificati delle Certification Autority riconosciute.

Speriamo che questo primo articolo sulle chiavi SSL sia stato utile e vi consigliamo di continuare a seguirci per rimanere aggiornati e informati su tutte le novità del settore.

In ogni caso per qualsiasi ulteriore informazione o consulenza, potete contattarci sul nostro form Contatti – Not Just A Cloud .

                                                                                                    La redazione