Cette section décrit les composants de NetIQ Certificate Server.
NetIQ Certificate Server est constitué du composant serveur PKI et d'un module de plug-ins pour iManager. iManager est l'interface d'administration de Certificate Server.
Certificate Server permet d'exécuter les tâches suivantes :
Établir une autorité de certification organisationnelle propre à votre arborescence eDirectory et à votre organisation.
Demander, gérer et stocker les certificats de clé publique et les clés privées qui y sont associées dans l'arborescence eDirectory.
eDirectory prend en charge les clés d'une taille allant jusqu'à 4096 bits. Si vous envisagez d'utiliser des certificats X.509 avec une clé publique RSA de 4096 bits pour vos applications, ces dernières doivent prendre en charge ce type de clé ou elles ne fonctionneront pas correctement.
Si vous utilisez un certificat X.509 avec des clés publiques RSA de 4096 bits pour établir des connexions TLS, les performances seront moins bonnes que celles obtenues avec des clés publiques RSA de 2048 bits.
Certificate Server vous permet de sélectionner la taille de clé lorsque vous créez un certificat.
Outre les certificats RSA, Certificate Server prend également en charge l'utilisation et la gestion des certificats et des clés ECDSA (Elliptic Curve Digital Signature Algorithm).
Une paire de clés ECDSA présente une sécurité comparable et une taille nettement inférieure à celles d'une clé RSA, a une taille considérablement inférieure à la clé RSA et améliore considérablement les performances lorsqu'il est utilisé lors de l'établissement de connexions TLS. ECDSA fait appel à la cryptographie basées sur les courbes elliptiques (ECC), une technologie qui génère des clés par le biais de courbes elliptiques. La technologie ECC peut être utilisée conjointement avec la plupart des méthodes de chiffrement par clés publiques, telles que RSA et Diffie-Hellman. L'utilisation de signatures ECC avec des certificats numériques offre des avantages supplémentaires en termes de taille et de performances.
eDirectory prend en charge les certificats ECDSA avec des clés basées sur les courbes suivantes :
P-256
P-384
P-521
En mode SuiteB, Certificate Server respecte la convention RFC 5759. Cette convention RFC stipule que tous les certificats et listes de révocation de certificats (CRL) doivent être signés au moyen d'ECDSA avec des clés générées à l'aide de la courbe P-256 ou P-384.
Si le certificat contient une clé basée sur la courbe P-256, la clé de l'autorité de certification signataire doit être sur la courbe P-256 ou P-384. Si le certificat contient une clé basée sur la courbe P-384, la clé de l'autorité de certification signataire doit être sur la courbe P-384. Tous les certificats et CRL doivent être hachés à l'aide de l'algorithme SHA-256 ou SHA-384, en fonction de la taille de la clé de l'autorité de certification signataire.
Une fois NetIQ Certificate Server installé, vous pouvez le gérer à l'aide d'iManager.
iManager permet d'effectuer les tâches suivantes :
Pendant l'installation, vous pouvez choisir de créer une autorité de certification (CA) organisationnelle si l'arborescence eDirectory n'en comporte pas déjà une. Vous pouvez également créer ou recréer l'autorité de certification organisationnelle une fois l'installation terminée.
L'objet Autorité de certification organisationnelle contient la clé publique, la clé privée, le certificat, la chaîne de certificats et d'autres informations de configuration la concernant. Cet objet se trouve dans le conteneur de sécurité d'eDirectory.
Dès qu'un serveur est configuré pour offrir le service d'Autorité de certification, il peut le fournir à l'ensemble de l'arborescence eDirectory. Si l'arborescence comporte un certificat d'autorité de certification subordonnée et que vous mettez à niveau le serveur hébergeant la CA subordonnée vers eDirectory 9.0, aucun certificat ECDSA de CA n'est généré. L'administrateur doit importer un certificat ECDSA d'autorité de certification subordonnée portant le même nom d'objet que le certificat RSA de la CA subordonnée. Si le serveur qui agit en qualité d'autorité de certification exécute eDirectory 9.0, eDirectory crée les certificats ECDSA pour la CA organisationnelle. eDirectory crée automatiquement les certificats ECDSA pour les serveurs si l'autorité de certification organisationnelle dispose d'un certificat ECDSA.
Pour plus d'informations sur la création d'une autorité de certification organisationnelle, reportez-vous à la section Création d’un objet Autorité de certification organisationnelle.
Le programme d'installation de Certificate Server crée des objets Certificat de serveur par défaut.
SSL CertificateDNS - nom_serveur
Un certificat pour chaque adresse IP configurée sur le serveur (IP AG xxx.xxx.xxx.xxx - nom_serveur)
Un certificat pour chaque nom DNS configuré sur le serveur (DNS AG www.exemple.com - nom_serveur)
SSL EC CertificateDNS - nom_serveur
Un certificat pour chaque adresse IP configurée sur le serveur (IP EC AG xxx.xxx.xxx.xxx - nom_serveur)
Un certificat pour chaque nom DNS configuré sur le serveur (DNS EC AG www.exemple.com - nom_serveur)
REMARQUE :eDirectory 9.0 ne crée pas automatiquement le certificat SSL CertificateIP. Le nom CertificateDNS SSL contient toutes les adresses IP répertoriées dans le champ Subject Alternative Name (Autre nom de l'objet).
Vous pouvez créer des autres objets Certificat de serveur une fois l'installation terminée.
L'objet Certificat de serveur contient la clé publique, la clé privée, le certificat et la chaîne de certificats qui active les services de sécurité SSL pour les applications serveur. Les objets Certificat de serveur peuvent être signés par l'autorité de certification organisationnelle ou par une CA externe.
Un serveur peut être associé à plusieurs objets Certificat de serveur. Toutes les applications codées exécutées sur un serveur spécifique peuvent être configurées pour utiliser n'importe lequel des objets Certificat de serveur de ce serveur. Plusieurs applications exécutées sur un serveur donné peuvent utiliser le même objet Certificat de serveur. Toutefois, un objet Certificat de serveur ne peut pas être partagé par plusieurs serveurs.
Vous ne pouvez créer des objets Certificat de serveur que dans le conteneur où se trouve le serveur. Si l'objet Serveur est déplacé, tous les objets Certificat de serveur appartenant à ce serveur doivent être déplacés aussi. Vous ne devez pas renommer les objets Certificat de serveur. Vous pouvez déterminer quels objets Certificat de serveur appartiennent à un serveur en recherchant le nom du serveur dans le nom des objets Certificat de serveur ou en consultant le champ Serveur hôte lorsque vous affichez l'objet Certificat de serveur dans iManager.
La paire de clés stockée dans l'objet Certificat de serveur est référencée par le nom que vous saisissez au moment de sa création. Le nom de la paire de clés n'est pas celui de l'objet Certificat de serveur. Lorsque vous configurez des applications codées pour qu'elles utilisent des paires de clés, vous référencez ces clés d'après le nom de la paire à laquelle elles appartiennent, et non d'après le nom de l'objet Certificat de serveur.
Si les objets Certificat de serveur par défaut sont endommagés ou non valides, utilisez l'assistant de création de certificats par défaut pour remplacer les anciens certificats par défaut. Pour plus d'informations sur la façon d'accéder à l'assistant de création de certificats par défaut, reportez-vous à la section Création d'objets Certificat de serveur par défaut.
Par défaut, eDirectory crée des certificats ECDSA si l'autorité de certification organisationnelle dispose d'un certificat ECDSA.
Les utilisateurs ont accès à leurs propres certificats et clés privées, qui servent à l'authentification, au chiffrement/déchiffrement des données, à la signature numérique et à la sécurisation du courrier électronique. Ces certificats sont souvent utilisés pour l'envoi et la réception de courriers électroniques chiffrés et signés numériquement à l'aide de la norme S/MIME.
En règle générale, seul l'administrateur de l'autorité de certification dispose de droits nécessaires pour créer des certificats utilisateur. Toutefois, seul l'utilisateur dispose de droits lui permettant d'exporter ou de télécharger la clé privée à partir d'eDirectory. N'importe quel utilisateur peut exporter le certificat de clé publique de tout autre utilisateur.
Le certificat utilisateur est créé sous l'onglet Sécurité de la page de propriétés de l'utilisateur et signé par l'autorité de certification organisationnelle. Les clés privées et les certificats créés par d'autres autorités de certification peuvent être importés après leur création.
Plusieurs certificats peuvent être stockés sur l'objet de l'utilisateur.
Pour plus d'informations sur la création d'un certificat utilisateur, reportez-vous à la section Création d'un certificat utilisateur.
Les racines approuvées constituent la base de l'approbation dans le cadre de la cryptographie à clé publique. Elles sont utilisées pour valider les certificats signés par d'autres autorités de certification, et permettent d'établir des connexions SSL sécurisées, de sécuriser le courrier électronique et de procéder à l'authentification par certificat.
Un conteneur de racines approuvées est un objet eDirectory qui contient des objets Racine approuvée.
Le conteneur de racines approuvées par défaut est CN=trusted roots.CN=security.
Pour plus d'informations sur la création d'un conteneur de racines approuvées, reportez-vous à la section Création d'un conteneur de racines approuvées.
Un objet Racine approuvée est un objet eDirectory qui contient le certificat de racine approuvée authentique et valide d'une autorité de certification. Vous pouvez exporter et utiliser le certificat de racine approuvée selon vos besoins. Les applications configurées pour utiliser le certificat de racine approuvée considèrent qu'un certificat est valide s'il a été signé par l'une des autorités de certification présentes dans le conteneur de racines approuvées.
L'objet Racine approuvée doit se trouver dans un conteneur de racines approuvées.
Pour plus d'informations sur la création d'un objet Racine approuvée, reportez-vous à la section Création d'un objet Racine approuvée.
L'administrateur de l'autorité de certification peut utiliser la CA organisationnelle afin de signer des certificats pour des utilisateurs et des serveurs externes à eDirectory. Ces certificats sont demandés par le biais d'une requête de signature de certificat PKCS#10 qui est transmise à l'administrateur de l'autorité de certification en mode hors bande.
Lorsqu'il reçoit une requête de signature de certificat, l'administrateur de l'autorité de certification peut émettre le certificat à l'aide de l'outil d'émission de certificats disponible dans iManager. Le certificat généré n'est pas stocké dans un objet au sein d'eDirectory. Il doit être renvoyé au demandeur en mode hors bande.
NetIQ Certificate Server permet de vérifier la validité de tous les certificats présents dans l'arborescence eDirectory. Le processus de validation des certificats vérifie chaque certificat de la chaîne de certificats jusqu'au certificat de racine approuvée et renvoie un état Valide ou Non valide.
Pour vérifier la validité des certificats de l'autorité de certification organisationnelle, reportez-vous à la section Validation des certificats de l'autorité de certification organisationnelle.
Pour vérifier la validité des certificats d'un serveur, reportez-vous à la section Validation d'un certificat de serveur.
Pour vérifier la validité des certificats d'un utilisateur, reportez-vous à la section Validation d'un certificat utilisateur.
Pour vérifier la validité des certificats d'une racine approuvée, reportez-vous à la section Validation d'un objet Racine approuvée.
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.
Pour que les certificats utilisateur ou les certificats d'autorité de certification intermédiaire situés dans le conteneur CN=trusted roots.CN=security et signés par des CA externes puissent être validés correctement, le certificat de la CA externe doit être stocké dans un objet Racine approuvée.
Une liste de révocation de certificats est une liste qui répertorie des certificats révoqués et les raisons pour lesquelles ils ont été révoqués.
NetIQ Certificate Server fournit un système de gestion des listes de révocation de certificats. Ce système est facultatif, mais doit être implémenté si vous souhaitez être en mesure de révoquer les certificats créés par l'autorité de certification organisationnelle. Pour plus d'informations sur la gestion des listes de révocation de certificats, reportez-vous à la Section 25.4.7, Tâches relatives aux listes de révocation de certificats.
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.
Un objet Configuration CRL peut être créé dans le conteneur CRL. Cet objet 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.
Un objet CRL, également connu sous le nom de point de distribution, peut être créé dans n'importe quel conteneur de l'arborescence eDirectory. Toutefois, les objets CRL NetIQ se trouvent généralement dans un conteneur CRL. 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. Lorsqu'un serveur qui contient l'autorité de certification de l'organisation est mis à niveau vers eDirectory 9.0, le processus de mise à niveau crée automatiquement des points de distribution de CRL. En outre, eDirectory fournit des objets Configuration CRL distincts pour les certificats RSA et ECDSA.
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.
Si vous supprimez un objet CRL, il sera recréé la prochaine fois que le serveur génère 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é.
Les clés d'utilisateur, de serveur et d'autorité de certification peuvent être marquées comme exportables lors de leur création. Si une clé est exportable, elle peut être extraite et placée dans un fichier avec le certificat associé. Le fichier est écrit dans un format standard pour le secteur (PFX ou PKCS#12) lui permettant d'être transporté vers d'autres plates-formes. Il est chiffré avec un mot de passe défini par l'utilisateur afin de protéger la clé privée.
L'exportation de certificats et de clés privées peut être effectuée afin d'obtenir une copie de sauvegarde de la clé, de déplacer la clé sur un autre serveur ou de partager la clé entre les serveurs.
Pour plus d'informations sur l'exportation des clés privées et des certificats, reportez-vous à la section Exportation d'un certificat utilisateur et de la clé privée.
Vous pouvez choisir d'importer une clé au lieu d'en créer une nouvelle au moment de la création d'un objet Certificat de serveur, Certificat utilisateur ou Autorité de certification. La clé et ses certificats associés doivent être au format PFX ou PKCS#12.
Vous pouvez choisir d'importer une clé au lieu d'en créer une nouvelle pour un objet Autorité de certification afin d'effectuer une récupération à la suite d'une défaillance du serveur, pour déplacer l'autorité de certification organisationnelle d'un serveur vers un autre ou pour une autorité de certification qui est subordonnée à une autre.
Vous pouvez choisir d'importer un certificat utilisateur ou un clé privée si elle a été signée par une autorité de certification tierce.
Vous pouvez choisir d'importer une clé au lieu d'en créer une nouvelle pour un objet Certificat de serveur afin d'effectuer une récupération à la suite d'une défaillance du serveur, pour déplacer la clé et le certificat vers un autre serveur ou pour partager la clé et le certificat avec un autre serveur.
L'objet Service SAS facilite la communication entre un serveur et ses certificats. Si vous supprimez un serveur d'une arborescence eDirectory, vous devez également supprimer l'objet Service SAS qui lui est associé. Si vous souhaitez restaurer le serveur dans l'arborescence, vous devez créer l'objet Service SAS qui l'accompagne. À défaut, vous ne pouvez pas créer de nouveaux certificats de serveur.
L'objet Service SAS est automatiquement créé dans le cadre de la vérification de l'état de santé du serveur. Il n'est pas nécessaire de le créer manuellement.
Vous ne pouvez créer un nouvel objet Service SAS que si le conteneur de l'objet Serveur ne contient pas encore d'objet Service avec un nom approprié. Par exemple, pour un serveur nommé WAKE, l'objet Service SAS est appelé Service SAS – WAKE. L'utilitaire ajoute les pointeurs DS de l'objet Serveur vers l'objet SAS, et de l'objet SAS vers l'objet Serveur. Il configure également les entrées ACL correctes sur l'objet Service SAS.
Si un objet Service SAS avec un nom approprié existe déjà, vous ne pouvez pas en créer un nouveau. Les pointeurs DS de l'ancien objet Service SAS peuvent être erronés ou manquants ou les ACL peuvent se révéler incorrectes. Dans ce cas, vous pouvez supprimer l'objet Service SAS altéré et utiliser iManager pour en créer un nouveau. S'il existe des certificats de serveur qui appartiennent à ce serveur, vous devez les lier manuellement à l'objet Service SAS, en utilisant l'onglet Autre.
Pour plus d'informations sur la création d'un objet Service SAS, reportez-vous à la section Création d'un objet Service SAS.
Novell International Cryptographic Infrastructure (NICI) est l'infrastructure cryptographique sous-jacente permet à NetIQ Certificate Server, aux services NetIQ Modular Authentication Services (NMAS) ainsi qu'à d'autres applications de fournir des services de chiffrement.
NICI doit être installé sur le serveur pour permettre le bon fonctionnement de NetIQ Certificate Server. NICI n'est pas livré avec NetIQ Certificate Server. Dans la plupart des cas, NICI est fourni et installé lorsque NetIQ Certificate Server est intégré dans un autre produit, tel qu'Open Enterprise Server (OES) ou eDirectory. Si vous avez besoin d'une version plus récente de NICI, vous pouvez la télécharger à partir du site Web de téléchargement NetIQ.