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

Le protocole SSL (Secure Sockets Layer) assure la sécurité de la couche de transport, y compris l'authenticité, la signature des données et le chiffrement des données, afin de garantir une connexion sécurisée entre un client et un serveur qui utilise 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 JSSE (Java™ Secure Sockets Extension) comme implémentation SSL pour les connexions sécurisées. JSSE fait partie de la spécification Java 2 Standard Edition (J2SE) et est inclus dans l'implémentation IBM® de Java Runtime Extension (JRE). 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 contient 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 celui du serveur de noeud final.

Gestion des certificats X.509

Les communications sécurisées pour WebSphere Application Server requièrent des certificats X.509 signés numériquement. Le contenu d'un certificat X.509 , tel que son nom distinctif et son expiration, est soit signé par une autorité de certification (CA), soit signé par un certificat racine dans NodeDefaultRootStore ou DmgrDefaultRootStore, soit autosigné. 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.

Les certificats X.509 de l'autorité de certification, chaînés et autosignés résident dans Java keystores. JSSE fournit une référence au magasin de clés dans lequel se trouve un certificat. Vous avez le choix entre plusieurs types de magasin de clés, y compris les magasins de clés de type JCE (Java Cryptographic Extension) et de type matériel. En règle générale, chaque configuration JSSE possède deux références de magasin de clés Java: un magasin de clés et un truststore. La référence de magasin de clés représente un objet de magasin de clés Java qui contient des certificats personnels. La référence de magasin de relations de confiance représente un objet de magasin 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 magasins de clés, voir Configurations des magasins de clés pour SSL.

Echange de signataire

Lorsque vous configurez une connexion SSL, vous pouvez échanger des signataires afin d'établir une relation de confiance dans un personal certificate pour une entité spécifique. L'échange de signataire permet d'extraire le certificat X.509 du magasin de clés homologue et de l'ajouter au magasin de clés de confiance 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 signer certificate directement à partir d'un certificat autosigné, qui est le certificat X.509 avec la clé publique.

La figure 1 illustre une possible configuration de magasin de clés et de magasin de clés de confiance. 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

Dans cet exemple, le magasin de clés de confiance 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 magasin de clés de confiance de l'entité B contient 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 magasin de clés,
une référence de magasin de clés de confiance
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 caractéristiques de chaque attribut de configuration SSL, voir Configurations SSL.

Remarque: WebSphere n'autorise pas les suites de chiffrement RC4 de la liste de chiffrement HIGH à sécuriser davantage le serveur par défaut. 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 son identité d'alias. 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 sur l'unité d'exécution en cours d'exécution avant 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), Hyper Text Transfer Protocol (HTTP) et LDAP (Lightweight Directory Access Protocol), acceptent la configuration.

Sélection dynamique

Vous pouvez associer dynamiquement une configuration SSL à un hôte cible, un port ou un protocole de communications sortantes spécifique à l'aide de critères de sélection prédéfinis. Lorsqu'il établit la connexion, WebSphere Application Server vérifie si l'hôte cible et le port correspondent à un critère prédéfini qui inclut la portion de 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.

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 des communications sortantes dynamiques répond aux informations de connexion en cours de configuration lorsque les propriétés SSL sont extraites de la manière décrite dans Spécification par programmation d'une configuration SSL sortante à l'aide de 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 appelle finalement 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.

Eviter les problèmes: WebSphere Application Server s'appuie sur les informations d'hôte, de port et de protocole qui sont transmises à la fabrique de sockets SSL WebSphere Application Server . La fabrique de sockets SSL de WebSphere Application Server peut être ignorée par les paramètres de configuration settings ou par l'application, à savoir :

Le fichier java.security ne contient pas la spécification de la fabrique de sockets WebSphere Application Server.
L'application appelle directement une autre fabrique de sockets.

