Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Service de gestion des certificats gNOI

Utilisez le service gNOI CertificateManagement pour gérer les certificats sur l’élément réseau cible.

Vue d’ensemble

Le service gNOI CertificateManagement du package gère la gnoi.certificate gestion des certificats sur l’élément réseau cible. Le fichier de définition du proto se trouve à https://github.com/openconfig/gnoi/blob/master/cert/cert.proto.

Une infrastructure à clé publique (PKI) prend en charge la distribution et l’identification des clés de chiffrement publiques, ce qui permet aux utilisateurs d’échanger des données en toute sécurité sur des réseaux tels qu’Internet et de vérifier l’identité de l’autre partie. La PKI Junos vous permet de gérer les certificats à clé publique sur les équipements Junos, y compris le téléchargement, la génération et la vérification des certificats. Le service gNOI CertificateManagement définit les opérations de gestion des certificats, qui se fait via l’ICP Junos. Les deux principales opérations sont :

  • Installer : installez un nouveau certificat à l’aide d’un nouvel ID de certificat sur le périphérique réseau cible. Si l’ID de certificat existe déjà, l’opération renvoie une erreur.

  • Rotation : remplacez un certificat existant, qui a déjà un ID de certificat existant, sur le périphérique réseau cible. Si le flux est interrompu ou si l’une des étapes échoue pendant le processus, l’appareil revient au certificat d’origine.

La figure 1 présente le flux de travail pour les Install() opérations et Rotate() . Pour les deux opérations, le client peut générer lui-même la demande de signature de certificat (CSR) ou demander à la cible de générer la CSR. Dans les deux cas, le client transmet la CSR à une autorité de certification (AC) pour demander un certificat numérique. Le client charge ensuite le certificat sur la cible, soit avec un nouvel ID de certificat pour Install() les opérations, soit avec un ID de certificat existant pour Rotate() les opérations. Pour Rotate() les opérations, le client doit également valider les certificats de remplacement et finaliser ou annuler l’opération Rotate() en fonction de la réussite ou de l’échec de la validation. Si le client annule l’opération, le serveur restaure le certificat, la paire de clés et tout bundle d’AC, s’ils sont présents dans la requête.

À partir de la version 23.1R1 de Junos OS Evolved, le Install()Rotate()LoadCertificate() serveur gNOI vérifie le nouveau certificat d’entité finale à l’aide du certificat d’AC correspondant. Ainsi, la PKI du serveur gNOI doit inclure le certificat de l'AC racine qui vérifie le nouveau certificat. Vous pouvez charger le certificat d’AC requis dans le bundle d’AC gNOI ou le charger séparément. Si la vérification échoue, l’appareil n’installe pas le nouveau certificat.

Figure 1 : Opérations d’installation et de rotation du service gNOI CertificateManagement Sequence diagram of certificate management with gNOI: gNOI Client requests a CSR from gNOI Server, CA Server signs it, and certificate rotation is completed.

Le serveur gNOI ne prend en charge qu’un seul bundle global de certificats AC pour les services gNOI. Lorsque vous utilisez le service gNOI CertificateManagement pour charger le bundle AC, les instructions suivantes s’appliquent :

  • Le CertificateManagement service charge toujours le bundle de certificats d’AC à l’aide de l’identifiant ca-profile-group gnoi-ca-bundleréservé .

  • Si vous utilisez le service pour charger le bundle de certificats d’AC CertificateManagement , l’appareil utilise implicitement l’authentification mutuelle.

  • Si le service envoie une demande de chargement d’un CertificateManagement nouveau bundle de certificats d’AC, le serveur efface les certificats du bundle d’AC précédent de l’appareil et charge les nouveaux.

  • Si vous utilisez le CertificateManagement service pour charger un bundle de certificats AC et que vous configurez explicitement l’authentification mutuelle dans la configuration de l’appareil, les instructions configurées sont prioritaires.

Ainsi, vous pouvez d’abord configurer l’authentification serveur uniquement sur le serveur gNOI, puis utiliser le Install() RPC pour charger les certificats AC. Lorsque vous utilisez gNOI pour charger le lot initial de certificats d’AC, l’équipement effectue les étapes suivantes :

  • Ajoute les certificats AC dans l’ICP Junos.
  • Configure automatiquement le bundle de certificats gNOI AC au niveau de la hiérarchie à l’aide [edit security pki] de l’identifiant ca-profile-group gnoi-ca-bundle.
  • Commutateurs de l’authentification serveur uniquement à l’authentification mutuelle.

