Gestion des certificats SSL/TLS (OpenSSL)

To the non-french speaker, note that you can translate the articles using the Google Trad widget situated at the bottom of all pages.


Il y a de cela un an je vous avais expliqué comment fonctionne le protocole TLS/SSL. Comment sont utilisé les certificats, quels sont les messages envoyés entre le client et le serveur etc… Si ça ne vous parle je vous invite à lire cet article puis celui-ci.

Dans cet article nous allons entrer un peu plus dans les détails et voir quels sont les différents types de certificat et surtout comment les générer. Nous nous intéresserons à trois types de certificat : les certificats signés, les certificats auto signés et les certificats client.

I/ Les certificats signés

Sur Internet la plupart des certificats utilisés sont signés par des autorités de certification. Ces autorités sont des compagnies reconnues dans le monde qui font office d’entités de confiance. Parmi elles on retrouve Let’s Encrypt, Go-Daddy, Symantec etc…

Toutes ces entités disposent à minima de deux objets absolument primordiaux : une clé privée et un certificat d’autorité signé grâce à la clé privée.

La clé privée utilisée pour signer le certificat d’autorité est l’objet le plus sensible pour les autorités de certification. Si elles la perdent ou qu’elles se la font voler alors n’importe qui sera en mesure de créer des certificats valides en leurs noms ce qui détruirait totalement la chaîne de confiance établie avec les clients (retenez bien ça parce que ça vous servira probablement pour certains CTF’s 😉 ) !

Lorsque l’on veut obtenir un certificat signé il faut donc passer par ces autorités mais ne vous y méprenez pas, il est très simple de créer une autorité de certification. Pour cela nous allons pour commencer avoir besoin d’une clé privée que l’on pourra générer via cette commande :

openssl genpkey -aes-256-cbc -algorithm RSA -out keyCA.priv -pkeyopt rsa_keygen_bits:4096

Arguments :
-genpkey est le module de création de clé privée
-aes-256-cbc est le cypher SSL/TLS à utiliser (ici du chiffrement AES avec une clé de chiffrement de 256 bits et le mode de chiffrement CBC)
-algorithme RSA indique que le protocole d’échange de données sera du RSA
-out permet de spécifier le nom de clé privée
-pkeyopt est optionnel et permet d’indiquer qu’on veut que la clé RSA ait une taille de 4096 bits

Attention, au moment de la génération de la clé, un mot de passe va vous être demandé. Ce mot de passe devra absolument être suffisamment robuste et vous devrez vous en souvenir.

Puis nous générerons un certificat d’autorité :

openssl req -x509 -new -nodes -key keyCA.priv -sha256 -days 3650 -out certificat_autorite

Arguments :
-req indique que l’on fait une demande de certificat
-x509 indique que l’on veut un certificat qui respecte la norme x509 (soit un certificat utilisable avec SSL/TLS)
-key indique le nom de la clé privée à utiliser pour signer le certificat
-new : on veut un nouveau certificat
-days : on veut que le certificat soit valable 3650 jours
-out indique le nom du fichier de sortie

Capture d’écran du 2019-06-27 22-43-57.png

Maintenant qu’on a notre certificat d’autorité, il va falloir créer le certificat de notre serveur et avant ça, il va falloir créer une autre clé privée :

openssl genpkey -aes-256-cbc -algorithm RSA -out keySERV.priv -pkeyopt rsa_keygen_bits:4096

Capture d’écran du 2019-06-27 22-45-41.png

Puis viens l’étape de la demande de signature de certificat, c’est ce qu’on appelle une demande de CSR. Un CSR, c’est un certificat intermédiaire qui contient plusieurs données parmi lesquelles on retrouve les informations d’identification du client (son nom, son pays, le FQDN de l’application etc…) ainsi qu’une clé publique.

Pour faire une demande de CSR il faudra utiliser cette commande :

openssl req -new -key keySERV.priv -out certificat.csr

Capture d’écran du 2019-06-27 22-50-01.png

