Étiquette : certificates

Photo-2014-06-10-11-05-42_5420

Remplacer les certificats SSL autosignés d’un XtremIO

Posted on by Cédric

self-signed-sslNous continuons notre préparation de mise en production de nos bricks XtremIO. Afin d’être conformes à notre politique de sécurité interne, nous essayons, dans la mesure du possible d’intégrer systématiquement des certificats SSL valides vis à vis de notre PKI Institutionnelle à chaque nouvelle application ou équipement. Les interfaces d’administration de nos différents composants de stockage ne dérogent pas à la règle et il a donc fallu s’atteler à intégrer des certificats corrects sur les consoles d’admin des XtremIO.

La chose n’est pas forcément facile, dans le sens ou la documentation fournie est plus que succincte à ce sujet. Donc après une petite demi-heure de tests et tâtonnements divers, nous sommes finalement arrivés à nos fins. Voici donc la procédure pour pouvoir installer un nouveau jeu de certificats à une console XtremIO. Je ne détaillerai pas ici la procédure permettant de générer un certificat depuis votre autorité de certification, ceci dépendant plus que largement de la solution que vous avez choisi au sein de votre organisation (et accessoirement, complètement hors-sujet ;) ).

Lire la suite …

0
Image 007

Au sujet des certificats internes des tunnels VPN des clusters VPlex

Posted on by Cédric

Vous le savez sans doute si vous utilisez des VPlex en production, ceux-ci sont reliées en FC, évidemment, mais également en IP via des tunnels VPN dédiés (tout comme le serveur Witness éventuel). Ces tunnels utilisent des couples clef privée/certificats, générés à l’installation et intégrés à la configuration. Ce que je ne savais pas c’est que ces certificats sont valables 2 ans et que leur renouvellement est nécessaire à la bonne communication entre clusters, évidemment.

Rassurez-vous, tout cela remonte chez EMC via eSRS, mais pour le coup, cela nous a causé une petite frayeur récemment, car les machines ne se voyaient plus, soudainement et sans préavis. Pour autant, toute la partie FC continue sans broncher évidemment. EMC est donc intervenu pour les renouveler… pour 2 ans ;)

D’autre part, si vous avez opté pour des certificats auto-signés pour la partie SSL (interface d’admin), le certificat associé est lui valable 5 ans, ce qui laisse plus de marge de manœuvre :)

Je profite enfin de cette petite niouze pour vous indiquer que nous avons planifié la migration de notre plate-forme de production vers GeoSynchrony 5.2 pour la fin Février. Je vous ferais un retour de cette mise à jour avec les détails fonctionnels et ergonomiques associés via un billet spécifique.

Bonne continuation à tous !

0
Image 007

Importer des certificats au format .pem dans vCloud Director (MAJ)

Posted on by Cédric

vCloud Director étant développé en Java, il utilise assez logiquement les conteneurs “jks” pour stocker et exploiter ses certificats SSL et clefs privées associées. Malheureusement, l’outil de base fourni dans le framework JRE, Keytool, n’est pas le plus souple en matière d’importation/exportation.

Pour autant, on ne va pas se laisser faire. Voici donc une procédure relativement simple pour pouvoir importer des certificats et clefs privées au format standardisé “.PEM” issu, par exemple d’une PKI gérée via OpenSSL.

Le pré-requis est de disposer des deux certificats (fournis par votre PKI) et clefs privées nécessaire à VCD, à savoir celui du service http et celui du console-proxy, le tout au format PEM. Première opération, exporter tout cela en format PKCS12 (lisible par keytool) :
openssl pkcs12 -export -inkey http.key -in http.crt -out http.pkcs12
openssl pkcs12 -export -inkey consoleproxy.key -in consoleproxy.crt -out consoleproxy.pkcs12

A chaque fois, openssl va vous demander un mot de passe de sécurisation des fichiers PKCS12. Je le note <password_pkcs12> dans les commandes suivantes. Ensuite, on importe ces deux fichiers PKCS12 dans un nouveau conteneur JKS. De la même façon, le password de sécurisation du conteneur JKS s’appelle <password_conteneur>. Première commande, on crée en même temps le nouveau keystore en ajoutant le premier certificat (http ici) :
/opt/vmware/vcloud-director/jre/bin/keytool -importkeystore -deststorepass <password_conteneur> -destkeystore vcloud.ks -srckeystore http.pkcs12 -srcstoretype PKCS12 -srcstorepass <password_pkcs12>
Vous devez obtenir une output de ce type :

Par défaut, le premier certificat est enregistré sous l’alias “1”, on va le renommer en http pour que vcloud retrouve ses petits ensuite :
/opt/vmware/vcloud-director/jre/bin/keytool -changealias -keystore vcloud.ks -srcalias 1 -destalias http

Le mot de passe du conteneur vous est demandé (évidemment). Enfin, on refait quasiment la même manipulation pour le second certificat “console proxy” :
/opt/vmware/vcloud-director/jre/bin/keytool -importkeystore -deststorepass <password_conteneur> -destkeystore vcloud.ks -srckeystore consoleproxy.pkcs12 -srcstoretype PKCS12 -srcstorepass <password_pkcs12>
puis
/opt/vmware/vcloud-director/jre/bin/keytool -changealias -keystore vcloud.ks -srcalias 1 -destalias consoleproxy

Enfin, pour controler que notre conteneur est parfait, une petite interrogation :
/opt/vmware/vcloud-director/jre/bin/keytool -list -keystore vcloud.ks
… doit donner un résultat de ce type :

Enfin, pour reconfigurer votre noeud pour prendre en compte ce nouveau keystore (en cas de changement de mots de passe par exemple), lancez la commande /opt/vmware/vcloud-director/bin/configure et répondez aux quelques questions posées :

Avec ces commandes, vous êtes paré pour importer sans souci des certificats SSL standards dans votre VCD ;)

0