25.4 Gestion de NetIQ Certificate Server

Création d’un objet Autorité de certification organisationnelle

Cette tâche est décrite à la Section 25.3.2, Création d’un objet Autorité de certification organisationnelle.

Émission d'un certificat de clé publique

Cette tâche vous permet de générer des certificats destinés aux applications codées qui ne reconnaissent pas les objets Certificat de serveur.

Votre autorité de certification organisationnelle fonctionne de la même manière qu'une autorité de certification externe. Autrement dit, elle est capable d'émettre des certificats à partir de requêtes de signature. Vous pouvez émettre des certificats à l'aide de votre autorité de certification organisationnelle lorsqu'un utilisateur envoie une requête vous invitant à signer le certificat. L'utilisateur qui demande le certificat peut se servir du certificat émis et l'importer directement dans l'application qui prend en charge la cryptographie.

Pour émettre un certificat de clé publique :

Affichage des propriétés de l'autorité de certification organisationnelle

Outre les propriétés et les droits eDirectory que vous pouvez visualiser avec tout objet eDirectory, vous pouvez également afficher les propriétés propres à l'autorité de certification organisationnelle, notamment celles qui concernent le certificat de clé publique et le certificat auto-signé qui lui est associé.

Affichage des propriétés du certificat de clé publique d'une autorité de certification organisationnelle

Affichage des propriétés de certificat auto-signé de l'autorité de certification

Exportation d'un certificat auto-signé d'une autorité de certification organisationnelle

Le certificat auto-signé peut être utilisé pour vérifier l'identité de l'autorité de certification organisationnelle ainsi que la validité d'un certificat signé par cette autorité.

À partir de la page de propriétés de l'autorité de certification organisationnelle, vous pouvez afficher les certificats et les propriétés associés à cet objet. À partir de la page de propriétés du certificat auto-signé, vous pouvez exporter le certificat auto-signé dans un fichier qui pourra être utilisé dans des applications codées.

Le certificat auto-signé qui réside dans l'autorité de certification organisationnelle est identique au certificat de racine approuvée d'un objet Certificat de serveur qui, lui, est signé par l'autorité de certification organisationnelle. Tout service qui reconnaît le certificat auto-signé de l'autorité de certification organisationnelle en tant que racine approuvée peut accepter un certificat utilisateur ou un certificat de serveur valide signé par cette autorité.

Cette tâche ne s'applique toutefois pas si l'autorité de certification est subordonnée.

Pour exporter le certificat auto-signé de l'autorité de certification organisationnelle :

Sauvegarde d'une autorité de certification organisationnelle

NetIQ vous recommande de sauvegarder la clé privée ainsi que les certificats de votre autorité de certification organisationnelle en cas d'échec irrécupérable du serveur hébergeant l'autorité de certification organisationnelle. Dans ce cas, le fichier de sauvegarde vous permettra de restaurer votre autorité de certification organisationnelle sur n'importe quel serveur de l'arborescence.

L'autorité de certification organisationnelle doit être sauvegardée lorsqu'elle fonctionne correctement.

Pour pouvoir effectuer une sauvegarde complète de l'autorité de certification, il convient de sauvegarder la base de données CRL ainsi que la base de données de certificats émis à l'aide de la version 9.0 de NetIQ Certificate Server ou d'une version ultérieure.

Pour les autres plates-formes, ces deux bases de données se trouvent dans le même répertoire que les fichiers DIB eDirectory. Les valeurs par défaut de ces emplacements sont les suivantes :

Ces valeurs par défaut peuvent être modifiées lors de l'installation d'eDirectory.

Les fichiers de sauvegarde de la base de données sont crl.db, crl.01 ainsi que le répertoire crl.rfl. Les fichiers de sauvegarde de la base de données d'émission des certificats sont cert.db, cert.lck, cert.01 ainsi que le répertoire cert.rfl.

Le répertoire dib eDirectory doit faire partie d'un plan de sauvegarde standard et régulier.

Pour sauvegarder l'autorité de certification organisationnelle :

Restauration d'une autorité de certification organisationnelle

Si l'objet Autorité de certification organisationnelle a été supprimé ou altéré, ou si le serveur hôte de l'autorité de certification organisationnelle a connu un échec irrérupérable, le bon fonctionnement de l'autorité de certification organisationnelle peut être restauré à l'aide d'un fichier de sauvegarde créé conformément aux indications de la section Sauvegarde d'une autorité de certification organisationnelle.

Pour pouvoir effectuer une restauration complète de l'autorité de certification, il convient de restaurer la base de données CRL ainsi que la base de données de certificats émis à l'aide de la version 9.0 de NetIQ Certificate Server.

Ces deux bases de données se trouvent dans le même répertoire que les fichiers DIB eDirectory. Les valeurs par défaut de ces emplacements sont les suivantes :

Ces valeurs par défaut peuvent être modifiées lors de l'installation d'eDirectory.

Les fichiers de restauration de la base de données CRL sont crl.db, crl.01 ainsi que le répertoire crl.rfl. Les fichiers de restauration de la base de données d'émission des certificats sont cert.db, cert.lck, cert.01 ainsi que le répertoire cert.rfl.

Le répertoire dib eDirectory doit faire partie d'un plan de sauvegarde standard et régulier.

Pour restaurer l'autorité de certification organisationnelle :

Déplacement de l'autorité de certification organisationnelle vers un autre serveur

