Frame buffer con Grub e Grub 2

Oggi trattiamo un aspetto puramente estetico, ovvero la risoluzione della console all'avvio della macchina.
Normalmente un sistema Debian, di default, viene installato e configurato per essere il più possibile compatibile con tutto l'hardware presente sul mercato, quindi la risoluzione della console viene impostata a valori molto bassi (640x480) per poter funzionare su qualunque monitor, ma questo fa sì che anche l'interfaccia testuale abbia un numero limitato di righe e colonne (80x24 se ricordo giusto).
A me questa risoluzione risulta troppo scarsa per poter lavorare adeguatamente, quindi voglio sempre aumentare la risoluzione aumentando di conseguenza il numero di righe e colonne di testo visualizzabili. Per far questo si deve modificare il file di configurazione di grub; questo file è diverso a seconda della versione di grub:

• /boot/grub/menu.lst per grub 1 aggiungendo il parametro vga nelle opzioni di avvio del kernel (ricordatevi di modificare la linea corretta, ovvero non quella che riguarda il single-user mode);
• /boot/grub/grub.cfg per grub 2 modificando il parametro gfxmode e gfxpayload.

In grub 1 le varie modalità video sono identificate da valori esadecimali (0x) in base alla propria scheda video; per conoscere le modalità disponibili ed i valori associati si utilizza il comando vbeprobe dalla modalità a linea di comando di grub (vi si entra premendo 'c' durante la visualizzazione del menù) e, una volta identificata la modalità desiderata, la si testa con vbetest. Se tutto viene visualizzato correttamente si può procedere con i calcoli necessari a ricavare il valore da associare al parametro vga.
Il valore da impostare al parametro vga da inserire come opzione alla stringa di avvio del kernel si ottiene partendo dal valore esadecimale di proprio interesse (ad esempio 0x144), a questo si aggiunge 0x200 (ottenendo 0x344, in decimale 836), il nuovo valore così ottenuto in genere è del tipo 0x3..; questo è il valore da assegnare al parametro vga specificandolo come vga=0x3.. oppure vga=8.. (valore decimale).
La nuova linea di avvio all'interno di grub sarà del tipo:

• kernel /boot/vmlinuz-x.y.z root=/dev/hda1 ro quiet vga=0x344

Fate attenzione a modificare la linea corretta, ovvero non quella di failsafe o single user mode.
In grub 2 le impostazioni sono molto più semplici ed i parametri sono in formato "uman readable", ovvero la stringa del valore e del tipo RisoluzioneOrizzontalexRisoluzioneVerticalexBitDiColore; i parametri coinvolti in questo caso sono due: gfxmode, che stabilisce la risoluzione durante la visualizzazione del menù di avivo, e gfxpayload, che tsabilisce la risoluzione da visualizzare in modalità testuale. Ad esempio, per avere tutte le risoluzioni a 1024x768 con una profondità di colore a 32 bit si dovranno aggiungere le seguenti linee:

• set gfxmode=1024x768x32
• set gfxpayload=1024x768x32

Direi che per oggi è tutto, buon divertimento con le nuove risoluzioni.

Collegarsi da fuori alla rete di casa? openVPN!

Ora che abbiamo parlato dei certificati possiamo cominciare ad utilizzarli; probabilmente questo utilizzo non è quello più semplice che una persona possa immaginare, ma sicuramente è uno di quelli che permette di capire le potenzialità offerte dalla struttura di certificati di tipo X.509.
Tralasciando la parte relativa alla creazione dei certificati che ormai è stata ampiamente trattata, vi annuncio solamente che l'autenticazione avviene attraverso i certificati X.509, quindi per il server e per ogni client sarà necessario avere a disposizione un certificato, garantito dalla propria CA, con la relativa chiave privata. Due comandi che potrebbero farvi comodo per abbreviare i processi di creazione dei certificati, in caso di creazioni massive, sono i seguenti (dovete posizionarvi all'interno della directory della CA):

• openssl req -new -keyout private/host-utente.unsec.key -out newcerts/host-utente.pem.csr -nodes -text -config ../openssl.conf -subj /"C=IT"/"ST=Provincia"/"L=Città"/"O=Organizzazione"/"OU=openVPN organizzazione"/"CN=utente"/"emailAddress=indirizzo di posta"/
• openssl ca -policy policy_anything -in newcerts/host-utente.pem.csr -out certs/host-utente.pem.crt -config ../openssl.conf -batch -days 1465