Maintenant qu’on a le CSR on va pouvoir demander à l’autorité de certification qu’on vient de créer de signer notre certificat à l’aide de sa clé privée et de son certificat. Mais avant ça il va falloir créer un petit fichier de configuration supplémentaire que l’on nommera « configuration_nonCA ».

Dans ce fichier on ajoutera ces lignes :

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

Puis on lancera cette commande :

openssl x509 -req -in certificat.csr -CA certificat_autorite -CAkey keyCA.priv -CAcreateserial -out certificat_final -days 1825 -sha256 -extfile configuration_nonCA

capture-de28099c3a9cran-du-2019-06-27-22-54-07.png

Nous obtiendrons ainsi notre certificat_final que l’on pourra attribuer à notre serveur web par exemple. Attention cependant, tant que vous n’importerez pas le certificat d’autorité que nous avons généré quelques minutes plus tôt dans l’onglet « Autorités » du panel certificat de votre navigateur :

Capture d’écran du 2019-06-27 22-56-01

Vous obtiendrez un message d’erreur vous indiquant que le certificat n’est pas valide. En effet votre navigateur considérera que le certificat est auto signé et donc qu’il est potentiellement dangereux d’accéder à ce site.

II/ Les certificats auto signés

Un certificat auto signé est un certificat qui n’a pas été signé par une autorité de certification. Autrement dit, c’est un certificat dont la légitimé n’a pas été approuvé. Utiliser ce type de certificat sur une infrastructure publique n’est donc pas une bonne pratique pour la bonne et simple raison que si vous déployez des certificats auto signés sur vos serveurs web alors les utilisateurs finaux recevront ce message de la part de leur navigateur :

Capture d’écran du 2019-06-26 22-55-22.png

En revanche vous trouverez souvent ce genre de certificats sur les serveurs d’intranet puisqu’ils sont faciles à créer et à déployer (même si personnellement je trouve que ce n’est pas une bonne pratique).

Comme pour les certifcats signés, nous allons commencer par créer une clé privée :

openssl genpkey -aes-256-cbc -algorithm RSA -out key.priv -pkeyopt rsa_keygen_bits:4096

Capture d’écran du 2019-06-26 23-08-32.png

Puis nous pourrons créer un certificat que l’on signera nous même avec notre clé privée via cette commande :

openssl req -x509 -key key.priv -new -days 3650 -out certautosigne.crt

Capture d’écran du 2019-06-26 23-16-45.png

Et voilà nous avons notre certificat final. Comme vous l’avez vu, le processus de création d’un certificat auto signé est beaucoup plus simple. En revanche il ne faudra pas oublier qu’un certificat auto signé sera toujours signalé aux clients par leurs navigateurs.

III/ Les certificats client

Jusqu’à maintenant nous n’avons utilisé que des certificats que l’on attribue à des serveurs. Cependant il est aussi possible d’effectuer la même chose pour les clients : on parle alors d’authentification forte. Dans ces cas là, le serveur ainsi que le client auront l’obligation de s’identifier via l’utilisation d’un certificat.

Pour mettre en place une authentification forte, encore une fois, il faudra créer et importer un certificat dans votre navigateur. Ce certificat (pour Chrome et Firefox) sera un peu particulier puisqu’il devra respecter la norme PKCS12.

Alors quelle est la différence entre un certificat pkcs12 et les autres ? Eh bien dans un certificat PKCS12 le certificat ainsi que la clé privée sont contenus dans un seul et même fichier.

Pour créer un certificat PKCS12 valide on pourra utiliser la commande suivante :

openssl pkcs12 -export -out finalcert.p12 -in cert.crt -inkey priv.key

Arguments :

-pkcs12 : indique que l’on veut obtenir un fichier au format pkcs12
-export : indique que l’on exporte le fichier
-out spécifeir le nom du fichier final
-in spécifie le nom du fichier qui contient le certificat d’autorité
-inkey indique le nom du fichier qui contient la clé privée

Et voilà ! Il ne nous restera plus qu’à importer ce certificat dans l’onglet « Vos certificats » :

Capture d’écran du 2019-06-29 12-15-06.png

Pour que l’authentification forte soit en place.

 

 

2 commentaires

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l'aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s