Vous pouvez déplacer votre autorité de certification organisationnelle d'un serveur vers un autre à l'aide des procédures de sauvegarde et de restauration décrites dans les sections Sauvegarde d'une autorité de certification organisationnelle et Restauration d'une autorité de certification organisationnelle.

Pour pouvoir procéder au déplacement complet de l'autorité de certification, il convient de déplacer la base de données CRL ainsi que la base de données de certificats émis à l'aide de la version 3.2 ou version ultérieure de NetIQ Certificate Server.

Pour les autres plates-formes, ces deux bases de données se trouvent dans le même répertoire que les fichiers DIB eDirectory. Les valeurs par défaut de ces emplacements sont les suivantes :

Ces valeurs par défaut peuvent être modifiées lors de l'installation d'eDirectory.

Les fichiers à déplacer pour la base de données CRL sont crl.db, crl.01 ainsi que le répertoire crl.rfl. Les fichiers à déplacer pour la base de données d'émission des certificats sont cert.db, cert.lck, cert.01 ainsi que le répertoire cert.rfl.

Validation des certificats de l'autorité de certification organisationnelle

Si vous suspectez la présence d'un problème avec un certificat ou que vous pensez qu'il n'est peut-être plus valide, vous pouvez facilement le valider à l'aide d'iManager. Tous les certificats de l'arborescence eDirectory peuvent être validés, y compris ceux émis par des autorités de certification externes.

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

Un résultat indiquant Valide signifie que tous les certificats de la chaîne se sont révélés valides. Les certificats sont considérés comme valides s'ils répondent à un certain nombre de critères prédéfinis. Ainsi, leur période de validité ne doit pas avoir expiré, ils ne doivent pas avoir été révoqués et ils doivent avoir été signés par une autorité de certification approuvée. Seuls les certificats avec une extension de point de distribution CRL ou une extension AIA OCSP sont vérifiés pour la révocation.

Un résultat indiquant Non valide signifie qu'un ou plusieurs certificats de la chaîne se sont révélés non valides ou que leur validité n'a pas pu être déterminée. Des informations supplémentaires sont fournies pour ces certificats et notamment quel certificat est considéré comme non valide et pourquoi. Cliquez sur Aide pour plus d'informations sur le motif.

Pour valider un certificat :

Suppression d'une autorité de certification organisationnelle

La suppression d'un objet Autorité de certification organisationnelle ne doit être effectuée qu'en cas d'absolue nécessité ou si vous restaurez l'autorité de certification organisationnelle à partir d'une sauvegarde (reportez-vous à la section Restauration d'une autorité de certification organisationnelle). La seule méthode sécurisée pour supprimer l'objet est de commencer par le sauvegarder pour pouvoir le restaurer par la suite.

Toutefois, il arrive parfois que l'autorité de certification organisationnelle doivent être supprimée, et non restaurée. Par exemple, lorsque vous fusionnez des arborescences, la nouvelle arborescence ne peut contenir qu'une seule autorité de certification organisationnelle ; l'autre doit être supprimée. Ou, lorsque le serveur hébergeant l'autorité de certification organisationnelle est endommagé et irréparable et qu'aucune sauvegarde de l'autorité de certification ou de la configuration NICI n'a été effectuée, la seule option consiste à supprimer l'autorité de certification et à recommencer.

Pour supprimer l'objet Autorité de certification organisationnelle :

Déploiement d'une autorité de certification organisationnelle

Les deux problèmes importants qui doivent être pris en compte lors du remplacement des certificats de l'autorité de certification organisationnelle (CA) sont les suivants :

Les objets Certificat de serveur (objets Matériel clé) contiennent un certificat de clé publique pour le serveur et le certificat de racine approuvée avec lequel a été signé le certificat de clé publique. Les certificats utilisateur sont stockés en tant qu'attributs sous l'objet Utilisateur et ne sont pas associés à la racine approuvée qui les a signés. Par conséquent, lors du remplacement du certificat de racine approuvée, les certificats de serveur restent valides, car la racine approuvée est toujours accessible. En revanche, les certificats utilisateur perdent immédiatement leur validité, sauf si le certificat de racine approuvée se trouve dans le conteneur de racines approuvées, auquel cas il pourra être localisé à des fins de validation.

L'autorité de certification peut être remplacée pour trois raisons :

Si l'autorité de certification expire, les certificats signés par cette autorité de certification vont expirer eux aussi. Une fois l'autorité de certification remplacée, chacun des certificats signés doit être recréé à l'aide de la nouvelle autorité.

Si l'autorité de certification a été endommagée, son remplacement entraîne la perte de validité des certificats utilisateur signés par l'ancienne autorité. Vous pouvez facilement les remplacer en exécutant la tâche de création des certificats par défaut dans iManager. Tous les certificats créés par défaut par Certificate Server sont recréés avec la nouvelle autorité de certification. Tous les certificats créés de manière personnalisée doivent être recréés manuellement avec la nouvelle autorité de certification. Pour plus d'informations sur la création de certificats par défaut, reportez-vous à la section Création d'objets Certificat de serveur par défaut.

Si vous souhaitez recréer l'autorité de certification pour toute autre raison, le stockage du certificat de racine approuvée dans le conteneur de racines approuvées maintient la validité des certificats utilisateur jusqu'à ce que vous puissiez les recréer à votre convenance.

Pour remplacer le certificat de racine approuvée :

Création d'objets Certificat de serveur

Cette tâche est décrite à la section Section 25.3.6, Création d'un objet Certificat de serveur.

Création d'objets Certificat de serveur par défaut

Le programme d'installation de Certificate Server crée des objets Certificat de serveur par défaut.

