Sécurisation des communications à l'aide de la couche SSL

Le protocole SSL (Secure Sockets Layer) fournit une sécurité de couche transport comprenant l'authenticité, la signature des données et le chiffrement des données pour garantir une connexion sécurisée entre un client et un serveur utilisant WebSphere Application Server. Il repose sur la technologie de chiffrement par clé publique. Lorsqu'une entité chiffre des données à l'aide de sa clé publique, seules les entités possédant la clé privée correspondante peuvent les déchiffrer.

WebSphere Application Server utilise l'implémentation JSSE (Java™ Secure Sockets Extension) qui est l'implémentation SSL pour les connexions sécurisées. JSSE fait partie de la spécification J2SE (Java 2 Standard Edition) et il est inclus dans l'implémentation IBM® de l'environnement JRE (Java Runtime Extension). Il est chargé de la négociation pour l'établissement de liaison et offre des fonctions de protection fournies par SSL pour s'assurer qu'une connectivité sécurisée a été établie entre la plupart des protocoles. JSSE repose sur des paires de clés asymétriques fondées sur des certificats X.509 pour la protection des connexions sécurisées et le chiffrement de certaines données. Les paires de clés chiffrent efficacement les clés secrètes fondées sur la session qui chiffrent des blocs de données de taille supérieure. L'implémentation SSL gère les certificats X.509.

WebSphere Application Server est livré avec Java SE7. Par défaut, Java SE 7 active SNI (Server Name Indication). SNI est une extension du protocole TLS. SNI permet à un client de spécifier le nom d'hôte auquel il tente de se connecter. Des exceptions sont générées si le certificat renvoyé ne correspond pas au nom d'hôte attendu.

Dans certains environnements proxy, cela entraîne des erreurs. Le client s'attend à recevoir le certificat du proxy, mais il reçoit le certificat du noeud final.

Gestion des certificats X.509

Les communications sécurisées de WebSphere Application Server requièrent des certificats X.509 signés numériquement. Le contenu d'un certificat X.509, tel que le nom distinctif et l'expiration, est signé par une autorité de certification, par un certificat racine dans NodeDefaultRootStore ou DmgrDefaultRootStore, ou il est auto-signé. Lorsqu'une autorité de certification habilitée signe un certificat X.509, WebSphere Application Server identifie ce dernier et le distribue librement. Un certificat doit être signé par une autorité de certification car il représente l'identité d'une entité auprès du grand public. Les ports côté serveur qui acceptent les connexions provenant du grand public doivent utiliser des certificats signés par une autorité de certification. La plupart des clients ou navigateurs disposent déjà du certificat de signataire qui peut valider le certificat X.509, ce qui permet d'établir une connexion sans procéder à un échange de signataire.

Vous pouvez considérer l'identité d'un certificat X.509 auto-signé comme étant digne de confiance que si un homologue situé dans un environnement contrôlé, tel que les communications réseau internes, accepte le certificat de signataire. Pour établir une liaison sécurisée, vous devez d'abord envoyer une copie du certificat de l'identité à tous les homologues qui se connectent à cette dernière.

L'autorité de certification (CA) et les certificats X.509 chaînés et autosignés résident dans des fichiers de clés Java. JSSE fournit une référence au fichier de clés dans lequel se trouve un certificat. Vous avez le choix entre plusieurs types de fichiers de clés, y compris les fichiers de clés de type JCE (Java Cryptographic Extension) et de type matériel. Généralement, chaque configuration JSSE possède deux références de fichier de clés Java : un fichier de clés et un fichier de clés certifiées. La référence du fichier de clés représente un objet de fichier de clés Java qui contient des certificats personnels. La référence du fichier de clés certifiées représente un objet de fichier de clés Java qui contient des certificats de signataire.

Un certificat personnel sans clé privée est un certificat X.509 qui représente l'entité qui le détient au cours d'un établissement de liaison. Les certificats personnels contiennent à la fois des clés publiques et privées. Un certificat de signataire est un certificat X.509 qui représente l'entité elle-même ou un homologue. Les certificats de signataire contiennent uniquement la clé publique et vérifient la signature de l'identité reçue au cours d'un établissement de liaison de poste à poste.

