Questions avec l'utilisation de PNP avec FND sur plus nouveau Cisco IOS® ; Releases

Introduction

Ce document décrit comment générer et exporter le certificat correct de l'infrastructure de clé privée de Windows (PKI) pour l'usage en combination avec le plug and play (PNP) sur le directeur de réseau de champ (FND).

Problème

Quand vous essayez d'employer PNP pour faire le déploiement nul de toucher (ZTD) sur un plus nouveau Cisco IOS® et un Cisco IOS® - les releases XE, le processus échoue avec une de ces erreurs PNP :

Error while creating FND trustpoint on the device. errorCode: PnP Service Error 3341, 
errorMessage: SSL Server ID check failed after cert-install
Error while creating FND trustpoint on the device. errorCode: PnP Service Error 3337, 
errorMessage: Cant get PnP Hello Response after cert-install

Depuis une certaine époque, le code PNP dans le ® IOS du Cisco IOS ®/Cisco - XE exige du champ alternatif soumis du nom (SAN) d'être rempli dans le certificat offert par le PNP-serveur/contrôleur (FND dans ce cas).

L'agent de Cisco IOS® PNP vérifie seulement le champ du certificat SAN pour l'identité de serveur. Il ne vérifie pas le champ commun du nom (NC) plus.

C'est valide pour ces releases :

• Version 15.2(6)E2 et ultérieures de Cisco IOS®

• Version 15.6(3)M4 et ultérieures de Cisco IOS®

• Version 15.7(3)M2 et ultérieures de Cisco IOS®

• Cisco IOS® XE Denali 16.3.6 et plus tard

• Cisco IOS® XE Everest 16.5.3 et plus tard

• Cisco IOS® Everest 16.6.3 et plus tard

• Tous les releases de Cisco IOS® de 16.7.1 et plus tard

Plus d'informations peuvent être trouvées ici : https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Plug-and-Play/solution/guidexml/b_pnp-solution-guide.html#id_70663

Solution

La majeure partie des guides et de la documentation pour FND ne mentionne pas encore que le champ SAN doit être rempli.

Afin de créer et exporter le certificat correct pour l'usage avec PNP et l'ajouter à la mémoire principale, suivez ces étapes.

Générez un nouveau certificat avec l'utilisation du modèle FND/NMS sur le Ca-serveur de Windows

Naviguez vers le Start > Run > le MMC > le fichier > l'ajout/suppression SNAP-dans… > les Certificats > ajoutent > compte > ordinateur local d'ordinateur > CORRECT et ouvrent les Certificats MMC SNAP-dans.

Développez les Certificats (ordinateur local) > personnel > des Certificats

Cliquez avec le bouton droit sur des Certificats et sélectionnez tous les tâches > certificat de demande nouveau… suivant les indications de l'image.

Cliquez sur Next et sélectionnez la stratégie d'inscription de Répertoire actif suivant les indications de l'image.

Cliquez sur Next et sélectionnez le modèle créé pour NMS/FND-server (répétition plus tard pour serveur de TelePresence (TPS)) et cliquez sur plus de lien d'informations suivant les indications de l'image.

Dans les propriétés de certificat, fournissez ces informations :

Nom du sujet :

• Organisation : votre nom d'organisation
• Nom commun : le nom de domaine complet (FQDN) du FND-serveur (ou de TPS si c'est approprié)

Nom alternatif (le champ SAN) :

• Si vous employez le Système de noms de domaine (DNS) afin de contacter la PNP-partie du FND-serveur, ajoutez une entrée DNS pour le FQDN
• Si vous employez l'IP afin de contacter la PNP-partie du FND-serveur, ajoutez une entrée d'ipv4 pour l'IP

Il est recommandé pour inclure de plusieurs valeurs SAN dans le certificat, au cas où les méthodes heuristiques varieraient. Par exemple, vous pouvez inclure le FQDN de contrôleur et adresse IP (ou adresse IP NAT) dans le domaine SAN. Si vous incluez chacun des deux, placez le FQDN comme première valeur SAN, suivie de l'adresse IP.

Exemple de configuration :

Une fois que terminé, cliquez sur OK dans la fenêtre de Properties de certificat, puis inscrivez-vous afin de générer le certificat et la finition quand la génération est complète.

Vérifiez le SAN-champ dans le certificat généré

Vérifier juste si le certificat généré contient les informations correctes, vous pouvez les vérifier comme suit :

Ouvrez les Certificats SNAP-dans dans Microsoft Management Console (MMC) et développez les Certificats (ordinateur local) > personnel > des Certificats.

Double-cliquer le certificat généré et ouvrez les détails que tableau font descendre l'écran pour trouver le champ SAN suivant les indications de l'image.

Exportez le certificat pour importer au FND Keystore

Avant que vous puissiez importer ou remplacer le certificat qui existe dans le keystore FND, vous devez l'exporter à un fichier .pfd.

Dans les Certificats SNAP-dans dans le MMC, développez les Certificats (ordinateur local) > personnel > des Certificats

Cliquez avec le bouton droit le certificat généré et sélectionnez toutes les tâches > exportation… suivant les indications de l'image.

Cliquez sur Next, choisi afin d'exporter la clé privée suivant les indications de l'image.

Sélectionnez afin d'inclure tous les Certificats dans le chemin de certification suivant les indications de l'image. 

Cliquez sur Next, sélectionnez un mot de passe pour l'exportation et sauvegardez le .pfx dans un emplacement connu.

Créez le FND Keystore pour l'usage avec PNP

Maintenant que vous faites exporter le certificat, vous pouvez établir le keystore requis pour FND.

Virez le .pfx généré de l'étape précédente sécurisé sur le FND-serveur (ordinateur de NMS (Network Management Systems) ou hôte d'OVULES), par exemple avec l'utilisation du SCP.