Si ces certificats sont altérés ou non valides pour une raison quelconque, ou si vous souhaitez simplement remplacer les certificats par défaut existants, vous pouvez utiliser l'assistant de création de certificats de serveur par défaut, comme indiqué dans la procédure suivante :

Si vous souhaitez mieux contrôler la création de l'objet Certificat de serveur, vous pouvez le créer manuellement. Pour plus d'informations, reportez-vous à la section Création manuelle d'un objet Certificat de serveur.

Importation d'un certificat de clé publique dans un objet Certificat de serveur

L'importation d'un certificat de clé publique est effectuée après avoir créé une requête de signature de certificat (CSR) et que l'autorité de certification (CA) vous a renvoyé un certificat de clé publique signé. Cette tâche s'applique lorsque vous avez créé un objet Certificat de serveur à l'aide de l'option personnalisée associée à l'option de signature par une autorité de certification externe.

L'autorité de certification peut renvoyer le certificat de plusieurs manières. En règle générale, l'autorité de certification renvoie un ou plusieurs fichiers contenant chacun un certificat, ou un fichier contenant plusieurs certificats. Ces fichiers peuvent être des fichiers binaires utilisant le chiffrement DER (.der, .cer, .crt, .p7b) ou peuvent être des fichiers texte codés au format Base64 (.cer ou .b64).

Si le fichier contient plusieurs certificats, il doit utiliser le format PKCS#7 pour pouvoir être importé dans un objet Certificat de serveur. En outre, le fichier doit contenir l'ensemble des certificats à importer dans l'objet (le certificat de l'autorité de certification au niveau de la racine, les certificats des autorités de certification de niveau intermédiaire et le certificat de serveur).

Si l'autorité de certification renvoie plusieurs fichiers après signature du certificat, chaque fichier contient un certificat distinct qui doit être importé dans l'objet Certificat de serveur. En présence de plus de deux fichiers (un pour l'autorité de certification à la racine, un ou plusieurs pour les autorités de certification intermédiaires et un pour le certificat de serveur), ces fichiers doivent être regroupés dans un fichier PKCS#7 afin de pouvoir être importés dans un objet Certificat de serveur.

Plusieurs méthodes permettent de créer un fichier PKCS#7. L'une d'entre elles consiste à importer tous les certificats dans Internet Explorer. Une fois importés, le certificat de serveur et tous les certificats de la chaîne peuvent être exportés au format PKCS#7 à l'aide d'Internet Explorer. Pour des informations sur cette procédure, reportez-vous à la section Autorités de certification externes.

Certaines autorités de certification ne renvoient pas de certificat d'autorité de certification de niveau racine avec le certificat de serveur. Pour obtenir le certificat d'autorité de certification de niveau racine, contactez directement le fournisseur de l'autorité de certification ou appelez le support technique.

Pour importer les certificats dans un objet Certificat de serveur :

Exportation d'un certificat de racine approuvée ou d'un certificat de clé publique

Il existe différentes raisons d'exporter un certificat dans un fichier :

Vous pouvez exporter le certificat dans deux formats de fichier : codage DER (.der) et Base64 (.b64). L'extension .crt peut également être utilisée pour les certificats au codage DER. L'exportation peut également être effectuée dans le Presse-papiers du système au format Base64 afin que le certificat puisse être collé directement dans une application codée.

Pour exporter un certificat de clé publique ou de racine approuvée :

Suppression d'un objet Certificat de serveur

Vous devez supprimer un certificat de serveur si vous pensez que la clé privée a été endommagée, si vous ne voulez plus utiliser la paire de clés ou si la racine de l'objet Certificat de serveur n'est plus approuvée.

Pour supprimer un objet Certificat de serveur :

Affichage des propriétés d'un objet Certificat de serveur

Outre les propriétés et les droits eDirectory que vous pouvez visualiser avec tout objet NDS, vous pouvez également afficher les propriétés propres à l'objet Certificat de serveur, notamment celles qui concernent le certificat de clé publique et le certificat de racine approuvée qui lui est associé (le cas échéant).

Pour afficher les propriétés d'un objet Certificat de serveur :

Affichage des propriétés du certificat de clé publique d'un objet Certificat de serveur

Pour afficher les propriétés du certificat de clé publique d'un objet Certificat de serveur :

Affichage des propriétés du certificat de racine approuvée d'un objet Certificat de serveur

Pour afficher les propriétés du certificat de racine approuvée d'un objet Certificat de serveur :

Sauvegarde d'un objet Certificat de serveur

NetIQ Certificate Server permet de stocker des certificats signés par des autorités de certification tierces dans des objets Certificat de serveur. Souvent, ces certificats sont très coûteux. Malheureusement, si une erreur irrécupérable se produit sur le serveur qui héberge les certificats, l'objet Certificat de serveur devient inutilisable. Pour éviter les désagréments de ce type, vous souhaiterez peut-être sauvegarder les certificats de serveur signés par des autorités de certification externes ainsi que leurs clés privées associées. Ensuite, en cas d'échec, vous pouvez utiliser le fichier de sauvegarde pour restaurer l'objet Certificat de serveur sur n'importe quel serveur de l'arborescence.

Le fichier de sauvegarde contient la clé privée du serveur, un certificat de clé publique, un certificat de racine approuvée et tous les certificats d'autorités de certification intermédiaires. Ces informations sont stockées au format PKCS#12 (également appelé PFX).

Un objet Certificat de serveur doit être sauvegardé lorsqu'il fonctionne correctement.

Pour sauvegarder un objet Certificat de serveur :

Restauration d'un objet Certificat de serveur

Si l'objet Certificat de serveur a été supprimé ou altéré, ou si le serveur qui hébergeait l'objet Certificat de serveur a connu un échec irrécupérable, le bon fonctionnement de l'objet peut être restauré à l'aide d'un fichier de sauvegarde créé conformément aux indications de la section Sauvegarde d'un objet Certificat de serveur.

Si vous n'avez pas pu effectuer une sauvegarde de l'objet Certificat de serveur, vous pourrez peut-être néanmoins toujours l'utiliser si NICI 2.x est installé sur le serveur et qu'une sauvegarde des informations de configuration NICI a été effectuée. Pour plus d'informations sur la procédure de sauvegarde et de restauration des fichiers de configuration NICI, reportez-vous à la section Backing Up and Restoring NICI (Sauvegarde et restauration de NICI) du Novell International Cryptographic Infrastructure Administration Guide (Guide d'administration de Novell International Cryptographic Infrastructure).