Ora veniamo alla parte più complessa, le configurazioni del server e dei client, ma prima di procedere vi devo descrivere la struttura di funzionamento su cui si basa openVPN (considerate che alcune assunzioni sono relative solamente alla mia metodologia di configurazione e vi sono altre possibilità):

• l'autenticazione avviene SOLAMENTE attraverso i certificati firmati dalla stessa CA;
• l'assegnazione degli indirizzi viene fatta in base al certificato presentato dal client, quindi se il file di configurazione per il client non è stato creato non è possibile collegarsi alla VPN perchè non viene assegnato l'indirizzo;
• la default route rimane quella presente anche prima dell'attivazione della VPN;
• solamente le macchine per cui viene specificato il routing sono raggiungibili (questo per limitare le possibilità di conflitto degli indirizzi).

A questo punto creiamo il file di configurazione del server che sarà /etc/openvpn/host-server.conf:
daemon
mode server
tls-server
dev-node /dev/net/tun
dev tun1194
proto udp
port 1194
tun-mtu 1250
ifconfig 10.0.0.1 10.0.0.2
client-config-dir /etc/openvpn/CN2ip
route 10.0.0.0 255.255.255.0
push "route 10.0.0.1 255.255.255.255"
client-to-client
dh /etc/openvpn/certs/dh1024.pem
ca /etc/ssl/YOUR_CA/CA.pem
cert certs/host-server.pem.crt
key certs/host-server.unsec.key
user nobody
group nogroup
persist-key
persist-tun
comp-lzo
keepalive 20 90
verb 1
log-append /var/log/openvpn/server.log
mssfix
Ora spiego i paratetri principali... il parametro daemon, mode server, tls-server e quelli realtivi al tun significano di eseguire openVPN come servizio, di abilitare le modalità server, di creare ed utilizzare utilizzare l'interfaccia tun1194 ed associargli l'mtu dichiarato.
I parametri proto, port, persist-key, persist-tun, comp-lzo e keepalive specificano il protocollo, la porta di servizio, la persistenza della chiave privata e dell'interfaccia tunnel (in caso di restart non vengono reiniziallate), la compressione ed il keepalive, ovvero ogni quanti secondi, dopo che non vi è traffico, inviare dei dati e quanto aspettare prima di riavviare il tunnel se non vi è risposta... parlando di standard imposti dallo IANA, openVPN è stato attestato sulla porta 1194 e con protocolli TCP/UDP. La scelta del protocollo può essere influenzata principalemente da due fattori, la facilità di attraversamento dei firewall per il protocollo UDP o la possibilità di utilizzare il protocollo TCP (modalità tcp-server/tcp-client) per tunnellizzare le connessioni (ad esempio tramite ssh).
I parametri ifconfig e route assegnano l'indirizzo ip e le informazioni di routing all'interfaccia rete creata, mentre client-to-client permette a client di vedersi a vicenda.
Le impostazioni scritte in formato push sono invece relative ai comandi da inviare indistintamente ad ogni client che si collega; siccome può capitare, e nel caso di indirizzo ip statico capita sicuramente, di dover inviare informazioni specifiche a client identificati, l'opzione che ci fa comodo è client-config-dir, e rappresenta il percorso in cui devono essere presenti i file con le configurazioni personalizzate. All'interno di questa directory, i file vengono collegati al loro destinatario attraverso il nome, questo deve essere lo stesso presente all'interno del CN ed in caso di spazi il carattere viene sostituito con l'underscore (_).
Ad esempio, se noi vogliamo che chi si presenta con un certificato valido con CN "Mario Bianchi" abbia un determinato indirizzo IP assegnato, dovremo creare il file /etc/openvpn/CN2ip/Mario_Bianchi con al suo interno i seguenti comandi:
ifconfig-push 10.0.0.14 10.0.0.13
# push "route 192.168.0.127 255.255.255.255" # Indirizzo da raggiungere attraverso la VPN
Ricordate che ogni client in connessione occupa una classe di tipo /30, ovvero ip di network, ip del client, ip del peer, ip di broadcast, quindi equivale dire 4 indirizzi ip... affinchè non vi siano errori di rete dovuti a sovrapposizioni, i client potranno solamente avere indirizzi ip 10.0.0.6, 10.0.0.10, 10.0.0.14...
Le opzioni ca, cert e key non dovrebbero aver bisogno di spiegazioni, sono i parametri relativi alla CA ed al certificato presentato dal server; l'unico parametro non noto e relativo alla crittografia è dh, che deve essere un file di tipo Diffie Hellman; per generarlo potete utilizzare il seguente comando:

• openssl dhparam 1024 > /etc/openvpn/certs/dh1024.pem

I parametri user, group, verb e log-append specificano le modalità con cui il tunnel deve funzionare, ovvero i permessi con cui girare e quante informazioni di debug devono essere presenti all'interno del file di log.
Ora, se avete terminato la configurazione e l'avete terminata in maniera corretta potete provare a vedere cosa succede avviando la openVPN con:

• /etc/init.d/openvpn restart

Se tutto ha funzionato ora avete un processo openVPN che è in esecuzione... adesso non rimane che configurare i client.
Il file di configurazione di un client è molto simile a quello per il server, ma mancano le informazioni per l'assegnazione dei parametri di rete che devono essere prelevate dal server, inoltre in genere la maggior parte dei client normalmente sono machcine windows, quindi file di configurazione con estensione ovpn, certificato e chiave saranno in un'unica cartella; un file di esempio è il seguente:
pull
tls-client
dev tun
proto udp
remote server-host port
remote server-ip port
tun-mtu 1250
resolv-retry infinite
nobind
ca ./hostCA.crt
cert ./host-nome.pem.crt
key ./host-nome.unsec.key
persist-key
persist-tun
ping 30
ping-restart 90
comp-lzo
mssfix
verb 1
Adesso vi spiego i nuovi parametri apparsi... pull e tls-client significano di richiedere le informazioni di configurazione al server ed il tipo di autenticazione utilizzata, remote è una lista di host/ip seguiti dalla porta che dovrebbe essere in ascolto a cui il client continuerà a provare a collegarsi all'infinito.
Siccome la maggior parte dei client saranno macchine windows (od almeno questa è la mia esperienza), affinchè il file di configuraizone venga riconosciuto come tale, deve avere estensione ovpn; inoltre, sotto windows, è molto più semplice mettere tutti i file relativi ad una VPN in una singola cartella (file.ovpn, file.unsec.key, file.crt e fileCA.crt) per non dover specificare percorsi assoluti che potrebbero cambiare con lo spostamento della directory.
Il parametro nobind impedisce ad openVPN di posizionarsi in ascolto, ma fa sì che la connessione alla VPN venga solamente tentata e non attesa, mentre ping e ping-restart fanno sì che avvenga un ping ogni tot secondi e se non si riceve risposta il tunnel viene reinizializzato.
Ultima cosa da notare... non c'è l'informazione relativa al file di log, sappiate che se abilitate il log su file non sarete più in grado di vederlo a video se siete su di una macchina windows.
Direi che a questo punto potete provare la connessione da un client, ricordatevi che il certificato della CA deve essere presente assieme ai file relativi al client, questo perchè openVPN controlla che il server sia effettivamente colui che ci si aspetta e quindi il suo certificato deve essere firmato dalla stessa CA.
Con questo penso di aver trattato tutto il minimo necessario per fare una VPN con determinate caratteristiche; la configurazione di esempio che ho utilizzato è quella che utilizzo più spesso dato che consente di vincolare univocamente un indirizzo IP ad un determinato certificato, sappiate che comunque è possibile creare una VPN in maniera che chiunque si presenta con un certificato valido riceva un indirizzo come se fosse presente un DHCP. Di sicuro cercando su internet troverete molte informazioni più dettagliate ed altre modalità di funzionamento, ma il mio voleva essere solamente un vademecum di come mettere su una VPN, in maniera veloce ed indolore, con autenticazione tramite certificati ed indirizzi ip statici.

Creare i certificati X.509

