Verificare chiavi e certificati nelle configurazioni di SSL/TLS¶

Quando si lavora con file .pem nella gestione di certificati SSL, specie se si cambiano i certificati su un server, può capitare di confondere i file, e non essere più sicuri di aver associato correttamente un certificato o una richiesta di certificato alla sua chiave.

Per verificare che una richiesta di certificato (una CSR) server-csr.pem corrisponda alla rispettiva chiave server-key.pem occorre stampare il "modulo" di entrambe e verificare che corrisponda; per la CSR questo si fa con:

$ openssl req -noout -modulus -in server-csr.pem
Modulus=B67A110FCE04C933C8A4C41BBC72E9BEB3BB2C887C2375C3BDF15F3356D82E16497A7790B1E6D28A09AA1FD7C6C5D8ABA78CC2A929D6A4AE514118ACC4942CAB91C397435433E6A8E2B0EE7DCC9B371D37043AB558CFEFBA58E4E6074325686AD8EB5C8AB33F409D2872067C6B3C02C1B8DBB0FE4881874988C8790B74A795B839AF751DF238C9B7662098735B4CE50D5987F7FDBA0C99320E0524B17CB066F1BB4D7FE2A10EE84233D092D74C1DCA017E4977900439DD96CF0436DE939F93550BBFA8385A72BF1AA2631E7A885AC653255397EFE986BA9465394F0D2C771D200AEBCA0CF3C5452C6EA4861E44E7227EE2167F294B9B4430D1923609A7ACCCCD

mentre per la chiave si fa con:

$ openssl rsa -noout -modulus -in server-key.pem 
Modulus=B67A110FCE04C933C8A4C41BBC72E9BEB3BB2C887C2375C3BDF15F3356D82E16497A7790B1E6D28A09AA1FD7C6C5D8ABA78CC2A929D6A4AE514118ACC4942CAB91C397435433E6A8E2B0EE7DCC9B371D37043AB558CFEFBA58E4E6074325686AD8EB5C8AB33F409D2872067C6B3C02C1B8DBB0FE4881874988C8790B74A795B839AF751DF238C9B7662098735B4CE50D5987F7FDBA0C99320E0524B17CB066F1BB4D7FE2A10EE84233D092D74C1DCA017E4977900439DD96CF0436DE939F93550BBFA8385A72BF1AA2631E7A885AC653255397EFE986BA9465394F0D2C771D200AEBCA0CF3C5452C6EA4861E44E7227EE2167F294B9B4430D1923609A7ACCCCD

se i due output sono identici, come nell'esempio, la corrispondenza è verificata.

Invece la modalità più immediata per verificare che il certificato server-cert.pem sia effettivamente un certificato associato alla chiave 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 l'associazione fra certificato e chiave non è sufficiente, occorre anche verificare 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à 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 usare server-interm.pem per la verifica e non il default che su Debian è fare riferimento ai certificati delle Certification Authority riconosciute installati sotto /etc/ssl/certs/ (qualora fossero altrove nel primo comando si sarebbe dovuto specificarlo con l'opzione -CApath).

Oggi però è diventato comune usare non un singolo certificato intermedio, ma una catena di certificati, vale a dire distribuire in un singolo file una catena di certificati intermedi (un cosiddetto CA-Bundle) in cui il primo viene verificato dal secondo, il secondo dal terzo e così via (anche se raramente si va oltre il terrzo). In questo caso occorrerebbe scomporre il file nei singoli certificati e verificarli uno per uno, la cosa è lunga e tediosa, ma per fortuna è disponibile l'opzione -untrusted a cui passare il file della catena che fa tutto il lavoro di scansione della stessa e permette di verificare il certificato, in tal caso si potrà ottenere la verifica con:

# openssl verify -untrusted ca-bundle.pem server-cert.pem
server-cert.pem: OK

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 nell'ordine in cui questa viene percorsa, per cui nel caso di certificato intermedio singolo si dovrà esegure:

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

e nel caso di catena di certificati invece:

cat server-cert.pem ca-bundle.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 della Certification Authority, eventualmente 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.