Pour restaurer l'objet Certificat de serveur :

La clé privée et les certificats du serveur ont à présent été restaurés et l'objet Certificat de serveur est totalement opérationnel. Si vous le souhaitez, le fichier de sauvegarde peut rester stocké pour une utilisation ultérieure.

Objets Certificat de serveur et mise en grappe

Vous pouvez configurer des objets Certificat de serveur dans un environnement en grappe pour vous assurer que vos applications codées qui utilisent des objets Certificat de serveur puissent toujours y accéder. La fonction de sauvegarde et de restauration des objets Certificat de serveur vous permet de dupliquer le matériel de codage par clé de l'objet d'un noeud de la grappe sur tous les noeuds. Ce processus de codage par clé du matériel signé par une autorité de certification externe vous permet d'économiser de l'argent en vous permettant de dupliquer le matériel de codage pour un certificat de serveur, plutôt que d'exiger du nouveau matériel de codage pour chaque noeud de la grappe.

Pour configurer le fonctionnement des certificats de serveur dans un environnement en grappe :

Validation d'un certificat de serveur

Si vous suspectez la présence d'un problème avec un certificat ou que vous pensez qu'il n'est peut-être plus valide, vous pouvez facilement le valider à l'aide d'iManager. Tous les certificats de l'arborescence eDirectory peuvent être validés, y compris ceux émis par des autorités de certification externes.

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

Un résultat indiquant Valide signifie que tous les certificats de la chaîne se sont révélés valides. Les certificats sont considérés comme valides s'ils répondent à un certain nombre de critères prédéfinis. Ainsi, leur période de validité ne doit pas avoir expiré, ils ne doivent pas avoir été révoqués et ils doivent avoir été signés par une autorité de certification approuvée. Seuls les certificats avec une extension de point de distribution CRL ou une extension AIA OCSP sont vérifiés pour la révocation.

Un résultat indiquant Non valide signifie qu'un ou plusieurs certificats de la chaîne se sont révélés non valides ou que leur validité n'a pas pu être déterminée. Des informations supplémentaires sont fournies pour ces certificats et notamment quel certificat est considéré comme non valide et pourquoi. Cliquez sur Aide pour plus d'informations sur le motif.

Pour valider un certificat :

Révocation d'un certificat de racine approuvée ou auto-signé

Il est parfois nécessaire de révoquer un certificat si la clé ou l'autorité de certification est endommagée, si le certificat a été remplacé par un autre, s'il a été supprimé de la liste de révocation, s'il a cessé de fonctionner, etc.

Déplacement d'un objet Certificat de serveur vers un autre serveur

Vous pouvez déplacer un objet Certificat de serveur d'un serveur vers un autre à l'aide des procédures de sauvegarde et de restauration décrites dans les sections Sauvegarde d'un objet Certificat de serveur et Restauration d'un objet Certificat de serveur.

Remplacement du matériel de codage par clé d'un objet Certificat de serveur

La clé privée et les certificats de l'objet Certificat de serveur peuvent être remplacés. Ils ne doivent toutefois être remplacés qu'à l'aide d'un fichier PFX généré en interne, créé au cours d'une sauvegarde d'un objet Certificat de serveur. Les fichiers PFX générés en externe peuvent aussi être utilisés s'ils contiennent la clé privée, le certificat de serveur et la chaîne de certificats entière. La clé et les certificats dans le fichier ne doivent pas forcément correspondre à ceux qui figurent dans l'objet ; les données dans le fichier écrasent la clé et les certificats de l'objet.

Le remplacement de la clé privée et des certificats de l'objet Certificat de serveur est une opération délicate. Si la clé et les certificats ne correspondent pas exactement à ceux qui figurent dans l'objet, cela revient à supprimer l'objet Certificat de serveur actuel et à en créer un nouveau. Reportez-vous à la section Sauvegarde d'un objet Certificat de serveur pour plus d'informations sur les conséquences de la suppression de l'objet.

Si la clé et les certificats correspondent à ceux de l'objet, le remplacement du matériel de codage par clé n'a aucun effet, si ce n'est de régénérer quelques attributs utilisés par les services d'authentification sécurisée.

Pour remplacer le matériel de codage par clé de l'objet Certificat de serveur :

La clé privée et les certificats du serveur ont à présent été remplacés et le certificat de serveur est totalement opérationnel. Le fichier de sauvegarde doit rester stocké pour une utilisation ultérieure.

Création de certificats utilisateur

Cette tâche est décrite à la section Création d'un certificat utilisateur.

