Come diventare la propria Certificate Authority (CA)

Sia che si voglia progettare un ambiente di prova il più possibile simile alla realtà, sia che si voglia proteggere (meglio) Checkmk nella intranet, sia che si voglia creare un ambiente di rete interno utilizzando TLD senza registrar (ad esempio, una rete Windows con Samba Active Directory), c'è solo una soluzione realistica: Un'autorità di certificazione indipendente che combini sicurezza e flessibilità. Seguendo questa procedura, è possibile creare un'infrastruttura di base in meno di un'ora.

La procedura per l'emissione di certificati SSL/TLS utilizzando una CA interna è particolarmente utile per gli ambienti di prova o per le reti a compartimenti stagni in cui i server Checkmk hanno un numero gestibile di utenti. È anche l'unico modo per ottenere certificati se si utilizza internamente uno dei cinque TLD riservati: .example, .invalid, .local, .localhost o .test. Questo è spesso il caso predefinito negli ambienti Windows (Samba) e diffuso ovunque per evitare sia la risoluzione dei nomi su Internet che l'instradamento verso Internet. Non esistono società di registrazione per questi domini, quindi non è possibile confermarne la proprietà.

In questo articolo vi mostreremo come costruire la vostra CA. Questa operazione può essere eseguita con le risorse on-board di Linux e richiede poche conoscenze preliminari. Il nostro esempio utilizza un dominio nel TLD .test, ma utilizzando la propria CA è possibile emettere certificati per qualsiasi dominio (anche esterno!).

Anche se una sola persona su un computer può eseguire tutte le azioni richieste, per illustrare la separazione dei ruoli nel processo di certificazione, avremo Carla come amministratore dell'autorità di certificazione, Bob come manutentore della chiave intermedia e infine Alice, l'amministratore che fa firmare i certificati del server. È possibile aumentare il numero di livelli intermedi secondo le proprie esigenze.

Note sulla sicurezza

• Questa guida non utilizza un elenco di revoca dei certificati (CRL, Certificate Revocation List). Tuttavia, negli ambienti di produzione più grandi, è consigliabile utilizzarne uno per poter revocare rapidamente la fiducia a qualsiasi chiave potenzialmente compromessa!
• Anche negli ambienti di prova è necessario utilizzare password forti e proteggere bene le chiavi private, perché la chiave CA utilizzata può essere usata per creare certificati per qualsiasi dominio. I sistemi che si fidano del certificato di una chiave "persa" sono quindi vulnerabili agli attacchi "man-in-the-middle"!

Creare le chiavi per la CA e il root certificate

Per motivi di sicurezza, Carla utilizza un notebook senza connessione a Internet per lavorare con la sua CA. Conservando il notebook in una cassaforte, esclude anche la possibilità che una terza persona vi installi un keylogger (hardware).

Poiché nel corso del lavoro con la CA si creano alcuni file con applicazioni diverse, è consigliabile utilizzare una struttura di directory con un nome univoco per questo compito. Carla la crea sotto /home/carla/ca:

carla@nb:~$ for d in certs newcerts crl private ; do mkdir -p ~/ca/$d ; done
carla@nb:~$ for f in index.txt serial ; do touch ~/ca/$f ; done

Nella cartella ~/ca/, inserisce un file ca.cnf, un esempio del quale è stato preparato e allegato alla fine di questo articolo. Carla crea quindi la chiave privata della CA, che memorizza in forma crittografata AES256 e fornisce con una lunga passphrase:

carla@nb:~$ cd ca
carla@nb:~/ca$ openssl genrsa -aes256 -out private/ca.key.pem 4096
Generating RSA private key, 4096 bit long modulus (2 primes)
.............++++
..........++++
e is 65537 (0x010001)
Enter pass phrase for private/ca.key.pem:
Verifying - Enter pass phrase for private/ca.key.pem:

Segue il root certificate, qui con una validità di dodici anni e due settimane - per maggiori informazioni sulla scelta dei periodi di validità si veda più avanti. Questo prende i parametri rilevanti per la posizione e l'organizzazione dal file di configurazione ca.cnf. Common Name e Email Address devono essere significativi:

carla@nb:~/ca$ openssl req -config ca.cnf  -new \
    -key private/ca.key.pem -x509 -days 4398 \
    -sha256 -extensions v3_ca -out certs/ca.cert.pem
Enter pass phrase for private/ca.key.pem:

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) [DE]:
State or Province Name [Bavaria]:
Locality Name [Munich]:
Organization Name [Stark Industries Ltd.]:
Organizational Unit Name []:
Common Name []: Stark Industries Root Certificate
Email Address []: carla@starkindustries.test

Carla verifica quindi il root certificate con il seguente comando:

carla@nb:~/ca$ openssl x509 -noout -text -in certs/ca.cert.pem
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            25:a0:77:02:e7:29:07:f7:b5:d5:ba:b5:a3:4e:2b:eb:b3:e7:a6:c0
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = DE, ST = Bavaria, L = Munich, O = Stark Industries Ltd., CN = Stark Industries Root Certificate, emailAddress = carla@starkindustries.test
        Validity
            Not Before: Feb 15 14:52:12 2022 GMT
            Not After : Mar 2 14:52:12 2034 GMT
        Subject: C = DE, ST = Bavaria, L = Munich, O = Stark Industries Ltd., CN = Stark Industries Root Certificate, emailAddress = carla@starkindustries.test
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                    00:d7:a9:89:94:dd:02:66:bf:fd:8e:c2:70:4b:d0:
[…]

Carla copia ora il file di configurazione ca.cnf e lo fornisce al suo collega Bob come modello. In questo modo, Bob dispone dei parametri appropriati, nonché del nome e della sede della società nella notazione corretta.

Il certificato intermedio

Bob è colui che si occupa quotidianamente dei certificati per la rete locale. Il suo compito è quello di utilizzare un certificato intermedio per firmare le chiavi dei server che gli amministratori gli inviano. A tale scopo, crea innanzitutto una struttura di directory e utilizza la cartella im (come intermediate) nella sua home directory:

bob@pc:~$ for d in certs newcerts crl private ; do mkdir -p ~/im/$d ; done
bob@pc:~$ for f in index.txt serial ; do touch ~/im/$f ; done

Nella cartella im, inserisce il file di configurazione ricevuto da Carla come im.cnf e vi modifica i percorsi dei file predefiniti della sua home directory e del suo ruolo. Crea anche una chiave privata che utilizzerà per i prossimi anni:

bob@pc:~$ cd im
bob@pc:~/im$ openssl genrsa -aes256 -out private/im.key.pem 4096

Il passo successivo consiste nel creare la Certificate Signing Request (CSR) per questa chiave; il suffisso del nome del file .csr è comunemente usato in questo caso:

bob@pc:~/im$ openssl req -config im.cnf -new -sha256 \
    -key private/im.key.pem -out certs/imbob.csr

[...]
Country Name (2 letter code) [DE]:
State or Province Name [Bavaria]:
Locality Name [Munich]:
Organization Name [Stark Industries Ltd.]:
Organizational Unit Name []:
Common Name []: Stark Industries Bobs Intermediate Certificate
Email Address []: bob@starkindustries.test

Il Common Name deve essere diverso da quello del root certificate. Anche in questo caso è necessario utilizzare un indirizzo e-mail accessibile. Bob porta il file imbob.csr nell'ufficio di Carla per una tazza di caffè. Carla prende il taccuino con la chiave della CA dalla cassaforte, copia il CSR di Bob nella sua cartella dei certificati e firma il CSR di Bob, con un periodo di validità di quattro anni e due settimane in questo esempio:

carla@nb:~$ cd ca
carla@nb:~/ca$ openssl ca -config ca.cnf \
    -extensions v3_intermediate_ca \
    -days 1476 -rand_serial -notext -md sha256 \
    -in certs/imbob.csr -out certs/imbob.pem