Pour plus d'informations, voir Ajout des certificats de signataire SSL corrects au magasin de clés du plug-in

Pour plus d'informations sur les fichiers de clés, voir Configurations de fichier de clés pour SSL.

Echange de signataire

Lorsque vous configurez une connexion SSL, vous pouvez échanger des signataires pour établir des relations de confiance dans un certificat personnel pour une entité spécifique. L'échange de signataire permet d'extraire le certificat X.509 du fichier de clés homologue et de l'ajouter au fichier de clés certifiées d'une autre entité afin que les deux entités homologues puisse se connecter. Le certificat de signataire peut également être émis par une autorité de certification en tant que certificat de signataire racine, en tant que certificat de signataire racine du certificat chaîné ou en tant que certificat de signataire intermédiaire. Vous pouvez également extraire un certificat de signataire directement à partir d'un certificat auto-signé, qui est le certificat X.509 associé à la clé publique.

La figure 1 illustre une possible configuration de fichier de clés et de fichier de clés certifiées. Une configuration SSL détermine les entités pouvant se connecter à d'autres entités ainsi que les connexions homologues considérées comme étant dignes de confiance à la suite d'un établissement de liaison SSL. Si vous ne disposez pas du certificat de signataire nécessaire, l'établissement de liaison échoue car l'homologue n'est pas considéré comme étant digne de confiance.
Figure 1. Echange de signataire
La figure 1 illustre un exemple de configuration contenant un fichier de clés et un fichier de clés certifiées. Une configuration SSL détermine les entités pouvant se connecter à d'autres entités ainsi que les connexions homologues considérées comme étant dignes de confiance à la suite d'un établissement de liaison SSL. Si vous ne disposez pas du certificat de signataire nécessaire, l'échange de protocoles échoue car l'homologue n'est pas considéré comme étant digne de confiance.

Dans cet exemple, le fichier de clés certifiées de l'entité A comporte trois signataires. L'entité A peut se connecter à n'importe quel homologue à condition que l'un des trois signataires valide son certificat personnel. Par exemple, l'entité A peut se connecter à l'entité B ou C car les signataires peuvent considérer les deux certificats personnels signés comme étant dignes de confiance. Le fichier de clés certifiées de l'entité B comporte un signataire. L'entité B peut se connecter à l'entité C uniquement, à condition que le noeud final homologue utilise le certificat 1 de l'entité C comme son identité. Les ports qui utilisent l'autre certificat personnel pour l'entité C ne sont pas considérés comme étant dignes de confiance par l'entité B. Par conséquent, l'entité C peut se connecter uniquement à l'entité A.

Dans l'exemple, la configuration auto-signée semble représenter une relation un à un entre le signataire et le certificat. Toutefois, lorsqu'une autorité de certification signe un certificat, elle en signe généralement plusieurs à la fois. L'utilisation d'un seul signataire d'autorité de certification permet de valider des certificats personnels générés par l'autorité de certification et devant être utilisés par des homologues. Toutefois, si le signataire est une autorité de certification publique, vous devez savoir que les certificats signés peuvent avoir été générés par une société différente de celle de l'entité cible. Pour vos communications internes, il est préférable de faire appel à des autorités de certification privées et à des certificats auto-signés plutôt qu'à des autorités de certification publiques car elles permettent d'isoler les connexions autorisées et d'interdire les autres.

Configurations SSL