Création groupée de certificats utilisateur

Cette fonction vous permet de créer des certificats utilisateur pour plusieurs utilisateurs simultanément, à l'aide d'une série d'opérations.

Importation d'un certificat de clé publique dans un objet Utilisateur (avec ou sans clé privée)

Vous pouvez importer un certificat de clé publique dans un objet Utilisateur (par exemple, un certificat signé par une autorité de certification tierce). Ce certificat peut utiliser l'un des deux types de fichiers suivants :

Une fois importé, le certificat est stocké dans l'objet Utilisateur et apparaît dans la liste des certificats disponibles.

Pour importer un certificat de clé publique dans un objet Utilisateur :

Affichage des propriétés d'un certificat utilisateur

Outre les droits et propriétés eDirectory qui peuvent être affichées avec n'importe quel objet eDirectory, vous pouvez également afficher les propriétés spécifiques du certificat utilisateur et notamment l'émetteur, l'état du certificat, l'état de la clé privée ainsi que la période de validité.

Exportation d'un certificat utilisateur

Pour échanger des courriers électroniques en toute sécurité avec une autre personne, vous devez d'abord disposer du certificat de clé publique de cet utilisateur. L'une des manières de l'obtenir consiste à l'exporter à l'aide d'iManager. Ce certificat peut également être obtenu à l'aide de LDAP ou par courrier électronique.

Pour exporter votre certificat de clé publique personnel ou celui de tout autre utilisateur :

Exportation d'un certificat utilisateur et de la clé privée

Pour pouvoir utiliser un certificat à des fins d'échange de courriers électroniques, d'authentification ou de chiffrement sécurisés, la clé privée et le certificat doivent être disponibles dans l'application codée. Vous devez exporter le certificat utilisateur et la clé privée et les placer à un emplacement accessible par l'application afin que l'application puisse les utiliser.

Les clés privées de l'objet Utilisateur appartiennent à cet utilisateur. Seul un utilisateur connecté sous l'identité de cet utilisateur peut exporter la clé privée. Aucun autre utilisateur, pas même l'administrateur réseau, n'est autorisé à exporter la clé privée d'un autre utilisateur.

Pour exporter votre clé privée personnelle et le certificat :

Validation d'un certificat utilisateur

Si vous suspectez la présence d'un problème avec un certificat ou que vous pensez qu'il n'est peut-être plus valide, vous pouvez facilement le valider à l'aide d'iManager. Tous les certificats de l'arborescence eDirectory peuvent être validés, y compris ceux émis par des autorités de certification externes.

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

Un résultat indiquant Valide signifie que tous les certificats de la chaîne se sont révélés valides. Les certificats sont considérés comme valides s'ils répondent à un certain nombre de critères prédéfinis. Ainsi, leur période de validité ne doit pas avoir expiré, ils ne doivent pas avoir été révoqués et ils doivent avoir été signés par une autorité de certification approuvée. Seuls les certificats avec une extension de point de distribution CRL ou une extension AIA OCSP sont vérifiés pour la révocation.

Un résultat indiquant Non valide signifie qu'un ou plusieurs certificats de la chaîne se sont révélés non valides ou que leur validité n'a pas pu être déterminée. Des informations supplémentaires sont fournies dans ce cas pour indiquer quel certificat est considéré comme non valide et pourquoi. Cliquez sur Aide pour plus d'informations sur le motif.

Pour valider un certificat :

Révocation d'un certificat utilisateur

Il est parfois nécessaire de révoquer un certificat si la clé ou l'autorité de certification est endommagée, si le certificat a été remplacé par un autre, s'il a été supprimé de la liste de révocation, s'il a cessé de fonctionner, etc.

Suppression d'un certificat utilisateur et de la clé privée

Si un certificat utilisateur n'est plus valide ou si vous pensez que la clé privée a été endommagée d'une quelconque façon, vous devrez peut-être supprimer le certificat utilisateur et la clé privée.

Avant de supprimer un certificat utilisateur et sa clé privée, vous devez révoquer le certificat utilisateur. Reportez-vous à la section Révocation d'un certificat utilisateur.

Pour supprimer un certificat utilisateur et sa clé privée :

Présentation

Lorsque vous créez un certificat X.509, de nombreuses informations importantes doivent être identifiées et vérifiées avant que l'autorité de certification (CA) émette le certificat. Les deux principales tâches sont les suivantes :

Ces deux tâches peuvent durer très longtemps et sont souvent effectuées par un administrateur ou un groupe distinct.

NetIQ Certificate Server a toujours tiré parti des fonctionnalités de gestion sécurisée des identités d'eDirectory afin de réduire le temps et les efforts nécessaires à l'exécution de ces vérifications. iManager permet à un administrateur de créer des certificats utilisateur en bloc ; autrement dit, créer un certificat pour un grand nombre d'utilisateurs simultanément. L'autorité de certification vérifie que l'identité du certificat est liée au compte eDirectory, qui vérifie l'identité de l'objet du certificat. Toutefois, l'autorité de certification n'a pas vérifié l'adéquation du nom d'objet dans le certificat. De ce fait, la création de certificats avec NetIQ Certificate Server a toujours exigé que le logiciel ou la personne dispose des droits d'administrateur sur l'autorité de certification organisationnelle.

L'auto-provisioning permet à un utilisateur ou à un serveur de générer des certificats sans disposer de droits d'administrateur sur l'autorité de certification organisationnelle et sans intervention d'un administrateur ou d'un groupe chargé de l'administration, tout en préservant la sécurité de l'autorité de certification.