Le Rotate() RPC ne prend pas en charge le passage d’un mode d’authentification à l’autre pendant l’opération de rotation. Ainsi, ne prend pas en charge le chargement du bundle de certificats AC sur le serveur gNOI pour la première fois, Rotate() car cela fait passer l’appareil de l’authentification serveur uniquement à l’authentification mutuelle pendant l’opération. Lorsque le mode d’authentification change, le périphérique réseau doit redémarrer la pile gRPC et la connexion est perdue. Si le flux est interrompu, le client ne peut pas finaliser la demande de rotation et l’appareil revient aux certificats qui étaient en place avant le lancement de la Rotate() demande.

Remarque :

L’instruction hot-reloading au niveau de la [edit system services extension-service request-response grpc ssl] hiérarchie ne conserve la session gRPC lors d’une mise à jour de certificat que lorsque le mode d’authentification reste inchangé pendant l’opération. Si le mode d’authentification passe, par exemple, de l’authentification serveur uniquement à l’authentification mutuelle ou vice versa, le client se déconnecte.

RPC pris en charge

Le Tableau 1 présente les RPC de service pris en charge sur les CertificateManagement équipements Junos.

Tableau 1 : RPC cert.proto pris en charge
RPC Descriptif Introduit dans la version
CanGenerateCSR()

Interrogez l’appareil cible pour déterminer s’il peut générer une demande de signature de certificat (CSR) avec le type, la taille et le type de clé spécifiés. Valeurs prises en charge :

  • Type de clé : KT_RSA

  • Tailles des clés : 1024, 2048, 4096

  • Type de certificat : CT_X509

Renvoie True si le serveur gNOI prend en charge le type, la taille de la clé et le type de certificat spécifiques.

Junos OS Evolved 23.1R1

GenerateCSR()

Générez et renvoyez une demande de signature de certificat (CSR).

Junos OS Evolved 22.2R1

GetCertificates()

Renvoyer les certificats locaux chargés sur l’appareil cible.

Junos OS Evolved 22.2R1

Install()

Chargez un nouveau certificat sur l’appareil cible en créant une demande CSR, en générant un certificat basé sur le CSR et en chargeant le certificat à l’aide d’un nouvel ID de certificat.

Junos OS Evolved 22.2R1

LoadCertificate()

Chargez un certificat signé par une autorité de certification (AC) sur l’équipement cible.

Junos OS Evolved 22.2R1

LoadCertificateAuthorityBundle()

Chargez un bundle de certificats d’AC sur l’équipement cible.

Junos OS Evolved 22.2R1

RevokeCertificates()

Révoquez les certificats avec les ID de certificat spécifiés sur l’équipement cible.

Junos OS Evolved 23.1R1

Rotate()

Remplacez un certificat existant sur l’appareil cible en créant une demande CSR, en générant un certificat basé sur le CSR et en chargeant le certificat à l’aide d’un ID de certificat existant.

Junos OS Evolved 22.2R1

Configuration des équipements réseau

Avant de commencer :

Pour les serveurs gNOI configurés au niveau de la hiérarchie, aucune configuration supplémentaire n’est [edit system services http servers] requise.

Pour les serveurs gNOI configurés au niveau de la [edit system services extension-service request-response grpc ssl] hiérarchie, vous devez configurer les use-pki instructions et au hot-reloading même niveau hiérarchique. L’instruction hot-reloading est requise pour maintenir la session gRPC lors de la mise à jour de certificats qui affectent la session. Pour configurer les instructions :

  1. Configurez l’appareil pour qu’il utilise la base de données PKI pour les certificats locaux.
  2. Permet à l’appareil de recharger les certificats sans mettre fin à la session gRPC.
  3. Validez la configuration.

Installation d’un certificat

Vous pouvez utiliser le CertificateManagement service Install() RPC pour charger un nouveau certificat sur l’appareil cible. Lorsque vous installez un nouveau certificat à l’aide de l’opération Install() , vous devez spécifier un nouvel ID de certificat qui n’existe pas déjà sur l’appareil cible. Vous pouvez aussi charger un bundle de certificats d’AC dans le cadre de l’opération Install() .

Dans le cadre de l’opération Install() , l’appareil vérifie le nouveau certificat. Par conséquent, la PKI Junos doit disposer du certificat d’AC racine qui vérifie le nouveau certificat. Vous pouvez charger le certificat d’AC requis dans le cadre de l’opération Install() , ou vous pouvez le charger séparément, avant l’opération, s’il n’est pas déjà dans l’ICP.

Si vous installez un nouveau certificat local qui sera utilisé pour l’authentification de session gRPC, vous devez également mettre à jour la configuration du serveur gRPC sur l’appareil pour utiliser le nouvel ID de certificat.

Exemple : Installation d’un certificat