Une configuration SSL comprend un ensemble d'attributs de configuration que vous pouvez associer à un noeud final ou à un ensemble de noeuds finaux dans la topologie WebSphere Application Server. Elle permet de créer un objet SSLContext, élément JSSE fondamental à l'aide duquel le serveur peut obtenir les fabriques de sockets SSL. Vous pouvez gérer les attributs de configuration suivants :
  • un alias pour l'objet SSLContext,
  • une version du protocole d'établissement de liaison,
  • une référence de fichier de clés,
  • une référence de fichier de clés certifiées
  • un gestionnaire de clés,
  • un ou plusieurs gestionnaires d'accréditation
  • une sélection de niveau de sécurité d'un groupe de codes de chiffrement ou d'une liste de codes de chiffrement,
  • un choix d'alias de certificat pour les connexions client et serveur.
Pour comprendre les spécificités de chaque attribut de configuration SSL, voir Configurations SSL.
Remarque : Par défaut, WebSphere ne permet pas aux suites de chiffrement RC4 de la liste de chiffrement HIGH de sécuriser davantage le serveur. Il est possible qu'un chiffrement RC4 ait été utilisé par défaut dans des établissements de liaison SSL avant cette modification. Les chiffrements RC4 étant retirés, un chiffrement AES sera probablement utilisé à la place. Les utilisateurs peuvent constater une dégradation des performances s'ils utilisent des chiffrements AES plus sécurisés.

Sélection des configurations SSL

Dans les éditions précédentes de WebSphere Application Server, vous ne pouviez référencer une configuration SSL qu'en sélectionnant directement l'alias de configuration SSL. Chaque noeud final sécurisé était identifié par un attribut d'alias qui référence une configuration SSL valide dans un répertoire des configurations SSL. Pour modifier la configuration, vous avez dû reconfigurer un grand nombre de références d'alias au sein des différents processus. Bien que l'édition en cours prenne encore en charge la sélection directe, cette approche n'est plus recommandée.

La présente édition fournit des fonctionnalités améliorées pour la gestion des configurations SSL et plus de souplesse lorsque vous sélectionnez les configurations SSL. Vous avez le choix entre plusieurs approches :
Sélection par programme
Vous pouvez définir une configuration SSL dans l'unité d'exécution en cours avant d'établir une connexion sortante. WebSphere Application Server s'assure que la plupart des protocoles système, y compris IIOP (Internet Inter-ORB Protocol), JMS (Java Message Service), HTTP (Hyper Text Transfer Protocol) et LDAP (Lightweight Directory Access Protocol), acceptent la configuration. Reportez-vous à Programmation d'une configuration SSL sortante grâce à l'API JSSEHelper
Sélection dynamique
Vous pouvez associer dynamiquement une configuration SSL à un hôte et un port cible ou à un protocole de communications sortantes spécifique en utilisant un critère de sélection prédéfini. Lorsqu'il établit la connexion, WebSphere Application Server vérifie si l'hôte et le port cible correspondent à un critère prédéfini qui inclut la portion "domaine" de l'hôte. Vous pouvez, de plus, prédéfinir le protocole pour une sélection de configuration SSL sortante et d'alias de certificat. Pour plus d'informations, voir Sélection des connexions sortantes dynamiques des configurations SSL.

La sélection dynamique de la configuration SSL sortante n'est possible que si le serveur dispose des informations de connexion. Il lui faut en effet associer le protocole sortant ou l'hôte et le port cible appropriés lorsque la création du socket client a lieu dans com.ibm.websphere.ssl.protocol.SSLSocketFactory. Pour les connecteurs d'administration WebSphere, tels que SOAP et RMI (Remote Method Invocation), les informations de connexion sont placées sur l'unité d'exécution et disponibles pour que la sélection des connexions sortantes dynamiques ait lieu. Le processus de sélection répond en fonction des informations de connexion lorsque les propriétés SSL sont récupérées, de la même manière que ce qui est décrit à la rubrique Programmation d'une configuration SSL sortante grâce à l'API JSSEHelper.