NetIQ Certificate Server vérifie l'identité de l'objet du certificat en vérifiant que l'identité du certificat est liée au compte eDirectory. L'autorité de certification permet vérifie également la conformité du nom de l'objet dans le certificat en le comparant aux informations dans eDirectory. L'autorité de certification organisationnelle parvient ainsi à tirer parti des fonctions sécurisées de gestion des identités d'eDirectory afin de réduire les tâches administratives tout en préservant la sécurité de l'autorité de certification.

Auto-provisioning des utilisateurs

Par le passé, la création d'un certificat utilisateur nécessitait des droits d'administrateur sur l'autorité de certification ainsi que des droits sur les attributs de l'objet Utilisateur. Grâce à l'auto-provisioning des utilisateurs, les droits d'administrateur sur l'autorité de certification ne sont pas nécessaires. Toutefois, les droits de lecture (R) et d'écriture (É) sur les attributs userCertificate, NDSPKI:UserCertificateInfo et SAS:SecretStore sont toujours nécessaires.

Si l'auteur de la requête de création du certificat dispose de droits d'administrateur sur l'autorité de certification, la création du certificat n'est pas affectée par l'activation ou non de l'auto-provisioning des utilisateurs. Si l'auteur de la requête de création du certificat ne dispose pas de droits d'administrateur sur l'autorité de certification, le nom de l'objet dans la requête est comparé avec le nom distinctif eDirectory de l'utilisateur ainsi que toutes les valeurs de l'attribut sasAllowableSubjectNames.

Si le nom d'objet correspond, l'autorité de certification vérifie que les autres noms d'objet sont conformes. Pour ce faire, l'autorité de certification vérifie qu'il n'y a pas plusieurs autres noms d'objet. Si le nom existe, il doit s'agir du type de nom de messagerie et il doit correspondre à un nom de messagerie configuré sur l'objet Utilisateur. Si toutes ces vérifications réussissent, il n'est pas nécessaire de disposer de droits d'administrateur sur l'autorité de certification pour créer le certificat.

Pour utiliser l'auto-provisioning des utilisateurs :

Auto-provisioning du serveur

Par le passé, la création d'un certificat de serveur nécessitait des droits d'administrateur sur l'autorité de certification ainsi que sur le contexte dans lequel le certificat de serveur était créé. Grâce à l'auto-provisioning du serveur, les droits d'administrateur sur l'autorité de certification ne sont pas nécessaires. Toutefois, les droits d'administrateur sur le contexte dans lequel le certificat de serveur a été créé sont en revanche toujours nécessaires.

