Création et installation de certificats SSL
Les sections suivantes expliquent
comment créer et installer des certificats SSL à utiliser avec WebSphere
Partner Gateway. Elles donnent également
une vue générale du processus de négociation SSL. Si votre communauté n'utilise
pas la couche SSL, ni vous, ni vos participants n'avez besoin de certificat SSL
pour les communications entrantes ou sortantes.
Négociation SSL
Chaque session SSL commence par une négociation.
Lorsqu'un client (le participant ou le Gestionnaire de communauté) initie un échange
de message, le processus est le suivant :
-
Le client envoie un message de salutation "hello" avec ses capacités cryptographiques
(triées en fonction de ses préférences), telles que la version de la
couche SSL ainsi que les algorithmes de cryptographie et les méthodes de compression de
données qu'il prend en charge. Le message contient également un nombre aléatoire sur 28
octets.
- Le serveur répond par un message "hello done" indiquant la méthode
cryptographique (l'algorithme) et la méthode de compression des données qu'il
choisit, un ID de session et un autre nombre aléatoire.
Remarque : La négociation échoue si le client et le serveur n'ont aucun
algorithme de cryptographie en commun. Le serveur choisit généralement
l'algorithme commun le plus fort.
- Le serveur envoie son certificat numérique.
L'authentification du serveur se produit à cette étape.
-
Le serveur envoie un message de demande de certificat numérique.
Dans ce message ("digital certificate request"), il envoie une liste des types de certificats pris en charge et
des noms distinctifs des autorités des certifications possibles.
- Le serveur envoie un message de fin de salutation "hello done" et attend la
réponse du client.
- Dès réception du message de fin de salutation, le client vérifie la validité du certificat
numérique du serveur et contrôle que les paramètres de salutation du serveur sont acceptables.
-
Si le serveur a demandé un certificat numérique au client, celui-ci en envoie un,
ou si aucun certificat numérique ne convient, il envoie une alerte d'absence de
certificat numérique. Cette alerte constitue un simple avertissement, mais le serveur peut faire échouer
la session si l'authentification du client est obligatoire.
- Le client envoie un message d'échange de clé client. Il contient le secret
premaster, un nombre aléatoire sur 46 octets, utilisé lors de la génération de
clés de chiffrement symétrique et de clés MAC (code d'authentification de
message), le tout chiffré avec la clé publique du serveur.
-
Si le client a envoyé un certificat numérique au serveur, il envoie
également un message de vérification de certificat numérique, signé avec sa clé
privée. En contrôlant la signature de ce message, le serveur peut vérifier
la propriété du certificat numérique du client.
Remarque : Aucune procédure supplémentaire de vérification du certificat numérique
n'est nécessaire. Si le serveur ne dispose pas de la clé privée du certificat numérique,
il ne peut pas déchiffrer le secret premaster et créer les clés adaptées à l'algorithme
de chiffrement symétrique, et la négociation échoue.
-
Le client réalise une série d'opérations cryptographiques pour convertir le secret premaster
en secret master, à partir duquel sont obtenues toutes les données de clé nécessaires
au chiffrement et à l'authentification du message. Ensuite, le client envoie un message
"change cipher spec" (modification de l'algorithme de cryptographie) pour faire
basculer le serveur sur l'algorithme nouvellement négocié. Le message suivant envoyé
par le client (le message "finished") est le premier message chiffré à l'aide de
cet algorithme et de ces clés de chiffrement.
- Le serveur répond par les messages "change cipher spec" et "finished".
L'authentification du client requiert les étapes
4,
7 et
9.
La négociation SSL est terminée et les données d'application chiffrées peuvent être envoyées.
Certificats SSL entrants
Cette section explique comment configurer l'authentification
du serveur et du client pour les demandes de connexion entrantes émises par les participants.
Authentification serveur
WebSphere Application Server utilise le certificat SSL
lorsqu'il reçoit des demandes de connexion de participants via SSL.
Il s'agit du certificat que le réceptionnaire présente pour identifier le
concentrateur auprès du participant. Ce certificat serveur peut être auto-signé
ou signé par une autorité de certification. Dans la plupart des cas, vous
utilisez un certificat d'une autorité de certification pour augmenter la
sécurité. Vous pouvez utiliser un certificat auto-signé dans un environnement
de test. Utilisez iKeyman pour générer un certificat et une paire de clés. Pour plus d'informations sur l'utilisation d'iKeyman, reportez-vous à la
documentation disponible auprès d'IBM.
Une fois le certificat et la paire de clés générés, utilisez le certificat
pour le trafic SSL entrant de tous les participants. Si vous disposez de
plusieurs réceptionnaires ou consoles, copiez le magasin de clés résultant sur
chaque instance.
Si le certificat est auto-signé, fournissez-le aux participants. Pour
obtenir ce certificat, utilisez l'utilitaire iKeyman afin d'extraire le
certificat public dans un fichier.
Utilisation d'un certificat auto-signé
Si vous avez l'intention d'utiliser des certificats de serveur auto-signés,
utilisez la procédure ci-dessous.
-
Démarrez l'utilitaire iKeyman qui se trouve dans le répertoire
/<ProductDir>/was/bin.
Si c'est la première fois que vous utilisez iKeyman, supprimez le certificat
"fictif" (dummy) se trouvant dans le magasin de clés.
- Utilisez iKeyman pour générer un certificat auto-signé et une paire
de clés pour le magasin de clés du réceptionnaire ou de la console.
- Utilisez iKeyman pour extraire dans un fichier le certificat qui contiendra
votre clé publique.
Enregistrez le magasin de clés dans un fichier JKS, PKCS12 ou JCEK.
- Installez le fichier dans le magasin de clés du réceptionnaire ou de
la console pour lequel il a été créé.
-
Distribuez le certificat à vos participants.
La méthode de distribution
préférée consiste à envoyer le certificat par courrier électronique dans un
fichier compressé protégé par mot de passe. Vos participants doivent vous
appeler et vous demander le mot de passe correspondant au fichier compressé.
Utilisation d'un certificat généré par une autorité de certification (CA)
Si vous envisagez d'utiliser un certificat signé par une autorité de
certification, suivez la procédure ci-dessous.
-
Démarrez l'utilitaire iKeyman, qui se trouve dans le répertoire
/<ProductDir>/was/bin.
- Utilisez iKeyman pour générer une demande de certificat et une paire de
clés pour le réceptionnaire.
- Envoyez une demande de signature de certificat (CSR, Certificate Signing
Request) à une autorité de certification.
- Lorsque vous recevez le certificat signé de l'autorité de certification,
utilisez iKeyman pour le placer dans le magasin de clés.
-
Distribuez le certificat de l'autorité de certification à tous les participants.
Authentification client
Si vous souhaitez authentifier les participants qui envoient
des documents, procédez comme suit.
Installation du certificat du client
Pour l'authentification client, utilisez la procédure ci-dessous.
- Procurez-vous un certificat pour votre participant.
- Installez le ou les certificats dans le magasin de clés de relations de confiance à l'aide de iKeyman.
- Placez la ou les CA associées dans le magasin de clé correspondant.
Remarque : Si vous ajoutez plusieurs participants à la communauté de
votre concentrateur, vous pouvez utiliser iKeyman pour ajouter leurs
certificats au magasin de relations de confiance.
Si un participant quitte la communauté, vous pouvez utiliser iKeyman pour
supprimer ses certificats du magasin de relations de confiance.
Configuration de l'authentification du client
Une fois le ou les certificats installés, configurez WebSphere Application Server
afin d'utiliser l'authentification client en exécutant le script utilitaire bcgClientAuth.jacl.
- Passez dans le répertoire : /<ProductDir>/bin
- Pour activer l'authentification client, appelez le script comme suit :
./bcgwsadmin.sh -f /<ProductDir>/scripts/bcgClientAuth.jacl
-conntype NONE set
Remarque : Pour désactiver l'authentification client, appelez le script comme
suit :
./bcgwsadmin.sh -f /<ProductDir>/receiver/scripts/bcgClientAuth.jacl
-conntype NONE clear
Vous devez redémarrez le serveur bcgreceiver pour que ces modifications prennent effet.
Validation du certificat du client
Une fonction supplémentaire peut être utilisée avec l'authentification client
SSL. Elle est activée via la Console de communauté.
Pour HTTPS, WebSphere Partner Gateway vérifie
les certificats par rapport aux ID Métier contenus dans les documents entrants. Pour pouvoir
utiliser cette fonction, créez le profil du participant, importez le certificat
client et marquez-le comme SSL.
- Importez le certificat du client.
- Cliquez sur Administrateur du compte > Profils >
Participant de communauté et recherchez le profil du participant.
- Cliquez sur Certificats.
- Cliquez sur Charger le certificat.
- Sélectionnez Client SSL comme type de certificat.
- Tapez une description du certificat (obligatoire).
- Faites passer l'état sur Activé.
- Cliquez sur Parcourir et accédez au répertoire dans lequel vous avez enregistré le certificat.
- Sélectionnez le certificat, puis cliquez sur Ouvrir.
- Si vous souhaitez sélectionner un autre type de passerelle que
Production (valeur par défaut), faites-le.
- Cliquez sur Télécharger, puis sur Sauvegarder.
- Mettez à jour la passerelle du client.
- Cliquez sur Administrateur du compte > Profils >
Participant de communauté et recherchez le profil du participant.
- Cliquez sur Passerelles.
- Sélectionnez la passerelle HTTPS précédemment créée. Si vous n'avez pas encore créé la passerelle
HTTPS, consultez la section Configuration d'une passerelle HTTPS.
- Cliquez sur l'icône Edition pour modifier la passerelle.
- Sélectionnez Oui pour Valider le certificat client SSL.
- Cliquez sur Enregistrer.
Certificat SSL pour les communications sortantes
Si votre communauté n'utilise pas la couche SSL, vous n'avez pas
besoin de certificat SSL pour les communications entrantes ou sortantes.
Authentification serveur
Si la couche SSL est utilisée pour envoyer des documents sortants à
vos participants, WebSphere Partner Gateway leur demande un certificat
côté serveur. Le même certificat de CA peut être utilisé pour
plusieurs participants. Le certificat doit être au format X.509 DER.
Remarque : Vous
pouvez convertir le format avec l'utilitaire iKeyman. Procédez comme suit :
- Démarrez l'utilitaire iKeyman.
- Créez un magasin de clés (vide) ou ouvrez-en un.
- Dans Contenu de la base de données de clés, sélectionnez
Certificats du signataire.
- Ajoutez le certificat ARM par l'option Ajouter.
- Exportez ce certificat comme donnée Binary DER, par l'option data
Extraction.
- Fermez iKeyman.
Installez le certificat auto-signé du participant dans le profil
Opérateur du concentrateur. Si le certificat
a été signé par une CA et si le certificat de CA racine
et tout autre certificat de la hiérarchie des certificats ne sont pas encore
installés dans le profil Opérateur du concentrateur, procédez à leur
installation.
- Cliquez sur Certificats.
- Cliquez sur Charger les certificats.
- Sélectionnez Racine et intermédiaire comme type de certificat.
- Tapez une description du certificat (obligatoire).
- Faites passer l'état sur Activé.
- Cliquez sur Parcourir et accédez au répertoire dans lequel vous avez enregistré le certificat.
- Sélectionnez le certificat, puis cliquez sur Ouvrir.
- Cliquez sur Télécharger, puis sur Sauvegarder.
Remarque : Il est inutile d'effectuer les étapes précédentes si le certificat
de CA est déjà installé.
Authentification client
Si une authentification SSL client est requise, le participant
demande, en retour, un certificat au concentrateur. Utilisez la Console de communauté
pour importer votre certificat dans WebSphere Partner Gateway.
Vous pouvez générer
le certificat à l'aide de iKeyman. Si le certificat est auto-signé, il doit
être fourni au participant.
S'il s'agit d'un certificat signé par une autorité
de certification, il doit être envoyé aux participants, de
sorte qu'ils puissent l'ajouter à leurs certificats dignes de confiance.
Vous pouvez attribuer plusieurs certificats. L'un est le certificat principal,
utilisé par défaut. L'autre est le certificat secondaire, utilisé si
le certificat principal expire ou n'est pas utilisable.
Utilisation d'un certificat auto-signé
Si vous envisagez d'utiliser un certificat auto-signé, appliquez la procédure suivante.
- Démarrez l'utilitaire iKeyman.
- Utilisez iKeyman pour générer un certificat auto-signé et une paire de clés.
- Utilisez iKeyman pour extraire dans un fichier le certificat qui contiendra
votre clé publique.
- Distribuez le certificat à vos participants. La méthode de distribution
préférée consiste à envoyer le certificat par courrier électronique dans un
fichier compressé protégé par mot de passe. Vos participants doivent vous
appeler et vous demander le mot de passe correspondant au fichier compressé.
- Utilisez iKeyman pour exporter le certificat auto-signé et la paire
de clés privées sous forme de fichier PKCS12.
- Installez le certificat auto-signé et la clé via la Console de
communauté.
- Cliquez sur Administrateur du compte
> Profils > Certificats pour afficher la liste des certificats.
Veillez à vous connecter à la Console de communauté en tant qu'opérateur du concentrateur.
- Cliquez sur Charger PKCS12.
Remarque : Le fichier PKCS12 envoyé ne doit contenir qu'une seule clé
privée et le certificat associé.
- Sélectionnez Client SSL comme type de certificat.
- Tapez une description du certificat (obligatoire).
- Faites passer l'état sur Activé.
- Cliquez sur Parcourir et accédez au répertoire dans lequel vous avez enregistré le certificat.
- Sélectionnez le certificat, puis cliquez sur Ouvrir.
- Entrez le mot de passe.
- Si vous souhaitez sélectionner un autre type de passerelle que
Production (valeur par défaut), faites-le.
- Si vous avez deux certificats SSL, indiquez s'il s'agit du certificat principal ou
secondaire en sélectionnant Principal ou Secondaire
dans la liste Utilisation du certificat.
- Cliquez sur Télécharger, puis sur Sauvegarder.
Si vous envoyez les certificats principaux et secondaires pour
l'authentification SSL du client et la signature numérique, et que vous envoyez
les certificats principaux dans deux entrées séparées, assurez-vous que les
certificats secondaires correspondants sont également envoyés comme des entrées
séparées.
Utilisation d'un certificat signé par une autorité de certification (CA)
Si vous envisagez d'utiliser un certificat signé par une autorité de
certification, suivez la procédure ci-dessous.
- Utilisez iKeyman pour générer une demande de certificat et une paire de
clés pour le réceptionnaire.
- Envoyez une demande de signature de certificat (CSR, Certificate Signing
Request) à une autorité de certification.
- Lorsque vous recevez le certificat signé de l'autorité de certification,
utilisez iKeyman pour le placer dans le magasin de clés.
- Distribuez le certificat de signature de l'autorité de certification à tous
les participants.
Ajout d'un liste de retrait de certificat (CRL)
WebSphere
Partner Gateway inclut une fonction de liste de retrait
de certificats.
La liste de retrait de certificats, émise par une autorité de
certification, identifie les participants qui ont révoqué des certificats
avant leur date d'expiration prévue. Les participants ayant des certificats
révoqués se voient refuser l'accès à WebSphere Partner Gateway.
Chaque certificat révoqué est identifié par son numéro de série dans la
liste de retrait de certificats. Le Gestionnaire de documents analyse cette liste toutes les 60 secondes et
refuse un certificat s'il est mentionné dans la liste.
Les listes de retrait de certificats sont à l'emplacement suivant :
/<répertoire de données partagées>/security/crl. WebSphere Partner
Gateway utilise le paramètre bcg.CRLDir dans le fichier bcg.properties pour déterminer l'emplacement du répertoire CRL.
Créez un fichier .crl contenant les certificats révoqués et placez-le dans le répertoire
de la liste de retrait de certificats.
Par exemple, dans le fichier bcg.properties, utilisez le paramètre suivant :
bcg.CRLDir=/<répertoire de données partagées>/security/crl
Activation
de l'accès aux points de distribution des CRL
Les CA se chargent de maintenir et mettre à jour les CRL. Ces
listes de retrait de certificats sont en général conservées dans un point de
distribution de CRL. Les CRL servent à vérifier si un certificat est retiré.
Le script bcgSetCRLDP.jacl peut servir pour activer et désactiver la
vérification du point de distribution de CRL lors de la vérification des
certificats retirés.
S'il vous faut accéder aux points de distribution de CRL lors de cette
vérification, activez leur utilisation. Si les certificats que vous avez
installés contiennent une extension CRL DP, vous pouvez activer l'utilisation
des points de distribution de CRL, afin qu'ils soient accessibles pour la
vérification des certificats retirés. Si vous avez téléchargé toutes les CRL
requises dans le répertoire défini par la
propriété bcg.CRLDir de bcg.properties, vous pouvez envisager de désactiver
l'utilisation des
points de distribution de CRL. Si les CRL courantes risquent de ne pas être
disponibles dans le répertoire bcg.CRLDir, vous avez intérêt à activer
l'utilisation des points de distribution de CRL.
Les points de distribution de CRL accessibles par HTTP et LDAP sont pris en
charge. Vous pouvez également configurer des serveurs proxy pour l'accès à ces points.
Remarque : Pour Windows, utilisez
bcgwsadmin.bat au lieu de
./bcgwsadmin.sh dans les commandes indiquées dans cette section.
Pour activer l'utilisation des points de distribution de CRL, lancez la
commande suivante depuis le répertoire <ProductDir>/bin :
./bcgwsadmin.sh -f <ProductDir>/scripts/bcgSetCRLDP.jacl install
<nomdenoeud> <NomDeServeur> CRLDP
où :
- <server_root>
- Est le répertoire racine du serveur
(par exemple /opt/ibm/receiver/was/profiles/bcgreceiver)
- <NomDeServeur>
- Peut être bcgdocmgr, bcgreceiver ou
bcgconsole. La commande doit être lancée depuis le
<server_root> correspondant.
Pour désactiver l'utilisation des points de distribution de CRL, lancez la
commande suivante depuis le répertoire <ProductDir>/bin :
./bcgwsadmin.sh -f <ProductDir>/scripts/bcgSetCRLDP.jacl uninstall
<nomdenoeud> <NomDeServeur> CRLDP
Pour activer l'utilisation des points de distribution de CRL, avec un
serveur proxy, lancez la commande suivante depuis le répertoire <ProductDir>/bin :
./bcgwsadmin.sh -f <ProductDir>/scripts/bcgSetCRLDP.jacl install
<nomdenoeud> <NomDeServeur> CRLDP
<hôteProxy> <portProxy>
Pour indiquer que vous ne voulez pas utiliser de serveur proxy, lancez la
commande suivante depuis le répertoire <ProductDir>/bin :
./bcgwsadmin.sh -f <ProductDir>/scripts/bcgSetCRLDP.jacl
uninstall <nomdenoeud> <NomDeServeur> PROXY
Si vous avez un exit utilisateur de Réceptionnaire, et qu'il utilise l'API
SecurityService, les paramètres ci-dessus s'appliquent également au serveur bcgreceiver. Pour
lancer les commandes ci-dessus depuis le Réceptionnaire, remplacez
bcgdocmgr par bcgreceiver.