Dans le cas (1) ou (2), le processus dynamique de sélection des communications SSL sortantes est ignoré et la connexion n'est pas établie.

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 magasin de clés associé à cette configuration SSL, avec 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 s'appuient sur des configurations SSL qui ont été définies en tant que paramètres individuels pour chaque configuration SSL de la topologie, mais que vos serveurs d'applications ont hérité de la configuration SSL telle qu'elle a été déployée du niveau de la cellule au niveau du noeud final, il est possible que des erreurs de communication se produisent entre les serveurs (par exemple, des erreurs d'établissement de liaison). 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. Pour plus d'informations, voir Gestion centralisée des configurations SSL .

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 :

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.
Le critère de sélection dynamique pour l'hôte et le port ou le protocole de communications sortantes.
La sélection directe.
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 certificat chaîné unique pour chaque noeud. Le certificat chaîné est signé avec une racine, un certificat auto-signé stocké dans DmgrDefaultRootStore ou NodeDefaultRootStore. WebSphere Application Server ne repose plus sur un certificat autosigné ou sur le certificat par défaut ou factice fourni avec le produit. Le magasin de clés par défaut key.p12 et le magasin de clés de confiance 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.

Lorsque vous fédérez un serveur d'applications de base, il se produit le cas suivant : le magasin de clés et le magasin de clés de confiance sont inclus, et le certificat de signataire est ajouté au magasin de clés de confiance commun du gestionnaire de déploiement qui se trouve dans le répertoire de cellule du référentiel de configuration.

Tous les noeuds placent leurs certificats de signataire à partir du certificat racine par défaut dans ce magasin de clés de confiance commun (trust.p12). De plus, une fois que vous avez fédéré un noeud, la configuration SSL par défaut est automatiquement modifiée pour pointer vers le magasin de clés de confiance commun, qui se trouve dans le répertoire de la cellule. Le noeud peut communiquer avec tous les autres serveurs de la cellule.

Toutes les configurations SSL par défaut contiennent un magasin de clés doté du suffixe DefaultKeyStore, un magasin de clés de confiance doté du suffixe DefaultTrustStore et un fichier racine doté du suffixe DefaultRootStore. Ces suffixes par défaut indiquent à l'environnement d'exécution WebSphere Application Server d'ajouter le signataire racine du certificat personnel au magasin de clés de confiance commun. Si le nom d'un magasin de clés de confiance ne se termine pas par le suffixe DefaultKeyStore, les certificats de signataire racine ne sont pas ajoutés au magasin de clés de confiance 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 Default chained certificate configuration in SSL [AIX Solaris HP-UX Linux Windows] et Web server plug-in default configuration in 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 derniers, qui sont stockés dans les magasins 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 les nouveaux certificats chaînés ou autosignés dans les magasins 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 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 contrôleur peut également remplacer automatiquement les anciens signataires par ceux des nouveaux certificats auto-signés contenus dans les magasins 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 Contrôle de l'expiration des certificats dans SSL.

Important: Pour une chaîne de certificats arrivée à expiration ou une chaîne de certificats d'autorité de certification arrivée à expiration, vous devez mettre à jour la totalité de la chaîne. Vous devez générer une nouvelle chaîne de certificats qui inclut les différents certificats signataire. Pour une chaîne de certificats d'autorité de certification, cette opération peut nécessiter l'importation d'une nouvelle chaîne de certificats, généralement via un nouveau fichier de demande de certificat (CSR).

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. En outre, 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 du 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 magasins de clés de confiance 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 magasin de clés de confiance 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é.
Attention: Il n'est pas sûr de faire confiance à une invite d'échange de signataire sans vérifier le prétraitement 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 magasin de clés de confiance client donné vers le magasin de clés de confiance client du serveur spécifié. Il peut être appelé uniquement pour télécharger un alias spécifique à partir d'un magasin de clés de confiance client spécifique. Vous pouvez également appeler le script pour télécharger les signataires vers des magasins de clés de confiance du serveur. Lorsque vous sélectionnez le magasin de clés de confiance CellDefaultTrustStore en tant que magasin de clés de confiance client du serveur spécifié et en tant que magasin de clés de confiance client commun pour une cellule, tous les signataires de cette cellule sont téléchargés vers le magasin de clés de confiance client spécifié du client, qui est généralement ClientDefaultTrustStore. Pour plus d'informations, voir la commande retrieveSigners.
Vous pouvez distribuer physiquement aux clients le magasin de clés de confiance 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 prennent effet lorsque le nouveau fichier security.xml atteint chaque noeud.

