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

6 novembre - IBM MQ version 9.0.4 CD est disponible

IBM MQ version 9.0.4 CD est disponible. Pour le télécharger sur PassportAdvantage, recherchez le (...)

18 octobre - Fixpacks tWAS 9.0.0.5

IBM annonce la disponibilité du fixpack 5 pour WebSphere Application Server traditionnal version (...)

16 octobre - Fin de support IIB version 9.0

IBM annonce ce jour que le support de IBM Integration Bus 9.0.x se terminera le 30/09/2018. Il (...)

5 octobre - Annonce de IBM MQ 9.0.0.2 LTSR

Ce produit est disponible : sous forme de fixpack classique (s’applique sur MQ 9000 ou 9001) (...)

29 septembre - IBM Integration Bus V9.0 - Fix Pack 9.0.0.9

IBM annonce ce jour la disponibilité du FixPack 9 pour IIB 9.0.

8 septembre - IBM Integration Bus V10.0 - Fix Pack 10.0.0.10

IBM annonce ce jour le Fix Pack 10.0.0.10 pour IBM Integration Bus V10.0.
Cette mise à jour (...)