Pour créer le certificat de serveur, vous devez disposer des droits d'administrateur sur l'autorité de certification. La création du certificat n'est pas affectée par l'activation ou non de l'auto-provisioning. Si vous ne disposez pas de droits d'administrateur sur l'autorité de certification, activez l'option Require read rights to operate the CA (Exiger des droits de lecture pour faire fonctionner l'autorité de certification) pour que l'autorité de certification puisse être gérée à partir de la tâche le Configure Certificate Authority (Configurer l'autorité de certification) dans iManager. Des droits d'administrateur sur l'autorité de certification ne sont pas nécessaires si l'une des conditions suivantes est vraie :

Les serveurs ne disposent pas, par défaut, de droits d'écriture sur l'attribut NDSPKI:Private Key de l'autorité de certification. Si l'option Require write rights to operate the CA (Exiger des droits d'écriture pour faire fonctionner l'autorité de certification) est activée dans la tâche Configure Certificate Authority (Configurer l'autorité de certification) dans iManager, vous devez accorder aux serveurs des droits d'écriture sur l'attribut NDSPKI:Private Key de l'autorité de certification.

Pour utiliser l'auto-provisioning du serveur :

Auto-provisioning et tâche d'émission du certificat

La tâche d'émission du certificat permet de créer un certificat à l'aide d'une requête de signature de certificat PKCS#10. Cette tâche permet à l'utilisateur de créer un certificat non lié à un objet eDirectory. Si l'auteur de la requête de création du certificat dispose de droits d'administrateur sur l'autorité de certification, la création du certificat n'est pas affectée Si l'auteur de la requête de création du certificat ne dispose pas de droits d'administrateur sur l'autorité de certification, la requête de certificat est traitée comme une requête d'auto-provisioning des utilisateurs, mais l'auteur ne doit pas disposer de droits sur les attributs userCertificate, NDSPKI:UserCertificateInfo et SAS:SecretStore pour l'objet. Cela est dû au fait que le certificat n'est pas stocké dans eDirectory, de sorte que les droits sur l'objet ne sont pas nécessaires.

L'auto-provisioning des utilisateurs doit être activé pour que des certificats puissent être émis sans disposer les droits d'administrateur sur l'autorité de certification. Effectuez les étapes 1 à 3 de la section Auto-provisioning des utilisateurs.

Pour plus d'informations sur la tâche d'émission d'un certificat, reportez-vous à la section Émission d'un certificat de clé publique.

Fonctionnalité de vérification de l'état de santé PKI

Pour répondre à la demande des clients de fournir des applications non-eDirectory avec des certificats X.509, le code de vérification de l'état de santé PKI disponible dans NetIQ Certificate Server permet désormais d'exporter automatiquement des clés et les certificats X.509 vers le système de fichiers. De cette façon, les applications non-eDirectory peuvent tirer parti des certificats émanant d'eDirectory et gérés par eDirectory.

Lors de l'exécution de la vérification de l'état de santé PKI, tous les certificats existants sont automatiquement écrasés, y compris leurs clés privées. Toutefois, pour veiller à ce qu'aucun certificat et clés privées valides ne soient supprimées, la vérification de l'état de santé PKI détermine si les clés et certificats existants sont les mêmes que ceux configurés dans eDirectory. S'ils sont différents de ceux configurés dans eDirectory, la vérification de l'état de santé PKI crée une sauvegarde de ces fichiers avant de les écraser. De cette façon, les certificats obtenus auprès d'une source externe (par exemple, VeriSign *) ne sont pas supprimés.

Une fois la configuration créée pour le serveur sur l'objet SAS:Service, les clés et certificats associés au serveur spécifié sont automatiquement exportés vers le système de fichiers. Si les clés et les certificats sont remplacés ou mis à jour dans eDirectory (par exemple, si l'objet Certificat de serveur est supprimé et qu'un nouveau est créé avec le même nom), les nouvelles clés et les nouveaux certificats sont automatiquement exportés vers le système de fichiers lors de la prochaine exécution de vérification de l'état de santé PKI.

Pour plus d'informations sur la vérification de l'état de santé PKI, reportez-vous à la Section 25.4.10, Vérification de l'état de santé PKI.

Avant que la vérification de l'état de santé PKI puisse exporter automatiquement les certificats et les clés X.509 vers le système de fichiers, l'objet SAS:Service doit être configuré. En effet, la vérification de l'état de santé PKI lit la configuration de l'objet SAS:Service. Pour plus d'informations sur la configuration de l'objet SAS:Service, reportez-vous à la section Configuration de l'objet SAS:Service pour exporter des certificats eDirectory.

Configuration de l'objet SAS:Service pour exporter des certificats eDirectory

Avant de pouvoir exporter un certificat de serveur eDirectory vers le système de fichiers, le serveur doit d'abord être configuré sur l'objet SAS:Service. Cette création de configuration peut être effectuée automatiquement ou manuellement, en fonction du serveur eDirectory que vous utilisez. Les sections suivantes décrivent ces options plus en détail :

Création d'un conteneur de racines approuvées

Cette tâche est décrite à la section Création d'un conteneur de racines approuvées.

Création d'un objet Racine approuvée

Cette tâche est décrite à la section Création d'un objet Racine approuvée.

Affichage des propriétés d'un objet Racine approuvée

Outre les droits et propriétés eDirectory qui peuvent être affichés avec n'importe quel objet eDirectory, vous pouvez également afficher les propriétés spécifiques de l'objet Racine approuvée et notamment l'émetteur, l'état du certificat ainsi que la période de validité.

Remplacement d'un certificat de racine approuvée

Cette tâche vous permet de remplacer un certificat de racine approuvée stocké dans l'objet Racine approuvée. Elle doit être effectuée si le certificat de racine approuvée est arrivé à expiration.

Vous pouvez remplacer un certificat de racine approuvée à partir de la page de propriétés de l'objet Racine approuvée.

Validation d'un objet Racine approuvée

Si vous suspectez la présence d'un problème avec un certificat ou que vous pensez qu'il n'est peut-être plus valide, vous pouvez facilement le valider à l'aide d'iManager. Tous les certificats de l'arborescence eDirectory peuvent être validés, y compris ceux émis par des autorités de certification externes.

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

Un résultat indiquant Valide signifie que tous les certificats de la chaîne se sont révélés valides. Les certificats sont considérés comme valides s'ils répondent à un certain nombre de critères prédéfinis. Ainsi, leur période de validité ne doit pas avoir expiré, ils ne doivent pas avoir été révoqués et ils doivent avoir été signés par une autorité de certification approuvée. Seuls les certificats avec une extension de point de distribution CRL ou une extension AIA OCSP sont vérifiés pour la révocation.

Un résultat indiquant Non valide signifie qu'un ou plusieurs certificats de la chaîne se sont révélés non valides ou que leur validité n'a pas pu être déterminée. Des informations supplémentaires sont fournies dans ce cas pour indiquer quel certificat est considéré comme non valide et pourquoi. Cliquez sur Aide pour plus d'informations sur le motif.

Pour valider un certificat de racine approuvée :

Révocation d'un certificat de racine approuvée

Il est parfois nécessaire de révoquer un certificat si la clé ou l'autorité de certification est endommagée, si le certificat a été remplacé par un autre, s'il a été supprimé de la liste de révocation, s'il a cessé de fonctionner, etc.

Création manuelle d'un conteneur CRL

Lors de l'installation de Certificate Server, un conteneur CRL est créé si l'utilisateur dispose des droits appropriés pour le créer. Dans le cas contraire, le conteneur CRL peut être créé manuellement par un utilisateur disposant des droits nécessaires une fois l'installation terminée.

Suppression d'un conteneur CRL

La suppression d'un conteneur CRL est possible, mais pas recommandée.

La règle générale consiste à ne pas supprimer un conteneur CRL, un objet Configuration CRL, un objet CRL ni un fichier CRL tant que la date d'émission du dernier certificat qui contient un point de distribution lié n'a pas expiré.

Création d'un objet Configuration CRL

Un objet Configuration CRL peut être créé dans le conteneur CRL. Il s'agit d'un objet qui contient les informations de configuration des objets Liste de révocation de certificats disponibles dans l'arborescence eDirectory. Normalement, l'arborescence ne compte qu'un seul objet Configuration CRL. Il se peut que vous ayez besoin de plusieurs objets Configuration CRL si vous créez ou déployez une nouvelle autorité de certification organisationnelle, mais un seul objet Configuration CRL peut être utilisé pour créer de nouveaux certificats.

L'objet Configuration CRL réside dans le conteneur CRL.

Activation d'un objet Configuration CRL

Une arborescence eDirectory ne peut contenir qu'un seul objet Configuration CRL à la fois. Si vous avez plusieurs objets Configuration CRL, vous devez en choisir un à activer. Par défaut, le premier objet Configuration CRL créé est actif.

Affichage et modification des propriétés d'un objet Configuration CRL

Suppression d'un objet Configuration CRL

Bien que la suppression d'un objet Configuration CRL soit possible, elle n'est pas recommandée. Lorsqu'un objet Configuration CRL est supprimé, le serveur s'arrête et crée les fichiers CRL. Si un fichier CRL existe déjà à l'emplacement indiqué dans l'objet CRL, la validation de certificat continue de l'utiliser jusqu'à ce qu'il arrive à expiration. Une fois arrivé à expiration, la validation de tous les certificats disposant d'un point de distribution CRL faisant référence à ce fichier CRL échoue.

La règle générale consiste à ne pas supprimer un conteneur CRL, un objet Configuration CRL, un objet CRL ni un fichier CRL tant que la date d'émission du dernier certificat qui contient un point de distribution lié n'a pas expiré.

Création d'un objet CRL

Cette tâche vous permet de créer un objet CRL (cRLDistributionPoint) pour stocker des CRL tierces dans eDirectory. Cet objet peut être créé dans n'importe quel conteneur de l'arborescence eDirectory. Toutefois, les objets CRL NetIQ se trouvent généralement dans un objet Configuration CRL et ne doivent pas être créés manuellement. Un objet CRL est créé automatiquement pour vous lorsque vous créez un objet Configuration CRL.

L'objet CRL héberge un fichier CRL qui contient des informations détaillées sur la liste de révocation des certificats. Pour chaque objet CRL NetIQ, un fichier CRL est automatiquement créé et mis à jour chaque fois que le serveur en émet un nouveau. Pour les autres objets CRL, vous devez importer un fichier CRL à partir d'une autorité de certification tierce.

Pour créer un objet CRL :

Exportation d'un fichier CRL

Vous pouvez exporter la liste de révocation de certificats contenue dans l'objet Point de Distribution CRL vers un fichier.

Pour exporter un fichier CRL NetIQ :

Pour exporter un fichier CRL tiers :

Remplacement d'un fichier CRL

Vous pouvez remplacer un fichier CRL, mais cette opération n'est pas recommandée.

Si un fichier CRL n'existe pas dans l'objet Configuration CRL, le bouton Importer s'affiche.

Affichage des propriétés d'un objet CRL

Pour afficher les propriétés d'un objet CRL NetIQ :

Pour afficher les propriétés d'un objet CRL tiers :

Suppression d'un objet CRL

Si vous supprimez un objet CRL, il sera recréé la prochaine fois que le serveur génèrera le fichier CRL. Si vous supprimez un objet CRL créé et importé à l'aide d'iManager, il est définitivement supprimé et tous les certificats qui y font référence sont considérés comme non valides.

La règle générale consiste à ne pas supprimer un conteneur CRL, un objet Configuration CRL, un objet CRL ni un fichier CRL tant que la date d'émission du dernier certificat qui contient un point de distribution lié n'a pas expiré.

Résolution de plusieurs conteneurs de sécurité, autorités de certification organisationnelles, conteneurs KAP et objets W0

NetIQ Certificate Server peut être installé sur plusieurs serveurs d'une arborescence eDirectory. Toutefois, pour lui permettre de fonctionner correctement, l'arborescence ne peut contenir qu'un seul conteneur de sécurité, une seule autorité de certification organisationnelle, un conteneur KAP et un objet W0.

Si vous installez NetIQ Certificate Server sur plusieurs serveurs d'une arborescence eDirectory, vous devez autoriser eDirectory à effectuer des réplications entre chaque installation de NetIQ Certificate Server. À défaut, votre installation sur un autre serveur risque de ne pas reconnaître que l'arborescence héberge déjà un conteneur de sécurité, une autorité de certification organisationnelle, un conteneur KAP et un objet W0, et pourrait recréer ces objets sur un autre serveur de la même arborescence eDirectory.

Les cas de figure suivants décrivent les scénarios possibles et comment les résoudre.

Restauration ou recréation d'un conteneur de sécurité

Si vous supprimez le conteneur de sécurité, vous ne pouvez pas créer d'autorité de certification organisationnelle tant que vous n'avez pas restauré ou recréé le conteneur de sécurité.

Pour restaurer le conteneur de sécurité, vous devez restaurer la partition eDirectory hébergeant le conteneur de sécurité.

Pour recréer le conteneur de sécurité, utilisez l'une des deux méthodes suivantes :

Restauration ou recréation d'objets KAP et W0

Ne supprimez pas les objets KAP ni W0. Tous les certificats utilisateur précédemment créés ne seraient alors plus valides. Si vous avez supprimé l'un de ces objets, accédez au site Web du support Novell et recherchez le document TID #3032354, How to Restore or Recreate KAP and W0 Object (Comment restaurer ou recréer des objets KAP et W10) pour plus d'informations sur la procédure de résolution de ce problème. N'essayez pas de procéder à d'autres installations de NetIQ Certificate Server, Single Sign-on, NMAS ou eDirectory tant que les problèmes n'ont pas été résolus.