H.9 Dépannage des services d'infrastructure de clés publiques d'OpenText

Non-fonctionnement des opérations PKI

Si les opérations d'infrastructure de clés publiques (Public Key Infrastructure, PKI) dans Identity Console ne fonctionnent pas, cela peut provenir du fait que les services PKI d'OpenText ne sont pas en cours d'exécution sur l'hôte Linux. Pour démarrer les services PKI, entrez la commande npki -1.

Si vous ne pouvez pas créer de certificats, vous devez vous assurer que le module NICI est correctement installé. Voir Initialisation du module NICI sur le serveur. Pour vérifier si le module NICI est initialisé, voir Vérification de l'installation et de l'initialisation de NICI sur le serveur.

Le retrait de la configuration d'un serveur OpenText eDirectory qui fonctionne comme serveur de clés d'arborescence dans une arborescence multiserveur, après que les objets OpenText eDirectory existants ont été déplacés vers un serveur différent, échoue et renvoie le code d'erreur correspondant à une réplique décisive.

Pour terminer l'opération, vous devez remplacer l'attribut DN du serveur de clés dans l'objet W0, sous le conteneur de sécurité > KAP, par un autre serveur de l'arborescence ayant téléchargé la clé d'arborescence à partir de ce serveur.

  1. Sur la page d'accueil d'OpenText Identity Console, cliquez sur la vignette Gestion des objets.

  2. Dans la liste déroulante Type, sélectionnez Liste des clés du domaine de sécurité, puis sur Rechercher.

  3. Sélectionnez l'objet W0 (généralement W0.KAP.sécurité).

  4. Sélectionnez NDSPKI:SD Key Server DN, puis cliquez sur Modifier l'élément .

  5. Spécifiez le nom et le contexte d'un autre serveur dans le champ DN du serveur de clés du domaine de sécurité, puis cliquez sur OK.

  6. Cliquez sur Appliquer, puis sur OK.

Lors de la désinstallation du serveur OpenText eDirectory contenant l'objet Autorité de certification (CA), les objets KMO créés sur ce serveur sont déplacés vers un autre serveur de l'arborescence et rendus non valides.

Vous devez recréer les objets CA et KMO pour l'arborescence. Pour plus d'informations, reportez-vous aux sections Création d'un objet Autorité de certification organisationnelle et Création d'un objet Certificat de serveur du Guide d'administration d'OpenText™ eDirectory CE 24.4 (v9.3).

Il est recommandé de ne pas désinstaller le serveur OpenText eDirectory sur lequel l'objet Autorité de certification de l'arborescence a été créé.

Utilisation de PKIDiag

PKIDiag est un utilitaire conçu pour diagnostiquer et corriger les objets Serveur de certificats. PKIDiag peut être utilisé pour effectuer les tâches suivantes :

  • Renommer ou déplacer des objets relatifs à des serveurs afin qu'ils respectent l'assignation de nom et le schéma d'endiguement appropriés si un serveur a été déplacé.

  • Créer les objets requis s'ils n'existent pas.

  • Accorder les droits nécessaires entre les objets.

  • Lier les objets s'ils ne le sont pas.

  • Créer les certificats SSL CertificateIP et SSL CertificateDNS s'ils n'existent pas.

  • Corriger les certificats SSL CertificateIP et SSL CertificateDNS s'ils présentent un nom incorrect ou sont périmés ou proches de l'expiration.

La fonctionnalité PKIDiag est utilisée par deux autres processus, la vérification automatique de l'état de santé du serveur et la tâche de création d'un certificat par défaut dans OpenText Identity Console.

La vérification automatique de l'état de santé du serveur est exécutée chaque fois qu'un serveur est redémarré ou que DSREPAIR est exécuté. Vous utilisez le processus de création d'un certificat par défaut pour remplacer les certificats par défaut créés lors de l'installation de Certificate Server. Pour plus d'informations, reportez-vous à la section Création d'objets Certificat de serveur par défaut.

Reportez-vous au document TID #3640106 pour plus d'informations sur PKIDiag et son utilisation.

Message d'attente de la synchronisation des serveurs

Il arrive qu'après la création du certificat de l'utilisateur, le client ne parvienne pas à rafraîchir la vue afin d'inclure le nouveau certificat. Une boîte de dialogue apparaît alors avec un message indiquant que le système attend la synchronisation des serveurs. À ce stade, le certificat de l'utilisateur a été créé, mais les serveurs concernés par la création n'ont pas encore été synchronisés. Vous pouvez fermer la boîte de dialogue sans incidence sur la création du certificat de l'utilisateur.

Erreur lors de la réutilisation de surnoms de certificat

