Migration SSL pour un cluster MQ – Notes
La protection des canaux MQ via le chiffrement SSL est quelque chose que l’on retrouve de plus en plus souvent dans les installations WebSphere MQ. Cela permet à la fois d’authentifier les partenaires, de chiffrer les messages lors de leur passage dans les canaux, et de filtrer les connexions entrantes en se basant sur le contenu du certificat.
Les configurations utilisant les fonctions de cluster MQ (Full repository, Partial repository, …) sont moins courantes, souvent réservées à des environnements où la disponibilité des applications est primordiale.
La mise en place du chiffrement des canaux clusters est une opération assez technique, surtout en terme de planification, en particulier si les membres du cluster MQ utilisent des certificats signés par différentes CA.
Il faut dans ce cas que l’ensemble des CA signataires soient présentent dans les magasins de certificats de tous les membres du cluster.
Le filtrage des QM pouvant communiquer avec le cluster peut être effectué via le paramètre SSLPEER des canaux.
Jusqu’en version 7.0, ce paramètre SSLPEER n’admet qu’une seule valeur, il faut donc trouver un « point commun » entre les certificats des différents membres du cluster, point commun que l’on ne retrouve pas dans les certificats des QM non autorisés. A moins d’avoir la main sur la valeur des champs du DN dans les certificats, c’est très compliqué.
A partir de MQ 7.1, le filtrage CHLAUTH permet d’empiler autant de SSLPEER que nécessaire pour ce filtrage, ce qui simplifie beaucoup la configuration.
Il existe plusieurs solutions pour passer en SSL un cluster existant.
La première méthode consiste à définir des nouveaux canaux cluster (nommés par exemple TS.xxx au lieu de TO.xxx), canaux qui préciseront un cipher à utiliser.
Cette méthode est adaptée aux configurations dont la période de migration va être significative (quelques semaines à quelques mois).
Pour les configurations qui vont basculer en SSL sur période courte (bascule simultanée des noeuds ou répartie sur quelques jours), il existe une approche beaucoup plus simple.
Après avoir installé les magasins de certificats sur les QM membres du cluster, il suffit de renseigner le paramètre SSLCIPHER sur les canaux cluster receiver explicites.
Cette modification va se propager vers les canaux cluster sender définis dynamiquement, et au prochain redémarrage des canaux les deux cotés seront en SSL.
L’approche est la même pour les senders définis explicitement entre les Partial et les Full repositories : La modification du canal receiver coté Full va être propagée sur le partial, et modifier dynamiquement la définition du sender explicite.
Là aussi, au prochain redémarrage des canaux, les deux cotés seront en SSL.
Et pour éviter la dernière faille découverte cette semaine dans le design du protocole SSL (faille POODLE), il faudra bien sûr choisir un cipher de type TLS. Ces ciphers ont un nom commençant par TLS ou ECDHE. L’autre intérêt des certificats de type TLS est qu’il permettent d’utiliser la fonction « multi-certificat », disponible avec MQ V8.