Bene, ora è giunto il momento di creare la nostra gerarchia di certificati, ma prima di fare questo guardiamoci un attimo attorno per capire come funzionano le cose fatte dai grandi gestori... se prendessimo come esempio le CA riconosciute ufficialmente, osserveremmo che loro richiedono solamente la richiesta di certificato, a cui applicano la firma, per poter poi restituire il certificato; questo viene fatto ai fini di sicurezza dato che voi, i proprietari della chiave privata, volete che NESSUNO sia in grado di venire a conoscenza dei dati che transitano; logicamente se generassero loro la vostra richiesta di certificato, avrebbero generato anche la chiave privata, e quindi la conoscerebbero; inoltre ve la dovrebbero trasmettere, esponendo la chiave privata a possibili sguardi inopportuni e riducendo largamente la sicurezza del sistema creato.
Nel nostro caso le cose si semplificano di molto dato che do per assunto una situazione prestabilita (che riduce altamente la sicurezza in caso di compromissione del server, ma non facendo transazioni bancarie lo ritengo un rischio accettabile): la chiave privata verrà utilizzata da servizi presenti sulla stessa macchina che gestisce la CA, quindi entrambe le chiavi possono risiedere a bordo di questa e gli unici occhi che le possono leggere sono i nostri (sempre che abbiate protetto bene il server).
Per generare la coppia di chiavi, ovvero la chiave privata e la richiesta di certificato (che contiene quella pubblica), eseguire la firma con la CA ed ottenere quindi il certificato, si può utilizzare il seguente script in /etc/*/makeCert.sh:

#!/bin/bash

# Script per la creazione della coppia chiavi pubblica/privata, per la generazione della richiesta di certificato, per la firma della richista trmaite la CA e per la generazione del certificato.
function newCert {
echo -n "Vuoi generare una chiave privata senza password? (s/N) ";
read ANS;
case ${ANS} in
"S"|"s"|"Y"|"y") echo "Attenzione, la chiave privata sara' leggibile da chiunque!";
openssl req -config ${opensslConf} -new -text -nodes -keyout ${CApath}/private/${NOME}.key -out ${CApath}/certs/${NOME}.pem.req;
;;
"N"|"n"|"") echo "Attenzione, ad ogni accesso alla chiave privata si dovra' fornire la password!";
openssl req -config ${opensslConf} -new -text -keyout ${CApath}/private/${NOME}.key -out ${CApath}/certs/${NOME}.pem.req;
echo "Per la rimozione della password usare il seguente comando: openssl rsa -in ${CApath}/private/${NOME}.key -out ${CApath}/private/${NOME}.unsecure.key";
;;
esac;
}
opensslConf=$(find /etc -iname openssl.cnf|sort|head -1);
CApath=$(grep "^[[:space:]]*dir[[:space:]]*=" ${opensslConf} | sed "s/.*=\s\+//" | awk '{print $1}');
if [ "$1" == "" ]; then
echo "La sintassi del comando e' $0 <nome_cert>";
exit -1;
fi;
NOME=$1;
if [ -s "${CApath}/newcerts/${NOME}.pem.crt" ]; then
echo "E' gia' presente il certificato ${CApath}/certs/${NOME}.pem.crt, vuoi rinnovarlo revocandolo ed emettendone uno nuovo [s/N]? ";
read ANS;
case ${ANS} in
"S"|"s"|"Y"|"y") echo "Verra' ora revocato il certificato";
openssl ca -config ${opensslConf} -revoke ${CApath}/newcerts/${NOME}.pem.crt
;;
"N"|"n"|"") echo "Si e' deciso di non revocare il certificato precedente, si potra' proseguire solamente sovrascrivendo i vecchi dati, ricordati che non puoi avere certificati con CN uguali.";
;;
esac;
unset ANS;
fi;
if [ -s "${CApath}/certs/${NOME}.pem.req" -o -s "${CApath}/private/${NOME}.key" ]; then
echo "E' gia' presente la richiesta di certificato ${CApath}/certs/${NOME}.pem.crt, vuoi sovrascriverla [s/N]? ";
read ANS;
case ${ANS} in
"S"|"s"|"Y"|"y") echo "La richiesta di certificato e le relative chiavi verranno sovrascritte.";
newCert;
;;
"N"|"n"|"") echo "Si e' deciso di non sovrascrivere la vecchia richiesta, impossibile proseguire.";
exit -1;
;;
esac;
unset ANS;
else
newCert;
fi;
OLD_UMASK=`umask`;
umask 77;
openssl ca -config ${opensslConf} -policy policy_anything -days 730 -out ${CApath}/newcerts/${NOME}.pem.crt -infiles ${CApath}/certs/${NOME}.pem.req;
chmod a+r ${CApath}/newcerts/*;
umask ${OLD_UMASK};

Dopo tutta questa sbrodolata di codice io sono esaurito, anche perchè lo scrivevo assieme al post e mentre facevo le prove; inoltre penso che se è la prima volta che vi avvicinate ad openssl abbiate le idee molto confuse... tranquilli, è normale. Negli script riportati in precedenza ci sono molti concetti sul funzionamento di openssl, su di alcuni schemi condizionali e sulle nomenclature (scelte da me con una certa logica); uno dei concetti più importanti che ci sono, riguarda il campo CN (Common Name) di un certificato: questo deve essere univoco all'interno di una CA, quindi se avete già emesso un certificato con quel CN è obbligatorio lo revochiate per poterne emettere un altro, anche se questo è già scaduto.
Con questo direi che la trattazione sembra abbastanza esaustiva o comunque sufficiente per rendervi operativi... ricordate che il CN è il campo fondamentale del vostro certificato, e deve contenere l'host, l'ip o l'indirizzo email, relativi al tipo di dati che si vuole proteggere.

Certification authority? Certo, sulla Linux Box

Benissimo, se siete qui a leggere vuole dire che vi servivano informazioni su questo argomento, oppure vi sono piaciuti i post precedenti... io spero la seconda, logicamente per soddisfare un po' il mio ego.
Ora veniamo a noi ed alla breve spiegazione teorica... quando si parla di garantire trasmissioni sicure, si vuole ottenere un sistema che sia in grado di realizzare uno o più dei seguenti requisiti:

• riservatezza/confidenzialità;
• integrità;
• autenticità;
• non ripudio.

Lo scopo viene ottenuto grazie all'utilizzo della crittografia con il sistema delle chiavi pubblica/privata. Questo sistema viene realizzato attraverso i certificati X.509, che realizzano una struttura gerarchica, con sviluppo ad albero, i cui elementi sono legati tramite un rapporto di fiducia, ovvero il "padre" garantisce che i suoi "figli" sono coloro che dicono di essere (autenticità), mentre le parti di integrità, riservatezza e non ripudio sono garantite dalla crittografia legata all'utilizzo delle due chiavi. Logicamente, come dicono i nomi, la chiave pubblica può e deve essere distribuita per poter stabilire se un determinato messaggio è firmato dalla relativa chiave privata o, nel caso di utilizzo della crittografia, per poter crittografare il messaggio che verrà poi decifrato attraverso l'uso della chiave privata. Dietro a tutto questo ci sono molti concetti matematici, che se volete potete cercare e studiare, ma questo esula sicuramente da quello che voglio dirvi.
La parte pratica viene gestita nella seguente maniera:

1. Il figlio genera la richiesta di certificato.
2. Il padre firma la richiesta di certificato del figlio, tramite un certificato valido.
3. La richiesta di certificato firmata diventa certificato e viene assegnato al figlio.
4. Chiunque riconosce l'autorità del padre, automaticamente riconosce anche quella del figlio.

Chi ha spirito pratico, in tutto questo si sarà accorto di una cosa, e si chiederà: "e chi ha firmato il certificato del padre? il nonno? e chi quello del nonno?" e così via. Logicamente qui ci troviamo al discorso del "è nato prima l'uovo o la gallina?", ma la risposta è molto più semplice: il primo certificato si chiama self-signed, ovvero è un certificato autofirmato in cui il firmatario garantisce di essere chi dice di essere. Da un certificato di questo tipo possiamo far nascere la nostra CA, ovvero una certification authority, i cui "figli" saranno riconosciuti da chi ha considerato autorevole il certificato del padre, ovvero quello originario della nostra CA.
La gestione dei certificati all'interno di una linux box ricopre una parte vastissima perchè riguarda tutte le comunicazioni che si vogliono rendere sicure, e pensando alla sicurezza, sono aspetti imprescindibili e molto profondi, quindi conviene impararla velocemente, mettendo i puntini sulle "i" fin dall'inizio ed apprendendo tutto quello che serve. Il mio scopo è darvi delle brevi e semplici informazioni e molti dei comandi utili sotto forma di script, questo al fine di aiutarvi ad addentrarvi in openssl da subito... logicamente, come il solito, dove non arrivano le mie spiegazioni ci arriveranno quelle di qualcun altro che ha scritto un help, un howto o della documentazione varia resa disponibile attraverso internet.
Passando alla configurazione pratica, prima di tutto ci serve installare l'ambiente ed i comandi che ci serviranno per la nostra CA, quindi:

• aptitude install openssl;

A questo punto a livello di comandi e configurazione avremo tutto quello che ci serve, ora dobbiamo solamente personalizzarlo modificando il file openssl.cnf (normalmente in /etc/ssl o /etc/pki/tls per le distribuzioni basate su RedHat) affinchè rispecchi i propri bisogni... io utilizzo i seguenti parametri (in Debian):

• dir = /etc/ssl/YOUR_CA
• private_key = $dir/private/cakey.unsec.pem # se la chiave non ha password
  
• private_key = $dir/private/cakey.pem # se la chiave ha password
• countryName_default = IT
• stateOrProvinceName_default = Turin
• localityName_default = Turin
• 0.organizationName_default = YOUR organization
• organizationalUnitName_default = host.domain from YOUR_CA
• commonName = Common Name (eg, YOUR name as host or IP)
• emailAddress_default = YOUR email address
• challengePassword_default = longpasswordyouwant

Questi parametri presuppongono alcune strutture che io do per scontate nelle mie configurazioni e sono:

• i percorsi a cui si fa riferimento in /etc/*/openssl.cnf sono di tipo assoluto;
• la struttura della CA è locata all'interno di una directory del tipo /etc/*/CA;
• il file openssl.cnf è nella stessa directory in cui vi è la CA;
  