Si une erreur se produit au cours de la création d'un certificat utilisateur, essayez d'utiliser un surnom différent pour le certificat. Le surnom spécifié n'est peut-être pas disponible pour une réutilisation.

Erreur -1426 lors de l'exportation d'une clé privée d'un utilisateur

Tous les serveurs comportant des répliques de la partition dans laquelle réside l'objet Utilisateur doivent disposer du même niveau de cryptographie (NICI américaine/internationale ou NICI restreinte à l'importation). Si ce n'est pas le cas, un message d'erreur -1426 peut s'afficher lorsque vous exportez la clé privée de l'utilisateur si la taille de cette dernière est trop élevée.

Pour exporter la clé privée de l'utilisateur après une erreur -1426, vous devez mettre à niveau la cryptographie sur les serveurs comportant des répliques de la partition ou supprimer la réplique des serveurs disposant d'une cryptographie exportable.

Le serveur utilise un certificat SSL CertificateIP ayant expiré

OpenText eDirectory 9.0 ne prend pas en charge le certificat SSL CertificateIP. Si vous effectuez la mise à niveau vers OpenText eDirectory 9.0 à partir d'une version antérieure, le certificat SSL CertificateIP reste associé au serveur. Lorsque les certificats dans votre environnement expirent, le certificat SSL CertificateIP ne se renouvelle pas automatiquement.

Une fois la mise à niveau vers OpenText eDirectory 9.0 effectuée, vous pouvez commencer à utiliser le certificat SSL CertificateDNS au lieu du certificat SSL CertificateIP quand vous le voulez.

Autorités de certification externes

Certaines autorités de certification tierces telles que VeriSign utilisent une autorité de certification intermédiaire pour signer les certificats de serveur. Pour importer ces certificats dans un objet Certificat de serveur, le certificat de serveur ainsi que l'autorité de certification intermédiaire et le certificat de racine approuvée doivent figurer dans un seul fichier au format PKCS#7 (.p7b). Si votre autorité de certification ne peut pas fournir ce type de fichier, vous pouvez en créer un vous-même en suivant la procédure ci-dessous sur une machine cliente avec Internet Explorer 5.5 ou version ultérieure.

  1. Importez le certificat du serveur dans Internet Explorer. Pour ce faire, double-cliquez sur le fichier ou accédez à Fichier > Ouvrir et sélectionnez le nom de fichier.

  2. Si le certificat de l'autorité de certification externe n'est pas déjà répertorié comme autorité de certification approuvée dans Internet Explorer, importez les autorités de certification intermédiaires ainsi que l'autorité de certification de niveau de la racine de la même manière.

  3. Dans Internet Explorer, sélectionnez Outils > Options Internet. Sélectionnez l'onglet Contenu, puis le bouton Certificats.

  4. Sous l'onglet Personnel, recherchez le certificat du serveur. Sélectionnez-le, puis cliquez sur Exporter.

  5. Acceptez les valeurs par défaut dans l'assistant jusqu'à ce que vous arriviez à la page Format du fichier d'exportation, puis sélectionnez le format Standard de syntaxe de message cryptographique - Certificats PKCS#7 (.p7b).

  6. Continuez la procédure dans l'assistant.

    Le fichier PKCS#7 peut désormais être importé dans l'objet Certificat de serveur.

Déplacement d'un serveur

Si un objet Serveur est déplacé, les objets LDAP, Service SAS et Certificat du serveur (les objets KMO, « Key Material Object », ou objets Matériel clé) de ce serveur doivent également être déplacés. Notez toutefois que la vérification automatique de l'état de santé du serveur déplacera ces objets pour vous la prochaine fois que vous redémarrez le serveur.

Prise en charge de DNS

Si DNS est configuré pour le serveur, le nom de l'objet par défaut pour un certificat de serveur sera :

.CN=<nom_DNS_serveur>.O=<nom_arborescence>

Dans le cas contraire, le nom de l'objet par défaut est le nom distinctif complet du serveur. Vous pouvez modifier le nom de l'objet par défaut en sélectionnant Personnalisé au cours du processus de création du certificat.

Suppression d'un serveur d'OpenText eDirectory

