Publié le 25/05/2020
Configuration, étape par étape, d’une session 5250 et de transferts de données sécurisés, en utilisant les protocoles TLS/SSL permettant de chiffrer les échanges, entre le poste client (Windows / Linux / Mac) et un environnement IBM i.
Par défaut, les sessions 5250 sont configurées sans aucun chiffrement, elles utilisent le port 23 (Telnet non sécurisé). Toutes les données et informations circulent en clair sur le réseau. Les informations sensibles, comme le mot de passe de l’utilisateur, peuvent être facilement récupérées à l’aide d’un analyseur de réseau (sniffer).
La configuration va se dérouler en sept étapes :
1 – Création d’un Certificate Store Local CA
2 – Création d’une autorité de certification dans le Certificate Store Local CA
3 – Création d’un Certificate Store System
4 – Création d’une autorité de certification dans le Certificate Store System
5 – Assignation du certificat aux services TCP/IP souhaités
6 – Redémarrage des services TCP/IP
7 – Configuration de la session
La quasi intégralité de la configuration s’effectue sur le Digital Certificate Manager, et pour cette occasion, nous allons utiliser le nouveau DCM disponible depuis la 7.4 TR1 (novembre 2019) et qui vient également d’être implémenté en 7.3 avec le TR8 (mai 2020).
Etape préalable de vérification
Pour savoir si la session est sécurisée, il suffit de regarder dans le coin en bas à droite de la fenêtre. Si le cadenas est ouvert, la session n’est pas chiffrée (utilisation du port 23). Si le cadenas est fermé, elle est sécurisée (utilisation du port 992).
En double cliquant sur la barre d’état de la session 5250 ACS, on obtient le détail sur le type de connexion. Pour le moment, la session n’est pas sécurisée, elle utilise bien le port 23.
Si l’on sélectionne l’option « Communication ==> Sécurité » des menus de la session, le message est plus clair, il indique que « La connexion n’est pas sécurisée« .
Si l’on regarde la configuration de la session en prenant le menu « Communication ==> Connexion », on constate que la session est prévue pour utiliser le port 23. Attention, il ne sert à rien de forcer le port 992 directement dans cette option, cela ne permettra pas d’obtenir une configuration sécurisée.
De la même manière, si l’on regarde la configuration des transferts de données, en cliquant sur le bouton « Propriétés » …
… on pourra constater que les transferts de données s’effectuent en mode non sécurisé car ils utilisent les paramètres par défaut de IBM i Access Client Solutions.
Le paramètre par défaut de ACS, permettant d’activer la sécurisation, se trouve dans la configuration système.
On sélectionne ensuite le système concerné (la partition) et l’on édite ses propriétés.
On constate que la valeur par défaut, l’option « Utilisation de SSL pour la connexion », n’est pas active. Cocher cette option ici, ne suffira pas à activer la sécurisation, il faut impérativement passer par les étapes de configuration via le DCM.
1 – Création d’un Certificate Store Local CA
Pour cette étape et les 4 suivantes, nous allons utiliser le nouveau Digital Certificate Manager.
Pour y accéder, il faut utiliser l’URL suivante :
http://mon_server:2001/DCM
Le serveur dirigera l’accès vers le port 2006.
http://mon_server:2006/DCM/login
Se connecter au DCM avec un profil disposant de droits d’administration du système.
Une fois connecté, voici le menu d’accueil. Les développeurs ont travaillé sur un design épuré par rapport à l’ancien DCM, par ailleurs toujours disponible (pour le moment).
Commençons par créer le Certificate Store de type Local CA. pour information, un Certificate Store est un endroit dans lequel on stocke des autorités de certification (certificats). Cliquer sur le lien « Create Certificate Store » dans le menu de gauche.
Puis choisir le type de Store « Local CA ».
Pour créer un Certificate Store, le seul paramètre requis est un mot de passe. Ce dernier permettra l’accès au Certificate Store Local CA.
Lorsque le mot de passe est saisi à deux reprises (pour la confirmation), le Certificate Store Local CA est créé.
2 – Création d’une autorité de certification dans le Certificate Store Local CA
Dans cette seconde étape, nous allons créer une autorité de certification (ou certificat) dans le Certificate Store. Pour cela, il faut commencer par cliquer sur « Create ».
On arrive alors sur une page contenant de nombreux paramètres permettant de définir l’autorité de certification.
Tous les paramètres ne sont pas obligatoires. Nous n’allons renseigner que ceux qui le sont :
- La taille de la clé (ex : RSA – 2048 bits)
- Le Hash (chiffrage) de l’algorithme utilisé (ex : SHA-256)
- La période de validité de l’autorité de certification (ex : 7300 jours, valeur maximale)
- Le nom de l’autorité de certification (ex : MonCA)
- Le nom de la société de certification (ex : MaSociete)
- Etat ou province (ex : Breizh)
- Le pays (Ex : Fr)
Une fois tous les paramètres saisis, cliquer sur le bouton « Create ».
L’autorité de certification du Certificate Store est créée.
On peut cliquer sur « View » pour vérifier les paramètres.
3 – Création d’un Certificate Store System
Nous allons désormais créer un Certificate Store System. Pour cela, il faut cliquer sur le lien « Create Certificate Store » dans le menu de gauche.
Cliquer sur *SYSTEM.
Tout comme pour le Certificate Store Local CA, indiquer un mot de passe. Ce dernier permettra l’accès au Certificate Store *SYSTEM. Le mot de passe peut, bien entendu, être différent de celui du Local CA.
Le Certificate Store *SYSTEM est créé.
On peut constater la présence d’un certificat dans le Certificat Store *SYSTEM. Cliquer sur le lien « Server/Client Certificate » pour avoir le détail.
En fait, il s’agit de l’autorité de certification créée dans le Certificate Store Local CA lors de l’étape 2. Tout certificat ou autorité de certification créé dans le Certificate Store Local CA est également visible dans le Certificate Store *SYSTEM.
On peut le vérifier, en cliquant sur « View ».
Il s’agit bien de l’autorité de certification créée en étape 2.
4 – Création d’une autorité de certification dans le Certificate Store System
Désormais, nous allons créer l’autorité de certification qui servira pour sécuriser les sessions 5250 en TLS/SSL. Les étapes 1 à 3 étaient nécessaires car les prérequis obligatoires pour l’autorité de certification n’existaient pas. S’il fallait créer une nouvelle autorité de certification ou renouveler un certificat, il suffirait de commencer à l’étape 4.
Pour créer l’autorité de certification, il faut cliquer sur « Create ».
Deux types d’autorité de certification sont proposés : Local CA et Internet CA. Choisir « Local CA ».
Un écran de création de l’autorité de certification se présente. Plusieurs paramètres sont obligatoires.
Pour la création de l’autorité de certification dans le Certificate Store *SYSTEM, nous n’allons renseigner que les paramètres obligatoires.
Par défaut, l’autorité de certification Local CA créée préalablement est proposée pour le paramètre Local CA. S’assurer que cela est bien le cas. Saisie des paramètres suivants :
- Label de l’autorité de certification (ex : MonCertificat)
- Choisir la taille de la clé (ex : RSA – 2048 bits)
- Le nom de l’autorité de certification (ex : MaSociete_Server_Certificate)
- Le nom de la société de certification (ex : MaSociete)
- Etat ou province (ex : Breizh)
- Le pays (ex : Fr)
Puis, cliquer sur « Create ».
L’autorité de certification a bien été créée.
Pour consulter les détails, cliquer sur « View ».
Détails de l’autorité de certification nouvellement créée. Une précision, le certificat à une durée de vie (validity period) par défaut d’un an (365 jours).
Il n’est pas possible de modifier la durée de péremption du certificat après sa création. Si l’on souhaite créer un certificat ayant une durée de vie différente. Il faut modifier la valeur par défaut, préalablement à la création.
Pour cela, il faut cliquer sur « Change Policy Data » dans le Certificate Store Local CA.
La valeur par défaut est de 365 jours.
Indiquer la valeur souhaitée, maximum 2000 (environ 5 ans et demi), et valider en cliquant sur « change ».
La modification est prise en compte, la durée de validité des prochains certificats créés sera égale à la valeur nouvellement paramétrée.
5 – Assignation du certificat aux services TCP/IP souhaités
Cette étape va permettre d’affecter les services TCP/IP souhaités au certificat (ou autorité de certification) que l’on vient de créer. Pour cela, cliquer sur le signe « + » en bas à droite du certificat.
Puis cliquer sur l’option « Assign ».
La liste des services disponibles s’affiche.
Il faut désormais sélectionner les services TCP/IP souhaités. Nous allons sélectionner 10 services parmi cette liste, ceux mis en bleu. Cela correspond à l’ensemble des host servers plus Telnet server :
- Central Server
- Database Server
- Data Queue Server
- Network Print Server
- Remote Command Server
- Signon Server
- IBM i TCP/IP Telnet Server
- IBM i TCP/IP Telnet Client
- IBM i DDM/DRDA Server – TCP/IP
- IBM i DDM/DRDA Client – TCP/IP
- Cluster Security
- Host Servers
- File Server
- Management Central Server
- IBM Tivoli Directory Server
- IBM Tivoli Directory Publishing
- IBM Tivoli Directory Client
- IBM i VPN Key Manager
- Entreprise Identity Mapping (EIM)
- IBM i System Service
- QFileSvr.400
- IBM i Remote Journaling Target
- IBM i Remote Journaling Source
- HTTP Server Monitor
- IBM i TCP/IP SMTP Server
- IBM i TCP/IP SMTP Client
- IBM i TCP/IP FTP Server
- IBM i TCP/IP FTP Client
- IBM i TCP/IP POP Server
- IBM Directory Server
Puis cliquer sur « Add » ou « Replace » afin d’affecter les services au certificat. Etant donné qu’il s’agit d’une première configuration, les fonctions « Add » et « Replace » auront le même comportement.
Les services ont été assignés au certificat.
On peut vérifier les détails en cliquant sur « View ».
Les services sont bien affectés au certificat.
6 – Redémarrage des services TCP/IP
L’étape suivante consiste à faire prendre en compte les modifications apportées aux services TCP/IP. Pour cela, il faut attendre le prochain IPL, ou stopper puis redémarrer les services concernés.
Telnet et les Host Servers sont les services affectés par le paramétrage que nous venons de mettre en œuvre. Attention, l’exécution des deux premières commandes va déconnecter les sessions 5250, il faut donc les exécuter depuis un environnement non concerné par ces coupures, comme la console 5250 ou FTP.
Arrêt de Telnet et des host servers
ENDTCPSVR SERVER(*TELNET)
ENDHOSTSVR SERVER(*ALL)
Démarrage de Telnet et des host servers
STRTCPSVR SERVER(*TELNET)
STRHOSTSVR SERVER(*ALL)Précision complémentaire, en ce qui concerne les sessions 5250. Le service Telnet contient un paramètre permettant d’autoriser on non l’utilisation du chiffrage des sessions.
Il s’agit du paramètre ALWSSL (Allow Secure Socket Layer). Par défaut, ce dernier est réglé à *YES. Cela signifie que l’on peut utiliser simultanément des sessions 5250 sécurisées et non sécurisées.
Il est possible de n’autoriser que les sessions 5250 sécurisées, et dans ce cas on réglera le paramètre à *ONLY.
Attention à ce paramètre, car si *ONLY est sélectionné, cela signifie que les sessions non chiffrées ne pourront plus se connecter à la partition.
Il est également possible d’interdire les sessions sécurisées et de n’autoriser que les sessions non chiffrées, mais cela est totalement déconseillé : ALLSSL(*NO).
7 – Configuration de la session
Ultime étape de configuration, la plus simple, celle qui va indiquer à la session qu’elle peut désormais utiliser le chiffrage pour sécuriser ses échanges.
Cliquer sur le lien « Configuration système » de IBM Client Access Solutions.
Sélectionner la partition IBM i concernée et cliquer sur « Edition ».
A cet instant, SSL n’est pas utilisé.
Sélectionner « Utilisation de SSL pour la connexion ».
Puis lancer la session 5250 correspondant à la partition IBM i configurée, soit dans le menu d’ACS soit en cliquant sur le lien habituel (sur le bureau par exemple).
La fenêtre de login host servers apparaît. Si cela n’est pas le cas, il faut redémarrer le poste client car les informations de connexion sont restées dans le cache, et elles contiennent une authentification non sécurisée.
Dès la connexion autorisée, deux fenêtres relatives aux certificats Local CA et *SYSTEM vont apparaitre. Bien entendu, il convient de les accepter toutes les deux.
Et voila, la session 5250 est désormais sécurisée, tous les échanges entre le poste client et la partition IBM i sont chiffrés. On peut le constater en regardant en bas à droite de la session, un cadenas fermé est présent, le port utilisé n’est plus le 23, mais le 992.
En cliquant sur la barre d’état de la session, le port 992 est bien utilisé.
On peut également vérifier en utilisant le menu « Communication ==> Configuration ».
La session, qui utilisait le port 23 avant la configuration TLS/SSL, s’est auto-configurée sur le port 992.
Si l’on regarde la configuration des transferts de données en cliquant sur le bouton « Propriétés ».
L’onglet « Connexion » indique que la configuration en cours utilise SSL ce qui n’était pas le cas avant .
Pour voir le certificat utilisé, il faut cliquer sur le menu « Communication ==> Sécurité ».
Puis, cliquer sur le bouton « Affichage du certificat de l’émetteur ».
Détails du certificat.
Le menu NETSTAT montre que les host services non chiffrés (ports 8470 à 8479) et chiffrés (ports 9470 à 9476) sont actifs, cela permet l’utilisation simultanée de sessions non sécurisées et sécurisées.
La session en cours est sécurisée, on peut le voir dans le menu NETSTAT par la présence d’une connexion depuis l’adresse TCP/IP de cette session, vers le port 992 (Telnet TLS/SSL).
