Oggi uno degli aspetti fondamentali relativi alla sicurezza dei servizi sulla rete è 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 consente di usare i certificati SSL e viene impiegata ad esempio per realizzare l’accesso ai siti con “https”. 

Al di là dell’uso 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 in cui esamineremo come utilizzare questi “attrezzi di lavoro”, forniti dal pacchetto openssl.

Quando si lavora nella gestione di certificati SSL con file in formato .pem , quello più diffuso, può capitare di confondere i vari file, specie 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 si può  non essere più sicuri di aver associato correttamente un certificato alla sua chiave, o comunque se ne può voler 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:

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

Questo si può fare con il comando verify della suite di openssl, percorrendo la catena di certificazione. Il caso più comune è 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.

Una volta stabilita la correttezza e la corrispondenza di tutti i file, si deve 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. Si tenga presente che l’ordine conta: si deve seguire all’indietro la catena, dal proprio certificato fino a quello pubblico della Certification Authority, omettendo quest’ultimo.

Infine una volta configurato il servizio se ne potrà 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). Si noti come 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