Dans cet exemple, le serveur gNOI a été initialement configuré avec un certificat local uniquement et n’a pas été configuré pour utiliser l’authentification mutuelle. Le client gNOI utilise le Install() RPC pour charger un nouveau certificat local et un bundle de certificats AC sur l’appareil. Une fois le bundle AC chargé sur le serveur gNOI, le serveur utilise l’authentification mutuelle par défaut. L’offre groupée d’AC comprend le certificat d’AC racine pour le certificat client ainsi que le certificat d’AC racine pour le nouveau certificat de serveur.

Le client exécute l’application gnoi_cert_install_certificate_csr.py Python, qui effectue les opérations suivantes :

  • Demande à la cible de générer un CSR.
  • Obtient un certificat signé basé sur le CSR.
  • Charge le nouveau certificat de serveur, le nouveau certificat d'AC racine du serveur et le certificat d'AC racine du client sur le périphérique réseau cible.

L’application utilise le InstallCertificateRequest message avec les paramètres appropriés pour définir les demandes de génération du CSR et de chargement des certificats. Pour chaque demande, l’application utilise le Install() RPC pour envoyer les demandes à l’équipement réseau.

L’application gnoi_cert_install_certificate_csr.py importe le grpc_channel module pour établir le canal. Le grpc_channel module est décrit dans Configurer les services gNOI. Les arguments de l'application sont stockés dans le args_cert_install_csr.txt fichier. Les dossiers de candidature et d’argumentation sont présentés ici.

gnoi_cert_install_certificate_csr.py

args_cert_install_csr.txt

Exécuter l’application

Lorsque le client exécute l’application, celle-ci demande le CSR, obtient le certificat signé et charge le nouveau certificat de serveur et les certificats AC sur le périphérique réseau cible.

Après avoir installé le nouveau certificat de serveur, vous devez configurer le serveur pour qu’il utilise cet ID de certificat pour l’authentification de session gRPC. Mettez à jour l’instruction local-certificate pour votre configuration de serveur spécifique, qui peut être configurée à l’un des niveaux hiérarchiques suivants :

  • [modifier services système extension-service-demande-réponse grpc ssl]

  • [modifier : services système, serveurs http, serveur name tls]

Par exemple :

De plus, comme l’opération a chargé de Install() nouveaux certificats d’AC, l’appareil utilise implicitement l’authentification mutuelle. Par conséquent, toutes les sessions gRPC suivantes doivent inclure le certificat et la clé du client lors de l'établissement du canal.

Si vous exécutez l’application et fournissez un ID de certificat qui existe déjà sur le serveur, l’application renvoie une ALREADY_EXISTS erreur, car l’opération Install() nécessite un nouvel ID de certificat.

Rotation d’un certificat

Vous pouvez utiliser le CertificateManagement service Rotate() RPC pour remplacer un certificat existant sur l’appareil cible. Lorsque vous remplacez un certificat existant à l’aide de l’opération Rotate() , vous devez charger le certificat à l’aide de l’ID de certificat qui existe déjà sur l’appareil cible. Vous pouvez également remplacer le lot de certificats gNOI AC existant dans le cadre de l’opération Rotate() .

L’opération Rotate() est similaire à l’opération Install() , sauf qu’elle Rotate() remplace un certificat existant au lieu d’installer un nouveau certificat. En outre, le client doit valider le fonctionnement du certificat mis à jour, puis finaliser ou annuler la Rotate() demande en fonction de la réussite ou de l’échec de la validation du certificat.

Dans le cadre de l’opération Rotate() , l’appareil vérifie le nouveau certificat. Par conséquent, la PKI Junos doit disposer du certificat d’AC racine qui vérifie le nouveau certificat. Vous pouvez charger le certificat d’AC requis dans le cadre de l’opération Rotate() , ou vous pouvez le charger séparément, avant l’opération, s’il n’est pas déjà dans l’ICP.

Exemple : rotation d’un certificat

Dans cet exemple, le client exécute l’application gnoi_cert_rotate_certificate_csr.py Python, qui effectue les opérations suivantes :

  • Demande à la cible de générer un CSR.
  • Obtient un certificat signé basé sur le CSR
  • Remplace le certificat de nœud et l’offre groupée d’AC gNOI sur l’équipement réseau cible.
  • Valide le nouveau certificat.
  • Finalise l’opération Rotate .

L’application utilise le RotateCertificateRequest message avec les paramètres appropriés pour définir les demandes de génération du CSR et de chargement du bundle de certificats et d’AC. Pour chaque demande, l’application utilise le Rotate() RPC pour envoyer la demande à l’équipement réseau. Pour permettre à l’équipement cible de vérifier le nouveau certificat de nœud, l’application remplace le bundle d’AC existant par un nouveau bundle d’AC. L’offre groupée comprend à la fois le certificat d’AC client et le certificat d’AC requis pour vérifier le certificat de nœud.

