OpenSSLSelfSigned » Cronologia » Versione 3
Versione 2 (Simone Piccardi, 20-05-2024 13:03) → Versione 3/4 (Simone Piccardi, 04-07-2024 16:35)
h1. Generare un certificato autofirmato con OpenSSL Diverse configurazioni dei servizi installati dai relativi pacchetti di una distribuzione (ad esempio Postfix per Rocky/RHEL su Rocky 9, o Apache per su Debian) rendono disponibile l'uso l'usi di connessioni cifrate cfirate con TLS/SSL all'installazione usando un certificato autofirmato creato in fase di installazione degli stessi. autofirmato. A seconda della distribuzione il certificato generato e la corrispondente chiave privata si possono trovare in specifiche directory, ad esempio su Rocky 9 vengono sono usate rispettivamente le nelle directory @/etc/pki/tls/certs@ e @/etc/pki/tls/private@, mentre su Debian le directory @/etc/ssl/certs/@ e @/etc/ssl/private/@. Non è detto però che i certificati generati automaticamente dai pacchetti corrispondano sempre alle proprie esigenze, ad esempio si potrebbe voler possono volerne cambiare i dati relativi ai nomi utilizzati, oppure o aggiustare alle proprio esigenze il periodo di validità degli stessi. In tal caso è possibile ricorrere al comando @openssl@ per effettuare manualmente la creazione di un certificato autofirmato. del certificato. Questo passa attraverso una serie di passi che partono sempre dalla creazione iniziale di una chiave privata che sarà quella da cui poi si otterrà il certificato, questa può essere generata con: <pre> openssl genrsa -out server.key 4096 </pre> Si tenga presente che la chiave deve esser protetta da lettura da parte di terzi, altrimenti chiunque potrà riusare il certificato sulla propria macchina, il programma 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 nel caso non è il caso di farlo, perché dovrà essere usata da un servizio che deve poterla leggere all'avvio senza la necessità della presenza di qualcuno che inserisca la passphrase. Il parametro finale nell'esempio precedente è la dimensione della chiave, che nel caso, avendo scelto di creare una chiave RSA, indica il numero di bit. In bit, ed in genere si usano valori come 1024, 2048 (il default) o 4096. Valori inferiori a 2048 non sono ritenuti sufficientemente sicuri, si è scelto 4096 che al momento è considerato molto sicuro. Una volta predisposta la chiave il passo successivo è la creazione di una richiesta di certificato; certificato (questi due passi sono gli stessi anche quando si deve fare una richiesta ad una Certification Authority commerciale); questo si fa con il comando @openssl req@ che chiederà tutte le informazioni da inserire nel certificato: <pre> 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 []: </pre> E' qui che si possono mettere le proprie informazioni rispondendo alle singole richieste (premendo invio si accetta il default mostrato fra parentesi quadre. Le ultime due richieste ('extra') possono essere vuote. In questo caso i dati della richiesta sono pubblici e non è necessaria nessuna particolare protezione del file risultante, @server.csr@. Fino a qui 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. Per L'ultimo passo è creare il certificato autofirmato invece basterà usare usando la stessa chiave @server.key@ precedente (@server.key@) per firmare la richiesta @server.csr@; (@server.csr@) ed ottenere il certificato, questo si fa eseguendo il comando: con: <pre> 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 </pre> dove l'opzione @-days@ consente di indicare 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. Si ricordi infine che l'uso di certificati autofirmati ha senso solo in caso di uso privato, in quanto questi non saranno mai accettati da nessuna programma di uso generico, non essendo riconosciuti da alcuna Certification Authority pubblica. Per questo pubblica, per cui per poterli usare ci si deve assicurare 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 un servizio debba essere esposto al pubblico occorrerà ricorrere a dei certificati validi (si veda [[UsareLetsEncrypt|questa pagina]] su come fare per usare Let's Encrypt).