Commandes de certificat TLS fondamentales que vous devez connaître | de Tate Galbraith | sept. 2022

Comprendre l’infrastructure à clé publique (ICP) peut être l’un des aspects les plus difficiles du développement logiciel. La création d’applications n’est qu’amusement et jeux jusqu’à ce que le moment soit venu de sécuriser leurs communications. Si vous créez des systèmes distribués qui se connectent les uns aux autres sur un réseau, vous allez rencontrer des certificats TLS à un moment donné.

Dans cet article, nous relèverons le défi de gérer les certificats de front. Apprendre quelques commandes de base pour générer et inspecter des certificats facilite grandement la gestion et la sécurisation de vos applications. Nous explorerons la mise en place d’une chaîne privée de certificats pouvant être utilisés pour les tests et examinerons comment chaque composant s’intègre dans son ensemble.

C’est l’une des tâches les plus courantes dans le domaine des certificats. Si vous construisez un réseau crypté ou testez un serveur Web HTTPS, vous devrez obtenir une forme de certificat.

Le moyen le plus rapide et le plus simple de le faire est de générer un certificat « auto-signé ». Il s’agit d’un certificat autonome qui indique essentiellement : « Je suis la seule autorité et je confirme ma propre identité. »

Cela devrait être évident, mais il ne s’agit pas réellement d’un certificat sécurisé ou de confiance. C’est parce qu’il se valide. Il est « auto-signé ». Il n’y a pas d’autorité de certification crédible en amont qui le valide pour prouver son identité.

Si vous souhaitez obtenir un certificat valide et fiable, vous devez utiliser un service gratuit tel que Chiffrez ou acheter un certificat auprès d’une entreprise comme Digicert.

À des fins de test ou de réseaux de développement internes uniquement, un certificat auto-signé est généralement acceptable. Regardons comment nous pourrions générer un certificat auto-signé en utilisant le openssl utilitaire:

openssl req -new \
-newkey rsa:4096 -nodes \
-x509 \
-days 3650 \
-keyout self_signed.key \
-out self_signed.pem \
-subj '/CN=TestCertificate/C=US/ST=CA/L=SF/O=Test'

Décomposons ce que fait cette commande à chaque étape en commençant par le début :

• Créer une nouvelle demande de certificat dans le PKCS10 format.
• Générez une nouvelle clé privée pour cette requête longue de 4096 octets.
• Ne cryptez pas la clé privée avec un mot de passe.
• Générer un certificat auto-signé (c’est le -x509 drapeau).
• Faites expirer le certificat dans 10 ans (une expiration plus longue est normale pour les autorités de certification racine hors ligne).
• Écrivez la clé privée dans le self_signed.key dossier.
• Écrivez le certificat au self_signed.pem dossier.
• Ajouter le spécifié informations sur le sujet au certificat – ce sont des éléments de données comme le pays, l’état et l’organisation.

Une fois cette commande exécutée, il nous restera deux fichiers importants :

• Le premier fichier se termine par .key et est notre clé privée utilisée pour former le certificat. Ceci est similaire à ce que vous utiliseriez pour générer une paire de clés SSH.
• Le deuxième fichier se terminant par .pem est le certificat. Une fois que vous avez le certificat et la clé, vous pouvez l’installer dans tous les services nécessitant un chiffrement.

Les clients qui se connectent au service verront qu’il s’agit d’un certificat auto-signé et produiront probablement une sorte d’avertissement. Bien qu’il ne s’agisse pas d’un certificat de confiance, le trafic entre les services sera techniquement crypté à ce stade.

Voyons ensuite comment nous pouvons utiliser notre nouveau certificat auto-signé pour signer d’autres types de certificats.

Maintenant que nous avons un nouveau certificat auto-signé sophistiqué, nous pourrions en fait utiliser ce certificat comme autorité de certification et commencer à signer d’autres certificats avec. Cela crée une chaîne de confiance (bien qu’une faible un) entre les certificats et forme les fondamentaux de l’infrastructure à clé publique distribuée.

Supposons que vous ayez un nouvel hôte pour lequel vous souhaitez émettre un certificat. Cet hôte et les autres au sein du même domaine doivent tous se faire confiance et avoir un point de référence central. C’est le concept d’une autorité de certification, ou Californie. Nous pouvons générer des certificats uniques pour tous nos hôtes et les signer à l’aide d’une seule autorité de certification.

