Pourquoi et quand exécuter cette tâche
L'authentification du client SSL se fait au moyen d'un certificat SSL et a lieu
lors de l'établissement de liaison SSL. Ce dernier est une série de messages
échangés sur le protocole SSL pour négocier les modalités de protection de la
connexion. Durant l'établissement de liaison, le serveur sécurisé demande que le client
lui renvoie un certificat ou une chaîne de certificats afin de s'authentifier. Pour activer SSL dans Liberty, ajoutez la fonction Liberty
ssl-1.0 au fichier du document racine de la
configuration, server.xml, avec le code des
informations du fichier de clés pour authentification.
Par défaut, le chemin d'accès et le nom de fichier du document racine de la configuration sont les suivants : chemin_d'accès_à_Liberty/wlp/usr/servers/nom_serveur/server.xml.
chemin_d'accès_à_Liberty est l'emplacement où vous avez installé Liberty sur votre système d'exploitation et
nom_serveur est le nom de votre serveur. Vous pouvez toutefois changer le chemin. Voir Personnalisation de l'environnement Liberty.
- Activez la fonction Liberty ssl-1.0 dans le
fichier server.xml.
<featureManager>
<feature>ssl-1.0</feature>
</featureManager>
Remarque : Si la sécurité d'application est requise et les informations de
sécurité redirigées vers un port sécurisé, vous devez ajoutez la
fonction
appSecurity-2.0
Liberty
au fichier server.xml.
Lorsque la fonction ssl-1.0 est activée, le serveur Liberty crée un SSLContext à partir de la configuration SSL par
défaut et convertit ce SSLContext en valeur par défaut du serveur en appelant l'API Java SSLContext.setDefault(). Cela rend le SSLContext par défaut du serveur
Liberty le SSLContext par défaut du processus. Si l'API Java SSLContext.getDefault() est appelé, la méthode renvoie
Liberty SSLContext. La
même chose s'applique à l'API Java SSLSocketFactory.getDefault() dans lequel la fabrique de sockets par défaut du SSLContext par défaut est renvoyée.
La communication SSL peut également être activée en ajoutant la fonction transportSecurity-1.0 Liberty dans le
fichier server.xml. <featureManager>
<feature>transportSecurity-1.0</feature>
</featureManager>
La fonction transportSecurity-1.0 remplace la fonction ssl-1.0 et ajoute une fonctionnalité qui n'est pas incluse dans la fonction ssl-1.0. Vous
pouvez spécifier une configuration SSL à utiliser en tant que valeur par défaut sortante ainsi que des filtres de configuration sur une configuration SSL afin que la
configuration SSL puisse être utilisée pour
un appel SSL sortant sur la base d'un port et d'un hôte cible. Pour en savoir plus sur les options SSL sortantes, voir
Configuration des paramètres SSL pour les communications sortantes et Filtres sortants pour configurations SSL.
Lorsque la fonction transportSecurity-1.0 est activée, le serveur Liberty définit une fabrique de sockets SSL
personnalisée qui utilise la propriété de sécurité Java ssl.SocketFactory.provider. Cette propriété de sécurité est définie automatiquement lorsque la fonction
transportSecurity-1.0 est activée.
Lorsque vous utilisez la fonction transportSecurity-1.0, le SSLContext par défaut du processus est le
SSLContext par défaut de Java Secure Socket Extension (JSSE). Un appel de SSLContext.getDefault() renvoie le contexte SSLContext par défaut de JSSE. Un appel de
SSLSocketFactory.getDefault() renvoie un SSLSocketFactory basé sur le fournisseur de la fabrique de sockets personnalisée du serveur
Liberty qui utilise le SSLContext de Liberty.
L'attribut outboundSSLRef et l'élément outboundConnection sont uniquement utilisés pour les connexions SSL sortantes si la fonction
transportSecurity-1.0 est spécifiée. Si la fonction ssl-1.0 est spécifiée et la fonction transportSecurity-1.0 n'est pas spécifiée,
l'attribut outboundSSLRef et l'élément outboundConnection sont ignorés.
Remarque : En raison de la nature du JDK, si vous passez de la fonction ssl-1.0 à la fonction transportSecurity-1.0 ou de la
fonction transportSecurity-1.0 à la fonction ssl-1.0, le serveur Liberty doit être redémarré pour
utiliser pleinement la fonction.
- Ajoutez l'objet de service keyStore au fichier server.xml. L'élément keyStore représente un fichier de clés portant l'identifiant defaultKeyStore et
contient le mot de passe d'accès à ce fichier de clés. Le mot de passe peut être indiqué en clair ou
sous forme codée. L'option securityUtility
encode peut être utilisée pour coder le mot de passe.
<keyStore id="defaultKeyStore" password="yourPassword" />
Exemple de fichier de clés SAF dans la configuration minimale :
<keyStore id="defaultKeyStore" location="safkeyring:///WASKeyring"
type="JCERACFKS" password="password" fileBased="false"
readOnly="true" />
Un fichier de clés RACF doit être configuré avant de pouvoir le configurer pour être utilisé par le serveur Liberty. Le
serveur ne crée par de certificats et les ajoute à RACF.
L'entrée keyStore représentant une configuration SSL minimale peut être
étendue pour inclure l'emplacement et le type du fichier de clés.
<keyStore id="defaultKeyStore" location="myKeyStore.p12" password="yourPassword" type="PKCS12"/>
Il s'agit de la configuration minimum requise pour créer une configuration SSL. Dans
cette configuration, le serveur crée le magasin de clés et le certificat s'il n'existe pas lors de l'initialisation SSL. Le mot de passe soumis doit comporter au moins six caractères. Cette configuration suppose qu'il s'agit d'un fichier de clés JKS nommé key.jks sous le répertoire home/resources/security
du serveur. Si le fichier n'existe pas, le serveur le crée pour vous. Dans ce cas, il crée également le certificat dans ce fichier. Le certificat
est autosigné avec une période de validité de 365 jours. La valeur CN de l'élément subjectDN dans le certificat est le nom d'hôte
de la machine sur laquelle le serveur s'exécute et utilise l'algorithme de signature SHA256withRSA.
Remarque : Lorsque l'utilisation d'un contrôleur de collectivité n'est pas pratique, peut-être
parce qu'il y a seulement un ou deux serveurs Liberty, un certificat auto-signé peut être utilisé pour restreindre le nombre de clients
pouvant se connecter au serveur membre Liberty. Nous vous suggérons d'utiliser un serveur IHS face aux serveurs
Liberty, où un certificat approprié signé par une autorité de certification peut être utilisé avec une liste blanche CN pour
contrôler quels clients peuvent se connecter au serveur HIS. Un canal de confiance entre le serveur IHS et le serveur membre Liberty peut
être maintenu à l'aide du certificat auto-signé.