
- Simone Piccardi
- Luglio 2024
- Sistemi
Continuiamo la serie dei nostri tutorial, con un altro articolo dedicato ai programmi di ausilio alla gestione della suite di protocolli TLS/SSL (Transport Layer Security/Secure Socket Layer), indispensabili per la sicurezza dei servizi di rete per quanto riguarda la capacità di fornire connessioni protette, sia in termini di riservatatezza dei dati inviati, che di verifica del corretto corrispondente.
In questo articolo analizzeremo come gestire autonomamente i cosiddetti “certificati autofirmati“, chiamati così perché non sono validati dalla firma di una Certification Authority riconosciuta, ma si autoproclamano validi firmandosi con sé stessi.
Sono molte le configurazioni dei servizi installati dai pacchetti di una distribuzione (ad esempio Postfix per Rocky/RHEL 9, o Apache per Debian) che rendono disponibile l’uso di connessioni cifrate con TLS/SSL usando un certificato autofirmato, creato in fase di installazione degli stessi. In base alla distribuzione, il certificato che verrà generato e la corrispondente chiave privata potrtebbero trovarsi in specifiche directory, ad esempio su Rocky 9 vengono usate rispettivamente le directory /etc/pki/tls/certs
e /etc/pki/tls/private
, mentre su Debian le directory /etc/ssl/certs/
e /etc/ssl/private/
.
Non è però così scontato che i certificati generati automaticamente dai pacchetti, corrispondano sempre alle proprie esigenze, ad esempio potrebbe esserci la necessità di voler cambiare i dati relativi ai nomi utilizzati, o correggere il periodo di validità degli stessi o utilizzare diversi algoritmi crittografici e lunghezze delle chiavi.
In questo caso è possibile ricorrere al comando openssl
per riuscire, manualmente, ad effettuare la creazione di un certificato autofirmato. Questo è possibile attraverso una serie di passi che cominciano sempre con la creazione iniziale di una chiave privata, che sarà quella da cui poi si otterrà il certificato.
La chiave può essere generata con:
openssl genrsa -out server.key 4096
ed in questo caso si è generata una chiave RSA in formato PEM nel file server.key.
E’ importante comunque tenere sempre presente che la chiave deve esser protetta da lettura da parte di terzi, in caso contrario, chiunque potrà riutilizzare il certificato su una propria macchina, il programma infatti, la crea con permessi 0600
e consente eventualmente di cifrarla con una passphrase, indicando un algoritmo crittografico con cui farlo (con opzioni come -aes128
, -aes256
, -des3
, ecc.) ma per un certificato autofirmato non è questo il caso, perché dovrà essere utilizzata da un servizio in grado di poterla leggere all’avvio, senza la necessità della presenza di qualcuno che inserisca la passphrase.
Il parametro finale nell’esempio che abbiamo visto prima è la dimensione della chiave, che ndica il numero di bit, avendo scelto di creare una chiave RSA. Solitamente si preferisce utilizzare valori come 1024, 2048 (il default) o 4096. Valori inferiori a 2048 non sono ritenuti sufficientemente sicuri, si è scelto 4096 che al momento è considerato moltouno dei più sicuri.
Dopo aver predisposto la chiave, il passo successivo sarà la creazione di una richiesta di certificato; questo si fa con il comando openssl req
che richiederà tutte le informazioni da inserire nel certificato:
openssl req -key server.key -new -out server.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:IT State or Province Name (full name) [Some-State]:Italy Locality Name (eg, city) []:Firenze Organization Name (eg, company) [Internet Widgits Pty Ltd]:Truelite S.R.L. Organizational Unit Name (eg, section) []:IT Common Name (e.g. server FQDN or YOUR name) []:server.truelite.it Email Address []:info@truelite.it Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
In questa sezione è possibile inserire le proprie informazioni rispondendo alle singole richieste (premendo invio si accetta il default mostrato fra parentesi quadre).
Le ultime due richieste (‘extra’) possono essere anche lasciate vuote. Non sarà necessaria nessuna particolare protezione del file risultante, server.csr
, poichè, in questo caso, i dati della richiesta saranno pubblici.
Fino a questo punto i passi elencati sono gli stessi di quando si deve generare richiesta di certificato da inviare ad una Certification Authority commerciale, perché questa la firmi e ci restituisca un certificato validato. In tal caso le si invierà il file server.csr
nelle modalità previste dalla stessa.
Tuttavia, per creare il certificato autofirmato, sarà sufficiente usare la stessa chiave server.key
usata per firmare la richiesta server.csr
; e questo lo si può ottenere eseguendo il comando:
openssl x509 -in server.csr -out server.crt -req -signkey server.key -days 3650 Certificate request self-signature ok subject=C = IT, ST = Italy, L = Firenze, O = Truelite S.R.L., OU = IT, CN = server.truelite.it, emailAddress = info@truelite.it
dove l’opzione -days
indica la durata del certificato in giorni (che nel caso dell’esempio è di 10 anni). Il certificato viene creato nel file server.crt
ed anche in questo caso non è necessaria nessuna particolare protezione del file.
Infine, è importante ricordare sempre che l’uso di certificati autofirmati ha senso solo in caso di utilizzo privato, poichè questi non saranno mai accettati da nessun programma di uso generico, non essendo riconosciuti da alcuna Certification Authority pubblica. Ecco perchè per poterli usare è importante assicurarsi di essere sempre in grado di configurarne l’accettazione da parte dei client corrispondenti. Risultano comunque utili in tutti quei casi in cui, lavorando su una rete interna, tutto quello che interessa è la cifratura dei dati nelle connessioni di rete.
Qualora poi, un servizio dovrà essere esposto al pubblico, occorrerà ricorrere a dei certificati validi (si vedano i precedenti articoli su come ottenerli usando Let’s Encrypt 1^ parte e 2^ parte).
Per qualunque altra informazione o consulenza non esitate a contattarci sul nostro sito, compilando il form nella sezione contatti.
La redazione