Qu'est-ce qu'une RSE ?

Une demande de signature de certificat (CSR) est un fichier généré par un client ou un appareil, contenant sa clé publique et des informations d'identification telles que le nom commun et les noms alternatifs du sujet, et qui est soumis à une autorité de certification. L'autorité de certification vérifie la demande et renvoie un certificat numérique signé que le demandeur peut installer.

Points clés à retenir

• Un CSR contient la clé publique et les champs d'identité d'un dispositif, mais jamais sa clé privée.
• L'appareil signe le CSR avec sa clé privée pour prouver qu'il détient la paire de clés.
• L'autorité de certification vérifie la demande et renvoie un certificat numérique signé.
• Les fichiers CSR peuvent être générés manuellement ou de manière automatisée via les protocoles SCEP, CMP ou ACME.
• Versa Director, Concerto et VMS génèrent et soumettent tous des CSR à une autorité de certification.

Sur cette page : Pourquoi est-ce important ? · Comment ça marche · Types · RSE et Versa · FAQ

Pourquoi la RSE est-elle importante ?

Une CSR constitue le point de départ de presque toutes les relations de confiance établies sur une infrastructure à clé publique (PKI). Avant que deux systèmes puissent s'authentifier mutuellement via TLS, TLS mutuel ou IPsec avec une authentification par certificat, l'un des deux doit disposer d'un certificat signé par une autorité de certification de confiance – et c'est par une CSR que ce processus commence. Générer la CSR sur l’appareil demandeur, plutôt que de laisser l’autorité de certification générer la paire de clés, signifie que la clé privée ne quitte jamais l’appareil qui l’utilisera, ce qui évite totalement le transit de la partie sensible de la paire de clés.

Les CSR revêtent également une importance opérationnelle, car la délivrance de certificats doit pouvoir s'étendre à des milliers d'appareils, de serveurs et de services sans devenir un goulot d'étranglement lié aux opérations manuelles. Les protocoles d’inscription automatisés s’appuient directement sur le format CSR, ce qui permet à un appareil de demander, de renouveler et de remplacer des certificats selon un calendrier défini, sans avoir à attendre un cycle manuel d’exportation et d’importation. La précision des champs d’identité – nom commun, noms alternatifs du sujet, période de validité – détermine également si les clients TLS feront réellement confiance au certificat obtenu, car les contrôles de validation modernes vérifient la liste des noms alternatifs du sujet (SAN), et pas seulement le nom commun.

Qu'est-ce qu'une RSE ?

Un CSR est un fichier au format PKCS#10 créé en trois étapes. Tout d’abord, le client ou l’appareil demandeur génère localement une paire de clés publique/privée. Ensuite, il assemble le corps de la demande : la clé publique, un nom distinctif identifiant le demandeur (pays, région, localité, organisation, unité organisationnelle et – surtout – un nom commun), ainsi que, généralement, un ou plusieurs noms alternatifs du sujet couvrant tous les noms d’hôte ou adresses IP pour lesquels le certificat doit être valide. Enfin, le dispositif signe l’ensemble de la demande avec sa propre clé privée, ce qui prouve à l’autorité de certification (CA) que le demandeur détient bien la clé privée correspondant à la clé publique figurant dans la demande, sans jamais transmettre cette clé privée où que ce soit.

La CSR signée est ensuite soumise à une autorité de certification (CA) – soit directement, via un processus manuel, soit automatiquement, via un protocole d’inscription tel que SCEP, CMP ou ACME. La CA valide l’identité du demandeur conformément à sa propre politique, puis émet un certificat signé associant la clé publique à l’identité demandée. Le demandeur installe ce certificat aux côtés de la clé privée qu’il détient déjà, et la CSR elle-même est supprimée.

Types de RSE

La manière dont un CSR est généré et envoyé varie selon le type de déploiement. Génération manuelle/via l'interface en ligne de commande (CLI) utilise un outil en ligne de commande – OpenSSL – ou un script fourni par un éditeur, tel que celui de VMS vsh generate-server-csr – pour générer la paire de clés et la CSR de manière interactive, l'administrateur saisissant les champs d'identité et copiant le fichier obtenu vers une autorité de certification (CA) en vue de sa signature. Génération pilotée par Orchestrator Cette opération s'effectue via une interface utilisateur d'administration : un administrateur renseigne les champs de la demande de certificat (nom commun, adresse e-mail, pays, durée de validité, taille de la clé) dans un workflow, puis la plateforme génère et soumet la demande dans le cadre de la mise en service d'un appareil ou d'un locataire. Recrutement automatisé selon le protocole supprime entièrement l'étape manuelle : les clients SCEP, CMP ou ACME génèrent la CSR, la soumettent automatiquement à un serveur d'autorité de certification et gèrent le renouvellement avant l'expiration du certificat. Il s'agit du modèle utilisé par la plupart des grandes flottes pour éviter les interruptions de service liées à l'expiration des certificats.