Lorsque la connexion sortante est établie à partir d'une application écrite par le client, il est possible que certaines parties des informations de connexion ne soient pas disponibles. En effet, certaines applications utilisateur envoient des appels d'API à un protocole pour établir la connexion. L'API complète ensuite le processus en appelant l'une des méthodes createSocket() dans la fabrique com.ibm.websphere.ssl.protocol.SSLSocketFactory. Les informations de connexion nécessaires à la sélection dynamique de la configuration sortante ne sont pas toujours toutes disponibles. Il est donc possible que vous deviez ajuster le filtre de sélection afin de substituer un astérisque (*) à chaque information manquante. Par exemple, l'appel openConnection() sur un objet URL se traduit, au bout du compte, par un appel à createSocket(java.net.Socket socket, String host, int port, boolean autoClose). Les informations de connexion peuvent être générées avec l'hôte et le port fournis, mais aucun protocole n'est fourni. Dans ce cas, un caractère générique (*) doit être substitué à la partie "protocole" des informations de connexion utilisées pour la sélection dynamique.

La plupart des méthodes createSocket() prennent en paramètres un hôte ou une adresse IP et un port. Le filtre de connexion utilisé pour la sélection dynamique de la configuration sortante peut être construit avec l'hôte et le port. La méthode createSocket() par défaut ne prend pas de paramètres et ne contient donc pas les informations nécessaires pour construire le filtre de connexion, sauf si la fabrique de socket (SSLSocketFactory) a été instanciée avec ces informations. Si les informations de connexion ne sont pas disponibles, utilisez l'une des autres techniques de sélection de la configuration SSL décrites dans la présente rubrique. La sélection programmatique peut être un bon choix.

