Digital Certificate Manager (DCM)

serveur HTTP a été démarré sur le système. J’apprécie la convivialité de DCM et j’utilise l’option Fast Path dans le panneau de gauche chaque fois que c’est possible. La difficulté n’est pas de savoir comment faire quelque chose dans DCM, mais plutôt quoi y faire.

Les certificats numériques et les autorités de certificats gérés par DCM se trouvent dans un stockage de certificats. Un stockage de certificats est un fichier avec une extension .kdb qui réside dans l’IFS (integrated file system) sur l’iSeries. S’il est prévu d’utiliser SSL, un administrateur doit créer un stockage de certificats spécial appelé *SYSTEM sur l’iSeries. L’un des nombreux certificats numériques que contient un stockage de certificats doit être marqué comme le certificat par défaut du stockage en question. Cela permet aux API d’utiliser le stockage de certificats sans que le code de l’application doive connaître le nom de label du certificat à utiliser au moment de l’exécution. Quand vous utilisez DCM pour créer un stockage de certificats, il va peupler le stockage avec un ensemble « en boîte » de CA bien connus que le stockage de certificats juge approuvés. Cette liste de CA change à chaque release lorsque les périodes de validité expirent ou lorsque de nouveaux CA sont disponibles.
L’iSeries a le concept d’une CA locale qui peut être créée via DCM. Vous utilisez une CA locale pour signer numériquement des certificats au lieu de demander à une CA bien connue de les signer. Ces certificats signés par la CA locale sont utiles pour des transactions intranet et d’entreprise à entreprise. Pour utiliser un certificat signé localement dans un environnement d’entreprise à client, il faudra mettre au point la distribution de votre CA local à tous vos clients potentiels. C’est nécessaire pour que le client approuve votre serveur. En principe, on utilise une CA bien connue pour ce scénario, afin d’éliminer l’obstacle de la distribution des CA. Les définitions d’applications ou ID d’applications sont uniques à l’iSeries et fournissent un point de contrôle de gestion des certificats unique pour chaque application. Les diverses interfaces de programmation System SSL sur l’iSeries savent comment utiliser un ID d’application. Un ID d’application peut être créé uniquement dans le stockage de certificats *SYSTEM. La définition identifie quel certificat numérique dans le stockage de certificats *SYSTEM l’application devrait utiliser, en supposant qu’un certificat est nécessaire. Vous pouvez utiliser la définition pour configurer l’utilisation de l’authentification client, même si l’application n’est pas codée pour cela.

Les ID d’application permettent aussi à chaque application d’être plus restrictive vis-à-vis des CA que l’application approuvera. Par défaut, toutes les applications utilisant *SYSTEM, y compris les ID d’application, approuveront toutes les CA marquées comme validées dans le stockage de certificats. Vous pouvez créer une CA Trust List pour identifier un sousensemble des CA validées à marquer comme approuvées.

Chaque ID d’application peut avoir sa propre liste unique. Dans une définition d’application, le support de CRL (Certificate Revocation List) est aussi activé ou désactivé. Une CA peut révoquer un certificat à tout moment après l’avoir signé puis publier une liste de ces certificats révoqués à l’attention d’un serveur LDAP (Lightweight Directory Access Protocol). Avec DCM, vous pouvez configurer l’emplacement de ce serveur et l’attribuer à des CA spécifiques dans le stockage de certificats. Si le support CRL est désactivé, un certificat qui est validé ne sera pas vérifié par rapport à la liste des certificats révoqués de la CA, même si un a été configuré pour la CA signataire. Les applications validées SSL livrées avec l’iSeries sont enregistrées d’emblée de telle sorte que l’attribution d’un certificat à la définition d’application existante soit la seule configuration requise dans DCM.