« LINUX:Extension de la CA privée (V3) » : différence entre les versions
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| Ligne 159 : | Ligne 159 : | ||
[[Category:LINUX]] | |||
---- | ---- | ||
''->[[LINUX:Certificats|retour aux certificats]]'' | ''->[[LINUX:Certificats|retour aux certificats]]'' | ||
__NOEDITSECTION__ | __NOEDITSECTION__ | ||
Version du 3 décembre 2020 à 13:38
But
Dans cet article, nous allons étendre les fonctionnalités des certificats publiques de serveur en passant à la version 3. Cette fonctionnalité est nécessaire pour utiliser MS Edge et Google Chrome. On ajoute la fonctionnalité SAN (Server Alternative Name ou nom alternatif du serveur). Nous aborderons aussi le certificat Wildcard.
Cette procédure se réalise sous Linux.
Serveur unique
Dans cette première partie, on considère un seul serveur ou site.
Création du fichier de configuration V3
La première étape consiste à créer un fichier de paramètres pour les extensions de type V3.
On crée le fichier "reqv3.cnf" dont le contenu est le suivant (le nom peut être différent):
[ v3_req ] # Extensions to add to a certificate request basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment subjectAltName = DNS: serverdb.home.dom, IP: 192.168.1.100
Une autre présentation:
[ v3_req ] # Extensions to add to a certificate request basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment subjectAltName = @alt_names # Liste SAN [ alt_names ] DNS = serverdb.home.dom IP = 192.168.1.100
On remarque le nom DNS de notre serveur WEB. Evidemment, si notre site WEB est "www.home.dom", on adapte l'entrée et le reste du chapitre.
La seconde entrée reprenant l'adresse IP est facultative; elle est ajoutée pour exemple.
Procédure
L'ensemble des opérations décrites dans l'article précédent Création d'une CA privée (V1), sont identiques à l'exception de la création du certificat publique de serveur.
Création du certificat publique pour le serveur
L'étape qui change est la création du certificat publique du serveur ou du site ("/etc/pki/home/certs/serverdb.home.crt". Ce qui change est l'ajout du fichier de configuration d'extension "reqv3.cnf" et d'y faire référence à son option "v3_req".
openssl x509 -req -days 3650 -extensions v3_req -extfile reqv3.cnf -in /etc/pki/home/req/serverdb.home.csr -out /etc/pki/home/certs/serverdb.home.crt -passinpass:MOTDEPASSESECRET -CA /etc/pki/home/certs/ca.home.crt -CAkey /etc/pki/CA/private/ca.key -CAcreateserial -CAserial /etc/pki/home/misc/ca.home.srl
On voit que sa validation est renforcée par la CA (clés privée et publique), d'où l'ajout du mot de passe qui sécurise notre CA lors de la création de son certificat publique.
Cette opération se fait sur base des informations contenues dans la requête ("/etc/pki/home/req/serverdb.home.csr").
Nous avons choisit 10 ans de validité ("-days 3650") mais vous pouvez définir un autre délais, 1 an par exemple.
Pour la première utilisation, il y a initialisation du n° de série. Par la suite, lors du renouvellement ou de la création d'un certificat pour le même domaine, ce fichier sera incrémenté. Chaque certificat publique aura un n° de série différent, ce qui peut être utile lors de la révocation d'un certificat qui n'a plus de raison d'être ou piraté ("/etc/pki/home/misc/ca.home.srl").
Si on crée un certificat publique pour un autre site, la commande est analogue mais il ne faut pas réinitialiser le n° de série; l'option "-CAcreateserial" est à éliminer.
Sites multiples
Dans cette seconde étape, on étend la notion à plusieurs sites ou machines bien définis analogue à un certificat publique Wildcard et SAN.
Un certificat Wildcard permet de sécuriser un domaines et ses sous-domaines sans devoir générer un certificat pour chaque site ajouté.
Un certificat SAN générique regroupe un nombre défini de sites et les sécurise tous mais si on ajoute un site, il doit être regénéré en ajoutant ce site. Notons qu'il peut comprendre d'autres domaines.
Dans l'exemple suivant, ce certificat sera le même pour les trois sites serverdb.home.dom, www.home.dom et mail.home.dom au niveau d'Apache, Postfix et Dovecot.
Création du fichier de configuration V3
La première étape consiste à créer un fichier de paramètres pour les extensions de type V3.
On crée le fichier "reqv3.cnf" dont le contenu est le suivant (le nom peut être différent):
[ v3_req ] # Extensions to add to a certificate request basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment subjectAltName = DNS: serverdb.home.dom, DNS: www.home.dom, DNS: mail.home.dom, DNS: home.dom, DNS: *.home.dom, IP: 192.168.1.100
Une autre présentation:
[ v3_req ] # Extensions to add to a certificate request basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment subjectAltName = @alt_names # Liste SAN [ alt_names ] DNS.0 = serverdb.home.dom DNS.1 = www.home.dom DNS.2 = mail.home.dom DNS.3 = home.dom DNS.4 = *.home.dom IP = 192.168.1.100
On remarque les noms DNS de différents sites WEB. Dans le second cas, les entrées DNS doivent être numérotées.
Mais comme nous allons avoir une configuration Wildcard, nous pouvons simplifier le fichier:
[ v3_req ] # Extensions to add to a certificate request basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment subjectAltName = DNS: home.dom, DNS: *.home.dom, IP: 192.168.1.100
ou:
[ v3_req ] # Extensions to add to a certificate request basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment subjectAltName = @alt_names # Liste SAN [ alt_names ] DNS.0 = home.dom DNS.1 = *.home.dom IP = 192.168.1.100
Procédure
L'ensemble des opérations décrites dans l'article précédent Création d'une CA privée (V1), sont identiques à l'exception de la requête et de la création du certificat publique global.
Création d'une requête de certificat publique global
Maintenant vient la phase de création du certificat publique global. Elle comporte deux étapes: la requête et la création du certificat publique.
On commence par faire une requête pour obtenir le certificat ("/etc/pki/home/req/home.csr").
openssl req -new -key /etc/pki/home/private/localhost.key -out /etc/pki/home/req/home.csr -subj '/CN=*.home.dom/emailAddress=pdupont@gmail.com/OU=Dupont/O=Home/L=Namur/ST=Belgique/C=BE'
Comme ci-dessus, les informations de propriété sont ajoutées en option. Ici le "Common Name" est celui du domaine global ("*.home.dom").
Création du certificat publique global
L'étape qui change est la création du certificat publique global ("/etc/pki/home/certs/home.crt". Ce qui change est l'ajout du fichier de configuration d'extension "reqv3.cnf" et d'y faire référence à son option "v3_req".
openssl x509 -req -days 3650 -extensions v3_req -extfile reqv3.cnf -in /etc/pki/home/req/home.csr -out /etc/pki/home/certs/home.crt -passinpass:MOTDEPASSESECRET -CA /etc/pki/home/certs/ca.home.crt -CAkey /etc/pki/CA/private/ca.key -CAcreateserial -CAserial /etc/pki/home/misc/ca.home.srl
On voit que sa validation est renforcée par la CA (clés privée et publique), d'où l'ajout du mot de passe qui sécurise notre CA lors de la création de son certificat publique.
Cette opération se fait sur base des informations contenues dans la requête ("/etc/pki/home/req/home.csr").
Nous avons choisit 10 ans de validité ("-days 3650") mais vous pouvez définir un autre délais, 1 an par exemple.
Pour la première utilisation, il y a initialisation du n° de série. Par la suite, lors du renouvellement ou de la création d'un certificat pour le même domaine, ce fichier sera incrémenté. Chaque certificat publique aura un n° de série différent, ce qui peut être utile lors de la révocation d'un certificat qui n'a plus de raison d'être ou piraté ("/etc/pki/home/misc/ca.home.srl").
Si on crée un certificat publique pour un autre site, la commande est analogue mais il ne faut pas réinitialiser le n° de série; l'option "-CAcreateserial" est à éliminer.