Sélection directe
Vous pouvez sélectionner une configuration SSL en utilisant un alias spécifique, comme dans les éditions antérieures. Cette méthode de sélection est conservée pour assurer la compatibilité amont car un grand nombre d'applications et de processus sont fondés sur les références d'alias.
Sélection de portée
Vous pouvez associer une configuration SSL et son alias de certificat qui se trouve dans le fichier de clés associé à cette configuration SSL, à une portée de gestion WebSphere Application Server. Cette approche est recommandée pour gérer les configurations SSL de manière centralisée. Vous pouvez gérer les noeuds finaux de manière plus efficace car ils sont situés dans une vue de topologie de la cellule. La relation d'héritage entre les portées réduit le nombre d'affectations de configuration SSL que vous devez définir.
A chaque fois que vous associez une configuration SSL à une portée de cellule, la portée du noeud dans la cellule hérite automatiquement des propriétés de la configuration. Toutefois, lorsque vous affectez une configuration SSL à un noeud, la configuration du noeud remplace celle dont le noeud a hérité de la cellule. De même, tous les serveurs d'applications d'un noeud héritent automatiquement de la configuration SSL de ce noeud à moins que ces affectations soient remplacées. Si une configuration spécifique n'est pas remplacée, la topologie est basée sur les règles d'héritage du niveau de la cellule jusqu'au niveau du noeud final pour chaque serveur d'applications.
Remarque : Si vos applications sont basées sur les configurations SSL qui étaient définies comme paramètres individuels pour chaque configuration SSL dans la topologie, mais si vos serveurs d'applications ont hérité de la configuration SSL telle que déployée depuis le niveau de cellule jusqu'au niveau de noeud final, il est possible que des erreurs de transmission surviennent parmi les serveurs (des incidents d'établissement de liaison, par exemple). Vous devez vous assurer que vos applications fonctionnent de façon cohérente avec la gestion centrale des configurations SSL.
La vue de topologie contient une arborescence entrante ou sortante. Vous pouvez effectuer des sélections de configuration SSL différentes pour chaque extrémité de la connexion SSL en se basant sur l'élément auquel le serveur se connecte en tant que connexion sortante et en tant que connexion entrante. Voir Gestion centrale des configurations SSL pour plus d'informations.
Le module d'exécution utilise un ordre de priorité pour déterminer quelle configuration SSL choisir car les configurations SSL peuvent être sélectionnées de plusieurs manières. Pour choisir votre approche de configuration, respectez l'ordre suivant :
  1. Sélection par programme. Si une application définit une configuration SSL sur l'unité d'exécution active en utilisant l'API com.ibm.websphere.ssl.JSSEHelper, la configuration SSL bénéficie de la priorité la plus élevée.
  2. Le critère de sélection dynamique pour l'hôte et le port ou le protocole de communications sortantes.
  3. La sélection directe.
  4. La sélection de la portée. L'héritage de la portée permet de s'assurer que le noeud final que vous sélectionnez est associé à une configuration SSL et que chaque portée sous-jacente en hérite, à condition que celle-ci ne remplace pas cette sélection.

Configuration des certificats chaînés par défaut

Par défaut, WebSphere Application Server crée un seul certificat chaîné pour chaque noeud. Le certificat chaîné est signé avec une racine, un certificat auto-signé stocké dans DmgrDefaultRootStore ou NodeDefaultRootStore. WebSphere Application Server n'est plus fondé sur un certificat auto-signé ou sur le certificat par défaut ou factice fourni avec le produit. Le fichier de clés par défaut key.p12 et le fichier de clés certifiées trust.p12 sont stockés dans le référentiel de configuration, dans le répertoire du noeud. Le certificat racine par défaut est stocké dans root-key.p12 dans le référentiel de configuration, sous le répertoire des noeuds.

Tous les noeuds placent leurs certificats de signataire dans ce fichier de clés certifiées commun du certificat racine par défaut (trust.p12). De plus, une fois qu'un noeud a été fédéré, la configuration SSL par défaut est automatiquement modifiée pour désigner le fichier de clés certifiées commun qui se trouve dans le répertoire de cellule. Le noeud peut communiquer avec tous les autres serveurs de la cellule.

Toutes les configurations SSL par défaut contiennent un fichier de clés doté du suffixe DefaultKeyStore, un fichier de clés certifiées doté du suffixe DefaultTrustStore et un fichier racine doté du suffixe DefaultRootStore. Ces suffixes par défaut indiquent au module d'exécution de WebSphere Application Server d'ajouter le signataire racine du certificat personnel au fichier de clés certifiées commun. Si le nom d'un fichier de clés certifiées ne se termine pas par le suffixe DefaultKeyStore, les certificats de signataire racine ne sont pas ajoutés au fichier de clés certifiées commun lorsque vous fédérez le serveur. Vous pouvez modifier la configuration SSL par défaut, mais vous devez vérifier qu'une relation de confiance correcte est établie pour les connexions administratives, entre autres.

Pour plus d'informations, voir Configuration des certificats chaînés par défaut dans SSL [AIX Solaris HP-UX Linux Windows]et[AIX Solaris HP-UX Linux Windows]Configuration par défaut du plug-in de serveur Web dans SSL.

Contrôle de l'expiration des certificats

Le contrôle des certificats permet de s'assurer que le certificat chaîné par défaut de chaque noeud n'est pas autorisé à expirer. La fonction de contrôle de l'expiration des certificats lance un avertissement avant que les certificats et les signataires soient définis pour expirer. Ces certificats et les signataires, qui sont stockés dans les fichiers de clés gérés par la configuration WebSphere Application Server, peuvent être contrôlés. Vous pouvez configurer le moniteur d'expiration pour qu'il remplace automatiquement un certificat. Un certificat chaîné sera recréé en fonction des mêmes données qui sont utilisées pour la création initiale, et signé avec le même certificat racine qui a signé le certificat d'origine. Un certificat auto-signé ou chaîné est également recréé en fonction des mêmes données qui sont utilisées pour la création d'origine.

Le moniteur peut également remplacer automatiquement les anciens signataires par ceux des nouveaux certificats chaînés ou auto-signés contenus dans les fichiers de clés gérés par WebSphere Application Server. Les échanges de signataire existants, effectués par le module d'exécution au cours de la fédération et par l'administration, sont préservés. Pour plus d'informations, voir la rubrique Contrôle de l'expiration des certificats dans SSL.

Le moniteur d'expiration est configuré pour remplacer les certificats personnels chaînés qui sont signés par un certificat racine dans DmgrDefaultRootStore ou dans NodeDefaultRootStore. Le certificat est renouvelé à l'aide du même certificat racine qui a été utilisé pour signer le certificat d'origine.

Le moniteur peut également remplacer automatiquement les anciens signataires par ceux des nouveaux certificats auto-signés contenus dans les fichiers de clés gérés par WebSphere Application Server. Les échanges de signataire existants, effectués par le module d'exécution au cours de la fédération et par l'administration, sont préservés. Pour plus d'informations, voir la rubrique Contrôle de l'expiration des certificats dans SSL.

Clients WebSphere Application Server : conditions requises pour l'échange de signataire

Un nouveau certificat chaîné est généré pour chaque au cours de son démarrage initial. Pour garantir la confiance, ces signataires racines doivent être affectés aux clients pour que ces derniers puissent établir une connexion. L'introduction de certificats chaînés dans l'édition actuelle facilite ce processus. Plutôt que d'échanger le signataire d'un certificat auto-signé à durée de vie courte, vous pouvez échanger le signataire racine à durée de vie longue, qui assurera une confiance préservée sur les renouvellements de certificats personnels. De plus, vous pouvez accéder aux certificats de signataire des différents noeuds auxquels le client doit se connecter avec l'une des options suivantes (pour plus d'informations, voir Installation sécurisée pour l'extraction des signataires client dans SSL) :
  • Une invite d'échange de signataire permet d'importer les certificats de signataire qui ne sont pas encore présents dans les fichiers de clés certifiées au cours d'une connexion à un serveur. Par défaut, cette invite est activée pour les connexions administratives et elle peut l'être pour toute configuration SSL client. Lorsque l'invite est activée, toute connexion établie avec un serveur et pour laquelle le signataire n'est pas encore défini fournit le signataire du serveur ainsi que les informations de certificat et un digest SHA (Secure Hash Algorithm) du certificat à des fins de vérification. L'utilisateur doit indiquer s'il accepte ces données. Si c'est le cas, le signataire est ajouté au fichier de clés certifiées du client jusqu'à ce qu'il soit supprimé de manière explicite. L'invite d'échange de signataire ne s'affichera plus lorsque vous vous connecterez au même serveur, à moins que le certificat personnel ait changé.
    Avertissement : Il est risqué de considérer une invite d'échange de signataire comme étant digne de confiance sans vérifier le digest SHA. Une invite non vérifiée peut provenir d'un navigateur lorsqu'un certificat n'est pas sécurisé.
  • Vous pouvez exécuter un script administratif retrieveSigners à partir d'un client avant d'établir des connexions aux serveurs. Pour télécharger des signataires, aucun droit d'administration n'est requis. Vous devez pour cela disposer du rôle Administrateur. Le script télécharge tous les signataires à partir d'un fichier de clés certifiées donné vers le fichier de clés certifiées du serveur spécifié. Il peut être appelé uniquement pour télécharger un alias spécifique à partir d'un fichier de clés certifiées spécifique. Vous pouvez également appeler le script pour télécharger les signataires vers des fichiers de clés certifiées du serveur. Lorsque vous sélectionnez le fichier de clés certifiées CellDefaultTrustStore en tant que fichier de clés certifiées du serveur spécifié et en tant que fichier de clés certifiées commun pour une cellule, tous les signataires de cette cellule sont téléchargés vers le fichier de clés certifiées spécifié du client, qui est généralement ClientDefaultTrustStore. Pour plus d'informations, voir la rubrique Commande retrieveSigners.
  • Vous pouvez distribuer physiquement aux clients le fichier de clés certifiées commun trust.p12 situé dans le répertoire de cellule du référentiel de configuration. Toutefois, au cours de cette distribution, vous devez vérifier que le mot de passe correct a été spécifié dans le fichier de configuration SSL ssl.client.props du client. Le mot de passe par défaut de ce fichier de clés certifiées est WebAS. Modifiez-le avant de procéder à la distribution. La distribution physique n'est pas aussi efficace que les options précédentes. Lorsque des modifications sont apportées aux certificats personnels sur le serveur, l'échange automatique peut échouer.

Modifications de configuration SSL dynamiques

Le module d'exécution SSL de WebSphere Application Server gère les programmes d'écoute pour la plupart des connexions SSL. Une modification de la configuration SSL peut entraîner les programmes d'écoute de connexions entrantes à créer un objet SSLContext. Les connexions existantes continuent à utiliser l'objet SSLContext en cours. Les connexions sortantes utilisent automatiquement les nouvelles propriétés de configuration lorsqu'elles sont établies.

Apportez des modifications dynamiques à la configuration SSL en dehors des heures de pointe afin de réduire les délais et empêcher le redémarrage du serveur. Si vous configurez le module d'exécution de manière à ce qu'il accepte les modifications dynamiques, modifiez la configuration SSL et sauvegardez le fichier security.xml. Vos modifications sont prises en compte lorsque le nouveau fichier security.xml atteint chaque noeud.

Remarque : Si les modifications de configuration entraînent l'échec de l'établissement de liaison SSL, des échecs de la connectivité administrative peuvent également se produire, ce qui peut entraîner des arrêts. Dans ce cas, vous devez reconfigurer les connexions SSL, puis procéder à la synchronisation manuelle des noeuds pour corriger l'erreur. L'exécution d'une modification dynamique est délicate. Il est recommandé de modifier les configurations SSL dans un environnement de test avant de les effectuer dans un système de production. Pour plus d'informations, voir la rubrique Mises à jour des configurations dynamiques dans SSL.

Gestion intégrée des certificats

La gestion des certificats, qui est comparable à la fonctionnalité iKeyMan, est maintenant intégrée aux panneaux de gestion des fichiers de clés de la console d'administration. Utilisez la fonction de gestion intégrée des certificats personnels, des demandes de certificats et des certificats de signataire qui sont stockés dans les fichiers de clés. En outre, vous pouvez gérer les fichiers de clés à distance. Il est possible, par exemple, de gérer un fichier de clés reposant sur des fichiers, qui se trouve hors du référentiel de configuration sur n'importe quel noeud du gestionnaire de déploiement. Vous pouvez également gérer les fichiers de clés de chiffrement matériel à distance, à partir du gestionnaire de déploiement.

Avec la fonction de gestion intégrée des certificats, vous pouvez remplacer un certificat auto-signé ou chaîné ainsi que tous les certificats de signataire répartis dans un grand nombre de fichiers de clés certifiées et extraire un signataire d'un port distant en vous connectant à l'hôte et au port SSL distant et en interceptant le signataire au cours de l'établissement de la liaison. Le certificat est d'abord validé en fonction du prétraitement SHA du certificat, puis l'administrateur doit accepter le certificat validé avant que celui-ci ne puisse être placé dans un fichier de clés certifiées.

Lorsque vous lancez une demande de certificat, vous pouvez l'envoyer à une autorité de certification. Lorsque le certificat est renvoyé, vous pouvez l'accepter dans la console d'administration. Pour plus d'informations, voir la rubrique Gestion des certificats dans SSL.
Conseil : Bien que la fonctionnalité iKeyMan soit encore livrée avec WebSphere Application Server, configurez les fichiers de clés à partir de la console d'administration en utilisant la fonction de gestion intégrée des certificats. iKeyMan est une option toujours disponible lorsqu'il est impossible d'utiliser la console d'administration. Pour plus d'informations, voir Gestion de certificats en utilisant iKeyman avant SSL.

Gestion de la configuration AdminTask

Les panneaux de gestion de la configuration SSL de la console d'administration sont fondés principalement sur les tâches administratives qui sont gérées et améliorées pour prendre en charge la fonction de la console d'administration. Vous pouvez utiliser les commandes wsadmin à partir de l'invite de la console Java pour automatiser la gestion des fichiers de clés, des configurations SSL, des certificats, etc.

Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_sslsecurecom
Nom du fichier : csec_sslsecurecom.html