A questo punto viene richiesta la passphrase per la chiave, viene visualizzato il contenuto della Certificate Signing Request e viene creato il certificato intermedio dopo la conferma. Carla consegna ora a Bob i due file PEM ca.cert.pem (il certificato codificato PEM dell'Autorità di certificazione) e imbob.pem (il certificato intermedio), spegne il notebook e lo chiude in cassaforte. Tornato al computer, Bob inserisce entrambi i file nella cartella ~/im/certs.

Creare una chiave per il sito Checkmk

Alice è l'amministratrice dei server Checkmk interni alla Stark Industries Ltd. Per proteggere un nuovo server Checkmk, crea innanzitutto la chiave del server. In questo caso è pragmatico non usare una passphrase, cioè fare a meno di -des3 o -aes256, altrimenti si dovrebbe reinserire questa passphrase a ogni avvio del server. Per il nome del file, il nome host del server è il più appropriato.

alice@pc:~$ openssl genrsa -out checkmk.starkindustries.test.key 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
.................................++++
.......++++
e is 65537 (0x010001)

Segue la creazione del CSR. Anche in questo caso è necessario rispondere alle domande sull'organizzazione e sul dipartimento. È importante il Common Name, che deve corrispondere al nome host primario del server. Per tenere traccia, Alice nomina il file della chiave e il file CSR con il nome del server su cui entrambi sono utilizzati. Un file di configurazione è opzionale per Alice, che qui lo omette:

alice@pc:~$ openssl req -new -key checkmk.starkindustries.test.key \
    -out checkmk.starkindustries.test.csr

[...]
Country Name (2 letter code) [DE]:
State or Province Name [Bavaria]:
Locality Name [Munich]:
Organization Name [Stark Industries Ltd.]:
Organizational Unit Name []:
Common Name (e.g. server FQDN or YOUR name) []: checkmk.starkindustries.test
Email Address []: alice@starkindustries.test

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Il campo Challenge password può rimanere vuoto. Ora Alice crea un file di configurazione dell'estensione del certificato X509 V3, checkmk.starkindustries.test.ext:

/home/alice/checkmk.starkindustries.test.ext

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = checkmk.starkindustries.test
DNS.2 = monitoring.starkindustries.test

Importante: anche se si desidera utilizzare un certificato per un solo nome host, il file di estensione è obbligatorio per tutti i browser moderni. In questo caso conterrà una sola riga sotto [alt_names].

Con i due file checkmk.starkindustries.test.csr e checkmk.starkindustries.test.ext in suo possesso, Alice si auto-invita nell'ufficio di Bob per una tazza di tè macha. Bob utilizza ora il suo certificato intermedio per firmare la CSR che ha portato con sé e che sarà valida per un anno:

bob@pc:~$ cd im
bob@pc:~/im$ openssl x509 -CAcreateserial -req \
    -in certs/checkmk.starkindustries.test.csr \
    -CA certs/imbob.pem -CAkey private/im.key.pem \
    -out certs/checkmk.starkindustries.test.crt -days 365 \
    -sha256 -extfile certs/checkmk.starkindustries.test.ext

Alice riceve in cambio tre file da Bob: ca.cert.pem e imbob.pem rappresentano la catena di certificati e checkmk.starkindustries.test.crt è il certificato appartenente alla chiave del server checkmk.starkindustries.test.key. Alice può ora distribuire questi file sul server:

/etc/apache2/sites-enabled/default-ssl.conf
SSLEngine on
SSLCertificateKeyFile /etc/certs/checkmk.starkindustries.test.key
SSLCertificateChainFile /etc/certs/imbob.pem
SSLCertificateFile /etc/certs/checkmk.starkindustries.test.crt

Importare la CA

Durata della validità del certificato - e catene conseguenti

L'intera catena di certificati funziona solo finché tutti i certificati sono validi. Pertanto, è necessario tenere traccia dei periodi di validità e creare per tempo un nuovo certificato in ogni punto della catena. Se la durata del root certificate di Carla è di dodici anni e lei emette quindi certificati intermedi validi al massimo per quattro anni a Bob, deve emettere lei stessa un nuovo root certificate in tempo utile prima che scadano gli otto anni e utilizzarlo per la firma in futuro. Bob, invece, che emette certificati validi per un massimo di due anni, deve fermarsi a prendere un caffè con Carla ogni due anni per ottenere un nuovo certificato valido per altri quattro anni.

Alice sa che Bob può emettere solo certificati di server validi per due anni. Se Alice ha bisogno di molti certificati di server man mano che la Stark Industries si espande, Bob, in quanto titolare di un certificato intermedio per Alice, può emettere un altro certificato intermedio con una validità di due anni. In questo modo, Alice può assumere il ruolo di CA subordinata che emette certificati con validità di un anno. In questo caso, deve effettuare un check-in annuale con Bob.

Nell'esempio di configurazione allegato di seguito, l'SSLCertificateChainFile richiesto non è il certificato intermedio di Bob, ma una concatenazione dei certificati intermedi di Bob e Alice.

E i certificati compromessi?

A prima vista, le misure di sicurezza di Carla possono sembrare un po' paranoiche, ma i root certificate compromessi sono difficili da gestire, perché alla fine bisogna rimuovere il certificato da tutti i client che lo utilizzano. Per questo motivo, consigliamo di mettere al sicuro il certificato root anche in ambienti di test relativamente piccoli: non deve essere necessariamente il vostro notebook, spesso la chiavetta USB nella cassaforte è abbastanza sicura. La firma regolare può essere effettuata utilizzando il certificato intermedio.

In ambienti gestibili, Bob può conservare un elenco di certificati firmati con un particolare certificato intermedio e notificare agli amministratori dei server interessati la necessità di nuovi certificati quando un certificato IM è stato compromesso.

Questo è più difficile se Bob stesso si rivela inaffidabile perché, ad esempio, ha emesso certificati per domini altrui al fine di spiare il traffico contabile. Pertanto, in ambienti in crescita, è bene tenere un elenco di revoca dei certificati. Jamie Nguyen descrive molto bene i passi aggiuntivi necessari nel suo blog.

Appendice: Il file di configurazione ca.cnf