unnamed

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

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 ;)

unnamed

Implanter des certificats SSL spécifiques sur une tête NAS EMC Celerra

Pour ceux qui utilisent au quotidien des VNX Unified ou des têtes NAS dédiées de type EMC Celerra, le souci revient régulièrement et il st particulièrement rébarbatif, à l’heure où tous les navigateurs serrent beaucoup la vis concernant la validité des certificats SSL.

En effet, à chaque connexion ainsi que lors de l’utilisation des fenêtres popup de configuration des NAS Celerra, on tombe souvent sur l’alerte de certificat, et pour cause : de base, les Control Stations embarquent un certificat auto-signé, non approuvé par une autorité racine de confiance. Plusieurs méthodes existent pour se débarrasser de ce genre d’alerte, la plus radicale étant un paramétrage spécifique du navigateur autorisant d’accepter n’importe quel certificat. Pas génial, c’est le moins qu’on puisse dire, si vous vous servez de ce même navigateur pour des activité plus quotidiennes par ailleurs.

La solution la plus pérenne et, de mon point de vue, la meilleure, consiste tout simplement à changer les certificats auto-signés des CS par des certificats validés par votre PKI interne (si vous en disposez évidemment). La procédure, quoique relativement simple, n’est pas clairement décrite dans les documentations Celerra.

Lire la suite …