Afin de signer un certificat d’hôte, nous devons d’abord créer quelque chose appelé une demande de signature de certificat (RSE). Il s’agit d’une demande spéciale créée par l’hébergeur et envoyée à l’autorité de certification pour être signée puis renvoyée.

Faisons une nouvelle RSE pour notre TestHost à présent:

openssl req -new \
-newkey rsa:4096 -nodes \
-keyout host.key \
-out host.csr \
-subj '/CN=TestHost/C=US/ST=CA/L=SF/O=Test'

Encore une fois, décomposons cela ligne par ligne :

• Créer une nouvelle demande de certificat dans le PKCS10 format.
• Générez une nouvelle clé privée pour cette requête longue de 4096 octets (là encore, cette clé n’est pas chiffrée et n’a pas de mot de passe).
• Envoyez la clé privée au host.key dossier.
• Envoyez le CSR au host.csr dossier.
• Ajouter l’hôte informations sur le sujet.

Une fois cette commande exécutée, nous aurons un nouveau fichier CSR à emporter avec nous et à signer à l’aide de notre autorité de certification. Voyons comment procéder ensuite.

La dernière pièce du puzzle est de faire signer notre RSE. Pour ce faire, nous prendrons notre host.csr fichier que nous avons créé précédemment et apportez-le à l’autorité de certification. Cela pourrait être sur un serveur centralisé, un portail, etc. Dans cet exemple, c’est sur le même hôte que nous avons testé, nous allons donc le signer maintenant :

openssl x509 -req \
-in host.csr \
-CA self_signed.pem \
-CAkey self_signed.key \
-CAcreateserial \
-out host.pem \
-days 30 -sha256

Attachez-vous pour une autre ventilation ligne par ligne de ce qui se passe:

• Cette fois, nous effectuons une x509 demande, ce qui signifie que nous allons signer un certificat au lieu de créer une nouvelle demande.
• Fournissez le fichier CSR hôte créé précédemment comme entrée.
• Fournissez le fichier de certificat CA auto-signé.
• Fournissez le fichier de clé privée de l’autorité de certification auto-signée.
• Créez un fichier de numéro de série — cela empêchera qu’une erreur ne se produise lors de la signature.
• Sortez le certificat signé comme host.pem
• Le certificat est valide pendant 30 jours et signé à l’aide du résumé SHA256.

Une fois cette commande terminée, il nous reste notre certificat d’hôte final signé. Nous pourrions ensuite utiliser ce certificat et tous les autres signés par cette autorité de certification pour créer un système d’hôtes de confiance dans le domaine.

Une chose à noter ici est l’expiration plus courte pour les hôtes. La plupart des recommandations sont d’environ 30 jours pour les certificats d’hôte. Cela oblige à un renouvellement tous les mois et garantit que les certificats d’hôte (puisque les hôtes sont généralement plus éphémères) ne peuvent pas traîner pendant des années à la fois.

Étant donné que nous avons un certain nombre de certificats flottant dans notre environnement, c’est une bonne idée d’apprendre à les inspecter. Certains certificats expirent plus rapidement que d’autres. Alors qu’une autorité de certification racine hors ligne peut être valide pendant 10 ans, un certificat client peut être valide pendant 24 heures seulement.

Regardons comment nous pouvons utiliser un dernier openssl commande pour inspecter les certificats existants :

openssl x509 -text -noout < cert.pem

Il s’agit d’une commande simple qui nous permet de voir tout de suite pas mal d’informations. Nous pouvons immédiatement apprendre les choses suivantes sur un certificat :

• L’émetteur
• La date d’expiration
• Les informations sur le sujet
• Informations de chiffrement

Il y a encore plus d’informations incluses dans le résultat, comme les clés chiffrées et les informations de chiffrement, mais ce n’est généralement pas aussi utile lors du diagnostic des problèmes.

Si vous cherchez à déterminer quand un certificat expire ou qui l’a délivré, c’est un excellent point de départ.

Voyons à quoi ressemble notre certificat auto-signé depuis le début :

Certificate:
Data:
Version: 1 (0x0)
Serial Number: 15449774297344832821 (0xd6689fddf532f535)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=TestCertificate, C=US, ST=CA, L=SF, O=Test
Validity
Not Before: Sep 21 01:48:35 2022 GMT
Not After : Sep 18 01:48:35 2032 GMT
Subject: CN=TestCertificate, C=US, ST=CA, L=SF, O=Test

Ça m’a l’air plutôt bien. Nous pouvons rapidement savoir combien de temps le certificat est valide, d’où il vient et à qui il est destiné.