Lorsque vous supprimez un serveur d'OpenText eDirectory™ et le réinstallez dans le même contexte sous le même nom, la réinstallation ne se déroule correctement que si vous supprimez également l'objet Service SAS qui représente le serveur supprimé (s'il existe).

Le processus doit se dérouler comme suit :

  1. Déterminez si les certificats par défaut doivent être sauvegardés. Si c'est le cas, sauvegardez-les.

  2. Supprimez les certificats par défaut.

  3. Supprimez l'objet SAS.

Par exemple, pour un serveur nommé mon_serveur, il peut exister un objet SAS nommé Service SAS – mon_serveur dans le même conteneur que le serveur. Vous devez supprimer manuellement cet objet SAS (via Identity Console) après avoir supprimé le serveur de l'arborescence, mais avant de le réinstaller.

En présence d'un serveur de CA organisationnelle ou de clés SD, vous devez effectuer des opérations supplémentaires. Ces opérations sont décrites dans le document TID #3623407.

Les certificats de serveur par défaut créés pour le serveur doivent également être supprimés, de manière à être recréés lors de la réinsertion du serveur.

Il s'agit des certificats SSL Certificate IP – mon_serveur et SSL Certificate DNS – mon_serveur. Vous devez faire preuve de vigilance lors de la suppression de ces certificats. Si des données ont été codées à l'aide de l'un de ces certificats, il convient de les récupérer avant de supprimer les certificats.

Limitations des noms d'objet des autorités de certification

Les certificats de serveur contenant un caractère @ dans leur nom d'objet peuvent entraîner un échec des connexions SSL. Contactez le support technique pour résoudre le problème.

Vitesse de validation des certificats

Le processus de validation des certificats comprend plusieurs vérifications des données contenues dans le certificat, ainsi que des données dans la chaîne de certificats. Une chaîne de certificats est constituée d'un certificat d'autorité de certification racine et, éventuellement, des certificats des autorités de certification intermédiaires.

La validation des informations contenues dans un certificat et sa chaîne de certificats associée ne nécessite pas beaucoup de temps. Toutefois, l'opération peut être un peu plus longue dans les cas suivants :

  • Si le certificat a été signé par une autorité de certification externe et si un ou plusieurs des certificats ont une extension de point de distribution CRL.

    Afin de valider le certificat, la CRL de chaque certificat applicable dans la chaîne doit être récupérée. La CRL doit alors être examinée pour déterminer si le certificat a été révoqué.

    Si les CRL sont volumineuses ou si le serveur utilisant le point de distribution CRL est occupé, la validation du certificat peut prendre un certain temps. Pour accélérer l'opération, vous pouvez prendre l'une des mesures suivantes (ou les deux) :

    • Augmentez la vitesse de la connexion utilisée pour vérifier l'état de révocation du certificat.

    • Contactez le fournisseur de l'autorité de certification.

  • Si un ou plusieurs certificats comportent une extension AIA OCSP. Si le répondeur OCSP est occupé, la validation peut nécessiter beaucoup de temps.

  • Si vous validez un certificat utilisateur.

    Pour les certificats de serveur, toute la chaîne de certificats est stockée avec le certificat du serveur dans l'objet Matériel clé. Par conséquent, lorsqu'un certificat de serveur est validé, le client peut obtenir tous les certificats nécessaires en lisant simplement un seul objet. Il en va autrement pour les certificats utilisateur. Seul le certificat utilisateur proprement dit est stocké dans l'objet Utilisateur. Par conséquent, le client doit récupérer la chaîne de certificats à partir d'autres objets stockés dans le conteneur de sécurité afin de valider le certificat utilisateur.

    Afin de valider un certificat utilisateur signé par l'autorité de certification organisationnelle, le client doit lire l'objet de cette dernière, afin de récupérer le certificat de l'autorité de certification. Afin de valider un certificat utilisateur signé par une autorité de certification externe, le client doit lire le conteneur de racines approuvées dans le conteneur de sécurité pour composer une chaîne de certificats qui correspond au certificat utilisateur. Dans ce cas, pour que la validation du certificat utilisateur réussisse, un administrateur doit avoir déjà importé les certificats des autorités de certification externes dans le conteneur de racines approuvées.

    Le temps nécessaire à la validation d'un certificat utilisateur peut être réduit en supprimant du conteneur de racines approuvées les certificats ayant expiré qui ne sont plus approuvés.

Validation de certificats après la suppression de l'autorité de certification organisationnelle

Si vous supprimez l'autorité de certification organisationnelle (à un moment autre que lors d'une procédure de sauvegarde et de restauration), vous devez exporter le certificat auto-signé et créer une nouvelle racine approuvée dans le conteneur de racines approuvées. Si vous ne le faites pas, vous rencontrerez le comportement suivant lors de la validation de ces certificats :

  • Les certificats utilisateur signés par l'autorité de certification supprimée ne sont pas valides. Cela est dû au fait que le certificat de l'autorité de certification qui a signé le certificat utilisateur est introuvable dans l'objet Autorité de certification organisationnelle ou dans le conteneur de racines approuvées. Si vous souhaitez que ces certificats utilisateur restent valides, vous devez ajouter le certificat auto-signé de l'ancienne autorité de certification dans le conteneur de racines approuvées.

  • Les certificats de serveur signés par l'autorité de certification supprimée restent valides. Cela est dû au fait que le certificat de l'autorité de certification est stocké dans l'objet Matériel clé, avec le certificat de serveur.

    Si vous avez supprimé l'autorité de certification organisationnelle parce que la clé a été compromise ou en raison d'une faille de sécurité, vous devez révoquer immédiatement tous les certificats utilisateur et de serveur signés par cette autorité. Si vous ne pouvez pas les révoquer, vous devez les supprimer et créer de nouveaux certificats pour les remplacer. Vous devez également demander à tous les utilisateurs susceptibles d'avoir importé le certificat de votre autorité de certification organisationnelle dans leur navigateur de le supprimer.

