Activation de la communication SSL dans Liberty

Pour activer la communication SSL dans Liberty, un ensemble d'options de configuration SSL minimum est disponible. Il est supposé que la plupart des options SSL nécessitent des informations de configuration du magasin de clés.

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.

Procédure

  1. 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.

  2. [17.0.0.3 and later]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.
  3. 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é.

Icône indiquant le type de rubrique Rubrique Tâche

Nom du fichier : twlp_sec_ssl.html