L’application valide le fonctionnement du nouveau certificat en créant une nouvelle session gRPC avec le périphérique réseau et en exécutant un RPC simple Time() , bien que vous puissiez tester l’authentification de la session avec n’importe quel RPC. L’application finalise la demande de rotation si la session est établie avec succès et annule la demande de rotation si l’authentification de la session échoue.

L’application gnoi_cert_rotate_certificate_csr.py importe le grpc_channel module pour établir le canal. Le grpc_channel module est décrit dans Configurer les services gNOI. Les arguments de l'application sont stockés dans le args_cert_rotate_csr.txt fichier. Les dossiers de candidature et d’argumentation sont présentés ici.

gnoi_cert_rotate_certificate_csr.py

args_cert_rotate_csr.txt

Il est important de noter que l root_ca_cert 'argument correspond au certificat d'AC racine du serveur requis pour les informations d'identification du canal initial. L server_root_ca1 'argument est le certificat d'AC racine correspondant au nouveau certificat du serveur. La PKI Junos doit disposer du nouveau certificat d’AC racine afin de vérifier le nouveau certificat local pendant l’opération Rotate() . De plus, les informations d’identification du canal pour la session gRPC qui valide le nouveau certificat utilisent ce certificat AC racine. Bien que cet exemple utilise le même certificat de AC racine pour le nouveau et l’ancien certificat de serveur, ceux-ci peuvent différer dans un autre cas.

Exécuter l’application

Lorsque le client exécute l’application, celle-ci demande le CSR, récupère le certificat signé et charge le certificat de remplacement et le bundle AC sur l’équipement réseau cible. L’application valide ensuite le certificat de remplacement avec une nouvelle session gRPC qui exécute un RPC simple Time() . Une fois la validation réussie, le client finalise la demande de rotation.

Révoquer un certificat

Un client gNOI peut utiliser le RevokeCertificates() RPC pour supprimer un ou plusieurs certificats de l’appareil cible. Le client inclut un RevokeCertificatesRequest message avec la liste des ID de certificat à révoquer.

Lorsque le serveur gNOI reçoit la RevokeCertificates() demande, il traite chaque ID de certificat de la liste comme suit :

  • Si le certificat est présent et que la révocation est réussie, l’équipement supprime le certificat du système de fichiers et de l’ICP Junos et ajoute l’ID du certificat à la liste des certificats révoqués avec succès.

  • Si le certificat est présent et que la révocation échoue, l’appareil inclut l’ID de certificat et la raison de l’échec dans la liste d’erreurs de révocation de certificat.

  • Si le certificat n’est pas présent, l’appareil considère que l’opération de révocation a réussi et ajoute l’ID de certificat à la liste des certificats révoqués avec succès.

Remarque :

Si la demande révoque le certificat utilisé pour la session en cours, celle-ci n’est pas affectée.

Après avoir traité la requête, le serveur gNOI renvoie un RevokeCertificatesResponse message qui inclut :

  • Liste des ID de certificat révoqués avec succès.

  • Liste des erreurs de révocation contenant l’ID du certificat et la raison de l’échec.

Exemple : Révoquer un certificat

Dans cet exemple, le client exécute l’application gnoi_cert_revoke_certificates.py Python, qui révoque deux certificats sur le serveur. Le premier ID de certificat est un identifiant valide sur l’appareil. Le deuxième ID de certificat est un identifiant qui n’existe pas sur l’appareil.

L’application utilise le RevokeCertificatesRequest message avec les paramètres appropriés pour définir la demande. L’application envoie le RevokeCertificates() RPC au périphérique réseau pour effectuer l’opération.

L’application gnoi_cert_revoke_certificates.py importe le grpc_channel module pour établir le canal. Le grpc_channel module est décrit dans Configurer les services gNOI. Les arguments de l'application sont stockés dans le args_cert_revoke_certificates.txt fichier. Les dossiers de candidature et d’argumentation sont présentés ici.

gnoi_cert_revoke_certificates.py

args_cert_revoke_certificates.txt

Exécuter l’application

Lorsque le client exécute l’application, celle-ci demande à l’appareil cible de révoquer les certificats spécifiés. L’appareil renvoie une liste des certificats révoqués avec succès et des erreurs. L’appareil considère que l’opération a réussi à la fois pour l’ID de certificat valide et pour l’ID de certificat qui n’existe pas actuellement sur l’appareil.

Tableau de l’historique des modifications

La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.

Libération
Descriptif
23.1R1-EVO
À partir de la version 23.1R1 de Junos OS Evolved, Rotate()les Install()et les opérations vérifient LoadCertificate() le nouveau certificat dans le cadre de l’opération.