Truedoc

h1. 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:

<pre>

$ openssl req -noout -modulus -in server-csr.pem

Modulus=B67A110FCE04C933C8A4C41BBC72E9BEB3BB2C887C2375C3BDF15F3356D82E16497A7790B1E6D28A09AA1FD7C6C5D8ABA78CC2A929D6A4AE514118ACC4942CAB91C397435433E6A8E2B0EE7DCC9B371D37043AB558CFEFBA58E4E6074325686AD8EB5C8AB33F409D2872067C6B3C02C1B8DBB0FE4881874988C8790B74A795B839AF751DF238C9B7662098735B4CE50D5987F7FDBA0C99320E0524B17CB066F1BB4D7FE2A10EE84233D092D74C1DCA017E4977900439DD96CF0436DE939F93550BBFA8385A72BF1AA2631E7A885AC653255397EFE986BA9465394F0D2C771D200AEBCA0CF3C5452C6EA4861E44E7227EE2167F294B9B4430D1923609A7ACCCCD

</pre>

mentre per la chiave si fa con:

<pre>

$ openssl rsa -noout -modulus -in server-key.pem 

Modulus=B67A110FCE04C933C8A4C41BBC72E9BEB3BB2C887C2375C3BDF15F3356D82E16497A7790B1E6D28A09AA1FD7C6C5D8ABA78CC2A929D6A4AE514118ACC4942CAB91C397435433E6A8E2B0EE7DCC9B371D37043AB558CFEFBA58E4E6074325686AD8EB5C8AB33F409D2872067C6B3C02C1B8DBB0FE4881874988C8790B74A795B839AF751DF238C9B7662098735B4CE50D5987F7FDBA0C99320E0524B17CB066F1BB4D7FE2A10EE84233D092D74C1DCA017E4977900439DD96CF0436DE939F93550BBFA8385A72BF1AA2631E7A885AC653255397EFE986BA9465394F0D2C771D200AEBCA0CF3C5452C6EA4861E44E7227EE2167F294B9B4430D1923609A7ACCCCD

</pre>

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:

<pre>

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

</pre>

se l'abbinamento è corretto si otterrà:

<pre>

Using default temp DH parameters

Using default temp ECDH parameters

ACCEPT

</pre>

altrimenti si otterrà:

<pre>

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:

</pre>

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:

<pre>

# openssl verify server-interm.pem 

server-interm.pem: OK

</pre>

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

<pre>

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

server-cert.pem: OK

</pre>

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:

<pre>

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

server-cert.pem: OK

</pre>

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:

<pre>

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

</pre>

e nel caso di catena di certificati invece: 

<pre>

cat server-cert.pem ca-bundle.pem > server-chained.pem

</pre>

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:

<pre>

# 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

</pre>

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.