Changement de nom du conteneur de sécurité

Vous ne pouvez pas renommer le conteneur de sécurité.

OpenText eDirectory ne peut pas valider les certificats après la recréation de l'autorité de certification de l'arborescence

OpenText eDirectory ne parvient pas à valider les certificats après la recréation de l'autorité de certification lors de la mise à niveau d'OpenText eDirectory vers la dernière version ou lors de son installation dans un emplacement personnalisé.

Pour résoudre ce problème, si le chemin d'installation d'OpenText eDirectory est différent de C:\NetIQ\eDirectory (sous Windows) ou /var/opt/novell/eDirectory (sous Linux), vous devez spécifier le chemin du fichier CRL correct conformément au chemin d'installation d'OpenText eDirectory lorsque vous recréez l'autorité de certification de l'arborescence ou lors de la création de l'objet CRL. Vous devez choisir l'option Personnalisé dans Identity Console dans la vignette Gestion des certificats, cliquez sur Gestion de l'autorité de certification lors de la recréation de l'autorité de certification à partir de l'Assistant Configurer l'autorité de certification et spécifier le chemin du fichier CRL correct pour éviter toute erreur. Par exemple, OpenText eDirectory installe par défaut les fichiers CRL dans le chemin C:\NetIQ\eDirectory\htdoc\crl\. Si vous installez eDirectory dans un emplacement personnalisé (C:\emplacement_personnalisé\eDirectory\), veillez à mettre à jour le chemin du fichier CRL lors de la recréation de l'autorité de certification de l'arborescence. Par exemple, C:\emplacement_personnalisé\eDirectory\htdoc\crl\.

REMARQUE :si une version antérieure d'OpenText eDirectory a été installée dans l'emplacement par défaut (C:\Novell\NDS\), vous devez appliquer la solution décrite ci-dessus lorsque vous recréez l'autorité de certification de l'arborescence après une mise à niveau vers la dernière version.

OpenText eDirectory affiche un message d'erreur lorsque l'utilisateur tente de changer de mot de passe dans l'arborescence avec la clé d'arborescence DES

Après la mise à niveau du serveur OpenText eDirectory vers la version 9.2 ou une version ultérieure, s'il existe une clé d'arborescence DES dans l'arborescence OpenText eDirectory, certains utilisateurs ne peuvent pas modifier leur mot de passe et l'erreur -16060 s'affiche. Cela se produit lorsque les mots de passe sont protégés par une clé d'arborescence DES (56 bits) et que le mode FIPS est activé (n4u.server.fips_tls=1) dans le fichier nds.conf.

Pour éviter ce problème, effectuez les étapes suivantes :

  1. Désactivez le mode FIPS sur votre serveur OpenText eDirectory en définissant n4u.server.fips_tls sur 0.

  2. Générez une nouvelle clé d'arborescence 3DES avec SDIdiag 2.7.0 à l'aide de la commande SD -G.

    REMARQUE :Pour installer SDIdiag 2.7.0, vous devez installer eDirectory 8.8.8 P11 sur une nouvelle machine, puis installer SDIdiag 2.7.0 sur la même machine.

  3. Rechiffrez les mots de passe à l'aide de l'utilitaire Diagpwd. Pour plus d'informations, reportez-vous à la section Utilitaire de diagnostic de mot de passe universel.

  4. Activez le mode FIPS sur le serveur OpenText eDirectory en définissant n4u.server.fips_tls sur 1.

  5. Vous devez maintenant être en mesure de modifier le mot de passe de l'utilisateur. Pour plus d'informations, consultez le TID 7024695.

L'autorité de certification OpenText eDirectory ne parvient pas à créer la liste de révocation de certificats (CRL)

Une nouvelle autorité de certification (CA) dans OpenText eDirectory ne parvient pas à créer la liste de révocation de certificats (CRL). Lors de la tentative d'accès à la CRL à partir d'Identity Console, l'erreur -603 s'affiche et l'attribut ndspkiCertificateRevocationList est également manquant.

Il n'y a pour l'instant aucun moyen de contourner ce problème.