Migration SSL pour un cluster MQ - Notes

samedi 18 octobre 2014
par Luc-Michel Demey

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.


Brèves

15 août - Annonce FixPack 11 pour IBM ACE v11.0

6 mois après la disponibilité du produit, App Connect Enterprise voit arriver son premier FixPack (...)

8 août - Annonce du FixPack 8.5.5.14 pour WAS 855

IBM annonce ce jour la disponibilité du FixPack 14 pour WAS 8.5.5.

23 juillet - IBM MQ 9.1 et IBM MQ Appliance M2002 sont disponibles

IBM MQ 9.1 est disponible au téléchargement sur l’ensemble des plates-formes supportées. (...)

28 juin - Annonce du FixPack 9.0.0.8 pour tWAS 9.0

IBM annonce ce jour la disponibilité du FixPack 8 pour WebSphere Application Server (...)

21 juin - Annonce du FixPack 8.0.0.10 pour IBM MQ v8.0

IBM annonce ce jour la disponibilité du FixPack 10 pour IBM MQ v8.0.

13 avril - Annonce du FixPack 8.0.0.9 pour WebSphere MQ v8.0

IBM annonce ce jour la disponibilité du FixPack 9 pour WebSphere MQ v8.0.