Remarque: Si des changements de configuration entraînent des échecs d'établissement de liaison SSL, des échecs de connectivité administrative peuvent également se produire, ce qui peut entraîner des indisponibilités. 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.

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 magasins 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 magasins de clés. En outre, vous pouvez gérer les magasins de clés à distance. Il est possible, par exemple, de gérer un magasin 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 magasins 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 magasins de clés de confiance 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 magasin de clés de confiance.

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.

Conseil: Bien que la fonctionnalité iKeyMan soit toujours livrée avec WebSphere Application Server, configurez les keystores à partir de la console d'administration en utilisant la fonctionnalité intégrée de gestion des certificats. iKeyMan est une option toujours disponible lorsqu'il est impossible d'utiliser la console d'administration. Pour plus d'informations, voir Gestion des certificats avec 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 magasins de clés, des configurations SSL, des certificats, etc.

Vérification du nom d'hôte et de l'adresse IP

La vérification du nom d'hôte et de l'adresse IP est activée par défaut pour les communications SSL. La vérification permet de s'assurer que le nom d'hôte ou l'adresse IP figurant sur le site URL correspond au Subject Alternative Name (SAN) du certificat SSL du serveur. Si le SAN n'est pas trouvé, la propriété s'assure que le nom d'hôte dans le site URL correspond au nom commun (CN). En cas de non-concordance, la connexion SSL est rejetée.

Généralement, lors de la vérification du nom d'hôte, lorsque le nom d'hôte est utilisé dans la demande, il est comparé à l'entrée DNSName dans le SAN. Si le SAN ne contient pas d'entrée DNSName, la vérification du nom d'hôte utilise le nom commun (CN) du propriétaire du certificat. Lorsqu'une adresse IP est utilisée dans la demande, la vérification du nom d'hôte repose uniquement sur les informations relatives à l'adresse IP dans le SAN. Pour plus d'informations, voir Contenu du keystore par défaut.

Configuration des propriétés du client SSL

Les propriétés suivantes contrôlent la vérification des noms d'hôtes et des adresses IP.

La propriété com.ibm.ssl.verifyHostname permet de vérifier le nom d'hôte et l'adresse IP. Il est fixé par défaut à true.
La propriété com.ibm.ssl.skipHostnameVerificationForHosts est une liste de noms d'hôtes, d'adresses IP ou des deux, séparés par des virgules. La vérification du nom d'hôte et de l'adresse IP pour les éléments de la liste est ignorée même si la propriété com.ibm.ssl.verifyHostname est définie sur true. Par défaut, cette propriété est une chaîne vide, ce qui signifie que tous les noms d'hôtes et adresses IP sont vérifiés.

Pour plus d'informations sur la configuration de ces propriétés pour le fichier client ssl.client.props, voir ssl.client.props fichier de configuration du client.

Pour plus d'informations sur la configuration de ces propriétés dans le fichier security.xml, voir Configuration de la vérification du nom d'hôte et de l'adresse IP dans le fichier security.xml.

Rappelle-toi: L'indicateur de propriété com.ibm.ssl.performURLHostNameVerification applique la vérification du nom d'hôte uniquement lorsque l'objet javax.net.ssl.HttpsURLConnection est utilisé alors que com.ibm.ssl.verifyHostname s'applique à toutes les connexions qui utilisent des usines de sockets WebSphere.

Résolution des erreurs SSL

La vérification du nom d'hôte et de l'adresse IP est activée par défaut. Il se peut que vous rencontriez des erreurs d'échange SSL si le nom d'hôte ou l'adresse IP figurant sur le site URL et le certificat SSL ne concordent pas.

Par exemple, vous pouvez voir une erreur telle quejava.security.cert.CertificateException: No subject alternative DNS name matching MYHOST.com. Assurez-vous que le nom d'hôte ou l'adresse IP dans le site URL correspond au Subject Alternative Name (SAN) dans le certificat SSL du serveur. Si le SAN est introuvable, assurez-vous que le nom d'hôte ou l'adresse IP figurant sur le site URL correspond au nom commun (CN).

Pour plus d'informations, voir java.security.cert.CertificateException: Pas de correspondance de noms DNS alternatifs MYHOST.com.