Dans le contexte ITIM, nous voulons sécuriser l'accès au Self-Service via https, notamment car celui-ci permet aux utilisateurs de changer ou de ré-initialiser leur mot de passe.
Cela a l'air facile, puisque le serveur http IHS IBM Http Server est basé sur apache. Dans un précédent article, j'expliquais comment faire pour activer un accès https sur apache.
Malheureusement, IBM n'utilise pas les composants OpenSSL, mais utilise ses propres modules, et notamment mod_ibm_ssl pour le module du serveur http, qui est de plus incompatible avec les certificats SSL généré par les utilitaires OpenSSL. Il faut donc utiliser toute la panoplie des outils IBM.
La mise en place de https passe par plusieurs étapes :
- Création du certificat
- Activation de SSL sur le serveur http
- Paramétrage du serveur https
Création du certificat
Nous allons faire les manipulations en ligne de commande, car le serveur ne dispose pas d'une interface graphique.
L'utilitaire IBM dans ce cas est gsk7cmd, un script shell qui lance le programme Java ikeyman.
Cet utilitaire permet d'agir sur plusieurs éléments :
- les bases de données de clés (option keydb)
- les certificats (option cert)
- les demandes de certificats (option certreq)
- les clés secrètres (option seckey)
Note : on peut également utiliser le programme gsk7capicmd, qui est un exécutable POSIX (pas de Java), mais qui supporte un chiffrement plus fort que gsk7cmd. Il est également plus rapide.
Création d'une base de données de clés
Nous allons d'abord créer une base de données de clés (key database), qui va stocker les certificats. Cette base sera stockées dans le répertoire /etc/ssl/certs, qui permet de regrouper les certificats.
$IHS_HOME/bin/gsk7cmd -keydb -create -db /etc/ssl/certs/ihs.kdb -pw IBMHttpServer -type cms -expire 3650 -stash
Les options utilisées :
- keydb : indique que l'on gère la base de données
- create : on va créer une nouvelle base de données
- db : chemin complet vers le fichier de la base
- pw : mot de passe pour accéder à la base de données
- type : précise le type de la base, CMS = Certificat Management System
- expire : durée (en jours) d'expiration du mot de passe
- stash : indique que l'on va cacher le mot de passe dans un fichier
Nous pouvons ensuite créer un certificat. Celui-ci peut être auto-signé, ou être une demande de certification qui sera par la suite signé par une PKI interne, afin d'être reconnu par les navigateurs.
Génération d'un certificat auto-signé
$IHS_HOME/bin/gsk7cmd -cert -create -db /etc/ssl/certs/ihs.kdb -pw IBMHttpServer -label "ITIM-Self-Service" \ -expire 3650 -default_cert [yes|no] -dn "CN=myserver.mycorp.com,O=mycorp,C=fr"
Les options utilisées :
- cert : indique que l'on gère les certificats
- create : on va créer un nouveau certificat (auto signé)
- db : chemin complet vers le fichier de la base
- pw : mot de passe pour accéder à la base de données
- label : libellé pour le certificat
- default_cert : est-ce que le certificat est celui par défaut pour la base de données
- dn : DN complet (voir ci-dessous)
- expire : durée (en jours) d'expiration du mot de passe
Le format du DN est celui-ci : CN=common_name, O=organization, OU=organization_unit, L=location, ST=state, province, C=country.
Seuls les attributs CN, O et C sont requis.
On peut par exemple avoir :
CN=itimserver.mycorp.com,O=MyCompany,OU=IT,C=FR
Le CN doit correspondre au FQDN (Fully Qualified Domain Name) du serveur (correspondant à l'URL qui est protégée en https).
Génération d'une demande de certificat
On peut générer une demande de certificat, qui devra par la suite être signée par une autorité de certification :
$IHS_HOME/bin/gsk7cmd -certreq -create -db /etc/ssl/certs/ihs.kdb -pw IBMHttpServer -label "ITIM-Self-Service" \ -dn DN -size 1024 -file /etc/ssl/certs/itim-self.req
Réception du certificat signé
Une fois le certificat signé par l'autorité, on l'intègre dans la key database :
$IHS_HOME/bin/gsk7cmd -cert -receive -file /tmp/myNewCert.pem -db /etc/ssl/certs/ihs.kdb -pw IBMHttpServer \ -format [ascii | binary] -default_cert [yes | no]
Par exemple :
$IHS_HOME/bin/gsk7cmd -cert -receive -file /etc/ssl/certs/itimserver.mycorp.com.pem \ -db /etc/ssl/certs/ihs.kdb -pw IBMHttpServer -format ascii -label "ITIM-Self-Service" -default_cert yes
Les options utilisées :
- cert : indique que l'on gère les certificats
- receive : on va importer un certificat signé
- db : chemin complet vers le fichier de la base
- pw : mot de passe pour accéder à la base de données
- format : précise si l'autorité de certification fournit le certificat en format ASCII ou binaire
- label : libellé pour le certificat. Ceci permet de distinguer les différents certificats dans la base
- default_cert : est-ce que le certificat est celui par défaut pour la base de données
Lister les certificats dans la base
Il est possible de lister les certificats de la base :
bin/gsk7cmd -cert -list -db /etc/ssl/certs/ihs.kdb -pw IBMHttpServer Certificates in database /etc/ssl/certs/ihs.kdb: ITIM-Self-Service
On peut également avoir le détail, en précisant le libellé :
bin/gsk7cmd -cert -details -db /etc/ssl/certs/ihs.kdb -pw IBMHttpServer -label ITIM-Self-Service Libellé : ITIM-Self-Service Taille de clé : 1024 Version : X509 V3 Numéro de série : 53 AA E8 E8 Emis par : CN=itimserver.mycorp.com, O=mycorp, C=FR Sujet : CN=itimserver.mycorp.com, O=mycorp, C=FR Valide : Du : mercredi 25 juin 2014 17 h 21 CEST au : samedi 22 juin 2024 17 h 21 CEST Empreinte digitale : 3D:00:42:7C:FB:84:76:0B:C7:F3:05:59:E0:DD:72:08:B3:B6:8B:6A Algorithme de signature : SHA1withRSA (1.2.840.113549.1.1.5) Etat de confiance : activé
Importer un certificat
Il est également possible d'importer un certificat, uniquement au format PKCS12 ou KeyDatabase.
Dans ce cas, la commande à utiliser est :
bin/gsk7cmd -cert -import -file /le/chemin/vers/monfichier.p12 -target_type kdb -target /etc/ssl/certs/ihs.kdb -target_pw IBMHttpServer
Note : l'utilisation de gsk7cmd (qui encapsule du Java) peut conduire à une erreur de type :
The command cannot complete because your JRE is using restricted policy files. Replace your policy files with the Unlimited Strength files.
On peut dans ce cas utiliser la commande gsk7capicmd, qui est un exécutable Linux. La syntaxe n'est pas la même :
bin/gsk7capicmd -cert -import -db /le/chemin/vers/monfichier.p12 -type pkcs12 -target_type cms -target "/etc/ssl/certs/ihs.kdb" -target_pw IBMHttpServer
Le fichier PKCS12 est protégé par un mot de passe, car il contient le certificat ET la clé privée.
Activation de SSL sur le serveur http
Maintenant que nous avons un certificat, il faut activer le SSL sur le serveur, en activant plusieurs choses :
- écouter sur le port 443
- charger le module mod_ibm_ssl
Ceci s'effectue dans le fichier de configuration $INS_HOME/conf/httpd.conf, dans lequel on ajoutera les lignes suivantes :
.../... NameVirtualHost *:80 NameVirtualHost *:443 LoadModule ibm_ssl_module modules/mod_ibm_ssl.so Listen 443
Les deux premières lignes permettent de gérer les VirtualHost sur les ports http et https (voir ci-dessous).
Paramétrage du serveur https
Le paramétrage s'effectue dans le fichier $INS_HOME/conf/httpd.conf, au niveau d'un VirtualHost. Par exemple :
<VirtualHost *:443> ServerName myserver.mycorp.com SSLEnable KeyFile /etc/ssl/certs/ihs.kdb LogLevel warn ErrorLog logs/myserver-error.log CustomLog logs/myserver-access.log common </VirtualHost>
Pour le serveur myserver.mycorp.com, on active le SSL (paramètre SSLEnable), avec le fichier de base de données précisé par le paramètre keyFile
Troubleshooting
Erreur lors de l'import d'un certificat
Lors de l'import d'une fichier pkcs12, si le label existe déjà (pour la remplacer par exemple) on a un message :
Error: 23 Please refer to the GSKCapiCmd User's Guide for the meaning of the error. Error id: GSKKM_ERR_DATABASE_DUPLICATE_KEY_LABEL
ou encore
Error: 2 Please refer to the GSKCapiCmd User's Guide for the meaning of the error.
Dans ce cas, il faut d'abord supprimer l'ancien certificat, avec son label en paramètre :
bin/gsk7capicmd -cert -delete -db /etc/ssl/certs/ihs.kdb -pw IBMHttpServer -label MaVieilleCle
Erreur au redémarrage IHS
Si en redémarrant IHS, on a dans le fichier log des lignes telles que :
[Fri Jun 27 16:00:23 2014] [error] [client 128.240.165.134] [864a618] SSL0208E: SSL Handshake Failed, Certificate validation error
Il s'agit d'un problème d'autorité de certification qui n'est pas reconnue. Ceci peut se vérifier avec la commande :
$IHS_HOME/bin/gsk7capicmd -cert -list -db /etc/ssl/certs/ihs.kdb -pw IBMHttpServer Certificates found: * default, - has private key, ! trusted *-! ITIM-Self-Service
Le certificat existe, mais n'est pas digne de confiance...
Note : on utilise ici la commande gsk7capicmd, au lieu de gsk7cmd, mais les 2 commandes sont interchangeables.
Il faut alors ajouter dans la base de données la chaîne de certificats qui ont permis de signer notre certificat :
$IHS_HOME/bin/gsk7capicmd -cert -add -db /etc/ssl/certs/ihs.kdb -pw IBMHttpServer -label ChainCA -file /tmp/chain.pem
On peut alors vérifier que cela fonctionne :
bin/gsk7capicmd -cert -list -db /etc/ssl/certs/ihs.kdb -pw IBMHttpServer Certificates found: * default, - has private key, ! trusted ! ChainCA *-! ITIM-Self-Service
Références
Les références utilisées sont :