Répertoriez le contenu du .pfx pour finir par connaître automatique-généré alias dans l'exportation :

[root@iot-fnd ~]# keytool -list -v -keystore nms.pfx -srcstoretype pkcs12 | grep Alias
Enter keystore password:  keystore
Alias name: le-fnd-8f0908aa-dc8d-4101-a526-93b4eaad9481

Créez un nouveau keystore avec l'utilisation de cette commande :

root@iot-fnd ~]# keytool -importkeystore -v -srckeystore nms.pfx -srcstoretype pkcs12 -destkeystore cgms_keystore_new -deststoretype jks -srcalias le-fnd-8f0908aa-dc8d-4101-a526-93b4eaad9481 -destalias cgms -destkeypass keystore
Importing keystore nms.pfx to cgms_keystore_new...
Enter destination keystore password:
Re-enter new password:
Enter source keystore password:
[Storing cgms_keystore_new]

Warning:
The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore cgms_keystore_new -destkeystore cgms_keystore_new -deststoretype pkcs12".

Dans la commande, assurez-vous que vous remplacez nms.pfx par le fichier correct (exporté de Windows CA) et que les srcalias évaluent des correspondances avec la sortie de la commande précédente (keytool-liste).

Après que vous le génériez, convertissez-le en nouveau format comme suggéré :

[root@iot-fnd ~]# keytool -importkeystore -srckeystore cgms_keystore_new -destkeystore 
cgms_keystore_new -deststoretype pkcs12
Enter source keystore password:
Entry for alias cgms successfully imported.
Import command completed:  1 entries successfully imported, 0 entries failed or cancelled

Warning:
Migrated "cgms_keystore_new" to Non JKS/JCEKS. The JKS keystore is backed up as 
"cgms_keystore_new.old".

Ajoutez le certificat de CA, exporté plus tôt, au keystore :

[root@iot-fnd ~]# keytool -import -trustcacerts -alias root -keystore cgms_keystore_
new -file rootca.cer
Enter keystore password:
Owner: CN=rootca, DC=fnd, DC=iot
Issuer: CN=rootca, DC=fnd, DC=iot
...
Trust this certificate? [no]:  yes
Certificate was added to keystore

Et en conclusion, ajoutez le certificat SUDI, cela est utilisé afin de vérifier l'identité par l'interface série du LOIN quand vous utilisez PNP, au keystore.

Pour une installation RPM, le certificat SUDI est empaqueté avec les modules et peut être trouvé dans : /opt/cgms/server/cgms/conf/ciscosudi/cisco-sudi-ca.pem

Pour une installation d'OVULES, première copie le certificat SUDI à l'hôte :

[root@iot-fnd ~]# docker cp fnd-container:/opt/cgms/server/cgms/conf/ciscosudi/cisco-sudi-ca.pem .

Ajoutez-alors le au keystore comme fait confiance pour le pseudonyme SUDI :

[root@iot-fnd ~]# keytool -import -trustcacerts -alias sudi -keystore cgms_keystore_new -file cisco-sudi-ca.pem
Enter keystore password:
Owner: CN=ACT2 SUDI CA, O=Cisco
Issuer: CN=Cisco Root CA 2048, O=Cisco Systems
...
Trust this certificate? [no]:  yes
Certificate was added to keystore

En ce moment, le keystore est prêt à être utilisé avec FND.

Lancez Keystore nouveau/modifié pour l'usage avec FND

Avant que vous utilisiez le keystore, remplacez la version préalable et mettez à jour sur option le mot de passe dans le fichier cgms.properties.

D'abord, prenez une sauvegarde du keystore qui existe déjà : 

Pour une installation RPM :

[root@fndnms ~]# cp /opt/cgms/server/cgms/conf/cgms_keystore cgms_keystore_backup

Pour une installation d'OVULES :

[root@iot-fnd ~]# cp /opt/fnd/data/cgms_keystore cgms_keystore_backup

Remplacez celui qui existe avec le neuf :

Pour une installation RPM :

[root@fndnms ~]# cp cgms_keystore_new /opt/cgms/server/cgms/conf/cgms_keystore

Pour une installation d'OVULES :

[root@iot-fnd ~]# cp cgms_keystore_new /opt/fnd/data/cgms_keystore

Sur option, mettez à jour le mot de passe pour le keystore dans le fichier cgms.properties :

D'abord, générez une nouvelle chaîne de mot de passe chiffré.

Pour une installation RPM :

[root@fndnms ~]# /opt/cgms/bin/encryption_util.sh encrypt keystore
7jlXPniVpMvat+TrDWqh1w==

Pour une installation d'OVULES :

[root@iot-fnd ~]# docker exec -it fnd-container /opt/cgms/bin/encryption_util.sh encrypt keystore
7jlXPniVpMvat+TrDWqh1w==

Assurez-vous que vous remplacez le keystore par le mot de passe correct pour votre keystore.

Le changement cgms.properties de /opt/cgms/server/cgms/conf/cgms.properties pour le basé sur RPM installent ou /opt/fnd/data/cgms.properties pour le basé sur ovules installent afin d'inclure le nouveau mot de passe chiffré.

En conclusion, reprise FND à commencer utilisant le nouveau keystore et mot de passe.