Une CSR peut également cibler une autorité auto-signée – ce qui est utile pour les laboratoires et les tests internes – ou une autorité signée par une autorité de certification (tierce) pour tout ce qui doit bénéficier d'une confiance généralisée. Dans les deux cas, les champs de la CSR restent les mêmes ; seule la racine de confiance diffère.

RSE & Versa

Versa utilise les CSR à deux niveaux de la plateforme. Sur Versa Service de messagerie, le vsh generate-server-csr La commande génère un CSR sur le nœud principal, en demandant de saisir entre cinq et sept noms alternatifs de sujet couvrant les interfaces de gestion, élastique et « southbound », ainsi que le nom de l'organisation et le nom commun – le résultat server-csr.pem est transmis à une autorité de certification de confiance pour être signé, puis revient par vsh import-ca-certs. Déploiements du système HA VMS générez plutôt localement une autorité de certification racine auto-signée et une chaîne CSR à l'aide de l'outil vms_cert_gen.sh script permettant de générer des certificats racine, de serveur et de client pour le cluster.

Du côté de l’ Secure SD-WAN , la configuration des locataires dans Concerto gère entièrement la génération des CSR via les champs du workflow : un administrateur sélectionne un type de serveur CA (ACME, CMP ou SCEP), puis renseigne les options de CSR telles que le nom commun, la clé partagée, la durée de validité et la taille de la clé privée pour chaque contrôleur. Concerto convertit ces entrées en données de liaison CSR que les appliances soumettent automatiquement lors de leur publication ; ainsi, l’authentification des locataires par certificat ne nécessite absolument aucune intervention sur le shell d’un appareil.

Questions fréquentes

Quelles informations figurent dans un rapport RSE ?

Un CSR contient la clé publique du demandeur ainsi qu'un nom distinctif : le nom commun, et généralement l'organisation, la localité, la région, le pays, ainsi qu'un ou plusieurs noms alternatifs du sujet. Il est signé à l'aide de la clé privée du demandeur afin de prouver qu'il en est bien le propriétaire, mais la clé privée elle-même n'est jamais incluse dans le fichier.

Un CSR contient-il une clé privée ?

Non. Un CSR ne contient que la clé publique de la paire de clés ; la clé privée reste sur l'appareil demandeur et sert uniquement à signer la demande, afin de prouver que l'appareil la détient, sans jamais la transmettre à l'autorité de certification ni à aucun autre endroit.

Quelle est la différence entre le « nom commun » et le « nom alternatif du sujet » dans un CSR ?

Le « nom commun » (Common Name) est le champ d'identité unique traditionnel, qui correspondait historiquement à un nom d'hôte. Le « nom alternatif du sujet » (Subject Alternative Name, SAN) est une extension plus récente qui répertorie tous les noms d'hôte, adresses IP ou identités que le certificat doit couvrir. Les clients TLS modernes effectuent une validation par rapport à la liste SAN ; c'est pourquoi la plupart des demandes de certificat (CSR) actuelles renseignent ces deux champs.

Quel est le lien entre un CSR et les programmes SCEP, CMP et ACME ?

SCEP, CMP et ACME sont des protocoles d'inscription qui automatisent les étapes d'un processus manuel de création d'une CSR : génération de la CSR, envoi à une autorité de certification et récupération du certificat signé. Les appareils « Versa » peuvent utiliser n'importe lequel de ces types de serveurs à la place d'un fichier CSR copié manuellement.

Une CSR peut-elle être réutilisée pour plusieurs certificats ?

Une demande de certificat (CSR) n'est généralement soumise qu'une seule fois et utilisée par l'autorité de certification (CA) qui la signe. Pour demander le renouvellement ou la réémission d'un certificat – ou pour modifier des champs d'identité tels que les entrées SAN –, le demandeur génère une nouvelle CSR plutôt que de renvoyer l'originale.

En savoir plus sur la RSE

Si vous souhaitez en savoir plus, voici des sources auxquelles nous faisons confiance.

Termes associés

Si vous vous intéressez à la RSE, voici quelques articles qui méritent votre attention.