• il nome della CA viene utilizzato anche per il nome del certificato;
• gli hash del certificato della CA vengono messi in /etc/*/certs.

A questo punto dobbiamo creare una struttura che ci permetta di svolgere i ruoli di una CA, ovvero coppia di chiavi pubblica/privata, un percorso in cui andare a salvare le richieste di certificato per elaborarle e trasformarle in certificato ed alcuni file necessari per la gestione "logica" della CA, compresa la CRL (Certificate Revocation List).
Il seguente script, da mettere in /etc/*/makeCA.sh, attingendo dai parametri immessi in openssl.cnf, prepara la struttura necessaria ad ospitare la CA.

#!/bin/bash

# Script per creazione della CA
opensslConf=$(find /etc -iname openssl.cnf|sort|head -1);
dir=$(grep "^[[:space:]]*dir[[:space:]]*=" ${opensslConf} | sed "s/[[:space:]]*dir[[:space:]]*=[[:space:]]*\([^[:space:]]*\)[[:space:]]*.*/\1/");
certificate=$(grep "^[[:space:]]*certificate[[:space:]]*=" ${opensslConf} | sed -e "s/[[:space:]]*certificate[[:space:]]*=[[:space:]]*\([^[:space:]]*\)[[:space:]]*.*/\1/" -e "s|\$dir|$dir|");
private_key=$(grep "^[[:space:]]*private_key[[:space:]]*=" ${opensslConf} | sed -e "s/[[:space:]]*private_key[[:space:]]*=[[:space:]]*\([^[:space:]]*\)[[:space:]]*.*/\1/" -e "s|\$dir|$dir|");
mkdir -pm 755 ${dir};
mkdir -pm 755 ${dir}/{certs,crl,newcerts};
mkdir -pm 700 ${dir}/private;
touch ${dir}/index.txt;
touch ${dir}/private/.rand;
echo 01 > ${dir}/serial;
echo -n "Vuoi generare una chiave privata senza password? (s/N) ";
read ANS;
case ${ANS} in
"S"|"s"|"Y"|"y") echo "Attenzione, la chiave privata sara' leggibile da chiunque!";
openssl genrsa -out ${private_key} 2048;
;;
"N"|"n"|"") echo "Attenzione, ad ogni accesso alla chiave privata si dovra' fornire la password!";
openssl genrsa -des3 -out ${private_key} 2048;
echo "Per la rimozione della password usare il seguente comando: openssl rsa -in ${private_key} -out ${private_key}.unsec";
;;
esac
openssl req -config ${opensslConf} -new -x509 -key ${private_key} -out ${certificate} -text -days 2922;
hash=$(openssl x509 -noout -in ${certificate} -hash);
ln -sf ${certificate} $(dirname ${dir})/$(basename ${dir}).crt;
ln -sf ${certificate} $(dirname ${dir})/certs/${hash}.0;

Ora la nostra CA è pronta a fare il suo dovere e mancano solamente più i certificati "figli".
Per scoprire come creare e gestire i certificati continuate a seguirmi, e vi fornirò le informazioni necessarie ad essere operativi... alla prossima!