Cette section fournit une présentation générale des types de sécurité, des outils utilisés pour générer et télécharger les certificats, ainsi que les types de magasins de données installés par WebSphere Partner Gateway.
Cette section présente la couche SSL, les signatures numériques et le chiffrement.
WebSphere Partner Gateway peut utiliser la couche SSL pour sécuriser les documents entrants et sortants. Un document entrant est celui envoyé au concentrateur. Un document sortant est celui envoyé à partir du concentrateur.
SSL est un protocole couramment utilisé pour la gestion de la sécurité sur Internet. La couche SSL sécurise les connexions en permettant à deux applications reliées par une liaison réseau de s'identifier l'une l'autre et en assurant la confidentialité et l'intégrité des données.
Une connexion SSL HTTP est toujours lancée par le client avec une URL commençant par https:// au lieu de http://. Une connexion SSL commence par une négociation. Durant cette étape, les applications échangent des certificats numériques, se mettent d'accord sur les algorithmes de chiffrement à utiliser et génèrent des clés de chiffrement pour le reste de la session.
Le protocole SSL fournit les dispositifs de sécurité suivants :
La signature numérique est la méthode pour assurer l'irréfutabilité. Cela signifie qu'un participant ne peut pas nier être à l'origine d'un message et l'avoir envoyé. Cela assure également que le participant ne peut pas nier avoir reçu un message.
Une signature numérique permet à l'expéditeur de signer un message afin de pouvoir vérifier qu'il est bien à l'origine de l'envoi. Elle permet également de s'assurer que le message n'a pas été modifié depuis qu'il a été signé.
WebSphere Partner Gateway prend en charge les formats de signature numérique PKCS#7 SignedData, selon les protocoles métier.
WebSphere Partner Gateway utilise un système de chiffrement à clé publique pour sécuriser les communications entre les participants et le concentrateur. Le chiffrement à clé publique utilise une paire de clés mathématiquement liées. Un document chiffré avec la première clé ne peut être déchiffré qu'avec la seconde, et réciproquement.
Chaque participant d'un système de clé publique dispose d'une paire de clés. L'une des clés est maintenue secrète, il s'agit de la clé privée. clé privée. L'autre clé est distribuée à quiconque la demande, il s'agit de la clé publique. WebSphere Partner Gateway utilise une clé publique de participant pour chiffrer un document. La clé privée est utilisée pour le déchiffrer.
Comme décrit dans les sections suivantes, l'outil IBM de gestion des clés (iKeyman) est utilisé pour créer des bases de données de clés, des paires de clés publiques et privées et des demandes de certificats. Vous pouvez également utiliser iKeyman pour créer des certificats auto-signés. L'utilitaire iKeyman se trouve dans le répertoire /<ProductDir>/was/bin, créé par WebSphere Partner Gateway au cours de l'installation.
Vous pouvez également utiliser iKeyman pour générer une demande de certificat auprès d'une autorité de certification.
Vous utiliserez la Console de communauté pour installer tous les certificats client, de signature et de chiffrement pour le stockage de WebSphere Partner Gateway. Vous pouvez également utiliser la Console de communauté pour installer les certificats racine et intermédiaires d'autorité de certification.
Lors de l'installation de WebSphere Partner Gateway, un magasin de clés et un magasin de relations de confiance sont également installés pour le Réceptionnaire et la Console.
Par défaut, les deux magasins de clés et les deux magasins de relations de confiance sont créés dans le répertoire <ProductDir>/common/security/keystore, sous les noms suivants :
Le mot de passe par défaut permettant d'accéder aux quatre magasins est WebAS. L'application WebSphere Application Server est configurée pour utiliser ces quatre magasins. Vous pouvez utiliser l'utilitaire iKeyman pour changer le mot de passe. Vous pouvez aussi utiliser la commande Unix suivante pour modifier le mot de passe du fichier de magasin de clés :
/<ProductDir>/console/was/java/bin/keytool -storepasswd -new $NEW_PASSWORD$ -keystore $KEYSTORE_LOCATION$ -storepass $CURRENT_PASSWORD$ -storetype JKS
Si les mots de passe des magasins de clés sont changés, la configuration de chaque instance de WebSphere Application Server doit l'être également. Pour cela, vous pouvez utiliser le script bcgChgPassword.jacl. Pour l'instance de console, naviguez jusqu'au répertoire suivant :
/<ProductDir>/bin
et exécutez la commande suivante :
./bcgwsadmin.sh -f /<ProductDir>/scripts/
bcgChgPassword.jacl -conntype NONE
Répétez cette commande pour les instances de WebSphere Application Server du Réceptionnaire et du Gestionnaire de documents.
Vous êtes alors invité à saisir le nouveau mot de passe.
Si un certificat du magasin de relations de confiance arrive à expiration, vous devez le remplacer par un nouveau certificat de la façon suivante :
Ce type de données doit correspondre au type de données du certificat importé.
Une hiérarchie de certificats se compose des certificats d'un participant et de tout certificat utilisé pour les authentifier. Par exemple, si un CA a été utilisé pour créer le certificat du participant, ce CA peut avoir lui-même avoir été certifié par un autre CA. La hiérarchie des relations de confiance commence au CA racine (l'ancrage des relations de confiance). Le certificat numérique du CA racine est auto-signé, c'est-à-dire qu'il utilise sa propre clé privée pour signer le certificat numérique. Tous les certificats entre l'ancrage des relations de confiance et le certificat du participant (le certificat cible) sont des certificats intermédiaires.
Pour tout certificat émis par le CA, il faut ajouter tous les certificats de la hiérarchie. Par exemple, pour une chaîne de certificats dans laquelle A (l'ancrage des relations de confiance) est l'émetteur de B, et B l'émetteur de C (le certificat cible), les trois certificats doivent être téléchargés en tant que certificats CA.
WebSphere Partner Gateway traite tous les certificats auto-signés en tant qu'ancrages de relations de confiance. Le certificat auto-signé peut être du type CA ou généré par le participant.
Vous pouvez créer plusieurs certificats d'un type donné, et en désigner un en tant que certificat principal et l'autre en tant que certificat secondaire. Si le certificat principal expire ou est inutilisable, WebSphere Partner Gateway bascule sur le certificat secondaire. La Console de communauté sert à préciser celui qui est principal et celui qui est secondaire.
Il est possible de définir des certificats principaux et secondaires pour les certificats suivants :
Prenez note des limitations importantes formulées ci-dessous, concernant l'utilisation de certificats de chiffrement. L'environnement Java Runtime Environment (JRE) fourni avec WebSphere Partner Gateway impose des restrictions concernant les algorithmes cryptographiques et les longueurs de chiffrement maximales autorisés. Par exemple, les règles imposent des limites de longueur qui ont des répercussions sur les performances des clés de chiffrement. Ces limitations sont spécifiées dans les fichiers nommés fichiers de règle de juridiction. La longueur maximum possible est de 2048 octets. Si vous souhaitez prendre en charge des certificats avec une taille de clé supérieure à 2048 octets, utilisez la version non limitée des fichiers de règle de juridiction. Vous pouvez préciser que vous souhaitez appliquer une règle non limitée plus efficace, en installant de nouveaux fichiers de règle dans un sous-répertoire de l'environnement JRE installé. Il existe également des restrictions sur les algorithmes de chiffrement symétriques, tels que DES3. S'il vous faut un algorithme fort à clé symétrique, le fait de remplacer les fichiers de règle de juridiction lèvera également les restrictions concernant les clés symétriques.
Pour installer des fichiers de règle de juridiction dans WebSphere Partner Gateway, procédez comme suit :
Ces étapes s'appliquent à toutes les instances configurées de WebSphere Application Server.