Garantire la sicurezza dei messaggi di posta elettronica e delle comunicazioni in Internet è una priorità. Per farlo, si utilizzano algoritmi di crittografia che consentono di inviare messaggi cifrati, che potranno essere letti solo da destinatario e che non possano essere decifrati anche se dovessero essere intercettati durante la trasmissione in rete. Le comunicazioni via web avvengono basandosi sull’utilizzo di appositi protocolli ritenuti sicuri, come i certificati SSL, che offrono una connessione criptata tra server e browser, creando una cosiddetta “firma digitale”. O ancora, ricorrendo al protocollo SSH, che permette di stabilire una connessione sicura e diretta tra due computer della rete Internet. Archiviare le chiavi di rete e i certificati digitali richiede l’impiego file di testo specifici, che garantiscano la riservatezza e l’integrità delle informazioni e dei dati che viaggiano in rete, e tra questi una delle estensioni più usate sono i file PEM. Ecco cosa sono e a cosa servono.
I file PEM nascono come standard di sicurezza della posta elettronica, e consentono di mantenere la riservatezza, impedendo a chi non è autorizzato l’accesso alle informazioni, e l’integrità dei dati che vi sono contenuti.
In alcuni casi, i file in formato PEM potrebbero utilizzare un’estensione di file diversa, come ad esempio .cer o .crt per i certificati, oppure .key per le chiavi pubbliche o private. Anche se l’estensione appare diversa, i file PEM appariranno in questo modo se aperti con un programma di visualizzazione di testo:
-----BEGIN -----
testo
-----END -----
Dove il tipo di file potrà essere una chiave crittografica RSA per protocollo SSH, oppure un certificato da usare per la crittografia SSL. Il testo interno tra “begin” ed “end” è codificato in base64 e forma un blocco di dati che può essere utilizzato anche per altri programmi. Va ricordato poi che un singolo file .pem può contenere al suo interno anche più blocchi di testo, e quindi più certificati.
Prima di tutto, viene assegnato al nome del dominio dell’utente finale un certificato di autorità (Certificate Authority, CA), cioè il file che viene usato da nginx e Apache per crittografare il protocollo HTTPS. Poi vengono emessi quattro certificati intermedi facoltativi, che le autorità principali danno a quelle secondarie. Infine, viene generato il certificato root, quello che occupa il posto principale della catena, perché è firmato digitalmente dall’autorità primaria CA. Ogni file PEM così generato per un certificato SSL apparirà nel seguente modo:
-----Begin certificate -----
testo certificato finale per utente
-----End certificate-----
----- Begin certificate -----
testo certificati intermedi opzionale
----- End certificate -----
----- Begin certificate -----
testo certificato di root
----- End certificate -----
A fornire questi file è il provider SSL a cui l’utente finale si connette per accedere al proprio browser web. Al termine della catena, l’utente potrà attendersi la generazione di almeno 4 file con estensione .pem:
Quando si vuole avviare una chiave crittografica del tipo SSH, l’utente dovrà eseguire il comando ssh-keygen per creare, gestire e convertire le chiavi generate, che saranno contenute proprio in un file .pem, come “id-rsa”. Ad esempio, Amazon Web Services fornisce un file PEM che contiene una chiave privata ogni volta che l’utente crea una nuova istanza, e per eseguire SSH in nuove istanze bisognerà utilizzare questa chiave al posto di “id-rsa”. Per farlo, bisogna utilizzare un apposito flag-i e digitare il testo
ssh -i keyfile.pem root@host
Questa stringa di codice permette di accedere al server normalmente, ma ogni volta va specificato il flag. In alternativa, gli utenti possono generare una chiave privata con il proprio ssh-agent attraverso ssh-add, eseguendo il codice
ssh-add keyfile.pem,
che però non viene salvato in caso di riavvio del dispositivo, quindi dovrà essere eseguito dopo ogni reboot. La soluzione finale per poter usare il protocollo SSH senza dover ogni volta aggiungere la propria chiave pubblica è quella di inserire l’istanza
~/.ssh/authorized_keys
che continuerà a funzionare per qualsiasi nuova istanza di crittografia che verrà inserita in futuro dopo il primo accesso.