Étape 1 : gérer les certificats

Transcription

1 Étape 1 : gérer les certificats Nous allons utiliser TinyCA pour gérer les certificats. Je vous laisse l'installer comme bon vous semble. Sous Debian, c'est juste «apt-get install tinyca». Je vous conseille simplement de l'installer sur une machine bien protégée, si possible pas sur le serveur qui héberge le serveur WEB, ni sur le serveur OpenSI ni sur tout autre serveur public. On n'est jamais trop prudent. Dans le même ordre d'idée, ne l'utilisez que sous un compte sûr : il va créer tout un tas de fichiers sensibles dans la «homedir» de cet utilisateur (sous ~/.TinyCA). Soyez prudents! Au lancement, vous avez ça : Saisissez les informations selon votre organisation. Elles ne sont là qu'à titre informatif, mais donner des informations représentant la réalité pourra s'avérer utile par la suite. N'hésitez pas à donner une durée de vie suffisante à votre CA (Certification Authority) ; j'ai mis ici 10 ans. Si vous voulez utiliser ce CA pour gérer des certificats à usages divers et variés, restez humble quand à la longueur des clefs : certaines implémentations de IPSec par exemple ne fonctionnent pas avec des clefs de 2048 bits. Par contre, ne soyez pas trop laxiste avec le mot de passe du CA, et surtout, surtout, ne l'oubliez pas! Un maître des clefs qui pose des cadenas trop fragiles ou qui perd ses clefs, ça fait mauvais genre... La fenêtre suivante (CA Configuration) dit «si vous n'êtes pas sûr, laissez inchangées les valeurs par défaut». Je ne sais pas vous, mais moi je ne suis pas sûr (et surtout très fainéant). Laissons donc les valeurs inchangées. On arrive alors à ça :

2 De là, nous allons d'abord créer une «requête» (une demande de certificat et une clef). Allons sous l'onglet «Requests» et cliquons sur «New» : Si vous ne voulez pas importuner les futurs utilisateurs avec des messages incessants concernant une incohérence entre le certificat et le serveur WEB, donnez bien comme «Common Name» le nom du serveur Apache tel qu'il est vu des utilisateurs. Nous allons maintenant jouer pour la première fois notre rôle de maître des clefs en signant la

3 demande de certificat que nous venons de créer pour le serveur. Cliquons donc sur «Sign» et sélectionnons «Sign Request (Server)» : Vous aurez besoin pour cela du mot de passe du CA ; vous ne l'avez pas déjà oublié, n'est-ce pas? Nous allons maintenant exporter la clef du serveur (créée en même temps que la requête) en allant sous l'onglet «Keys» : Choisissez un emplacement temporaire pour le fichier «.pem» (/tmp p.ex.). Pour le serveur, nous n'allons pas protéger la clef (mais nous la garderons précieusement) pour ne pas avoir à saisir le mot de passe à chaque démarrage d'apache. Notez que TinyCA s'en lave les mains tel un Ponce Pilate électronique :

4 Oui, oui, nous savons ce que nous faisons. Le mot de passe est celui entré lors de la création de la requête, vous suivez? Ok, procédons de la même manière pour exporter le certificat : Question : pourquoi ne demande-t-il pas de mot de passe pour exporter le certificat? Non, il n'y a rien à gagner. La réponse est que le certificat est une clef publique qui ne peut servir qu'à celui qui possède la clef privée correspondante (qui, elle, est théoriquement protégée par un mot de passe). Je ne m'étendrai pas ici sur la théorie des certificats et de la cryptographie asymétrique. Notez au passage le bouton «Revoke» et le statut «VALID» de notre certificat, nous y reviendrons tout à l'heure. Maintenant, exportons également le certificat du CA en retournant au premier onglet : Je ne ferai pas de commentaires. De même, je ne ferai pas de capture d'écran pour l'exportation de la CRL. Par contre, je préciserai quand même qu'il s'agit de la «Certificat Revocation List», la liste

5 des certificats révoqués. En effet, si pour une raison quelconque vous voulez qu'un certificat distribué à un tiers ne soit plus utilisable, il vous faudra 1) le révoquer et 2) ré-exporter la CRL pour faire savoir aux autres (au serveur Apache par exemple) que ce certificat est révoqué. Nous y reviendrons à l'étape 3. En attendant, exportez cette CRL (il vous faudra de nouveau le mot de passe du CA, je vous laisse deviner pourquoi). Étape 2 : configuration d'apache Bien, après l'étape 1, nous avons le certificat du CA le certificat et la clef du serveur WEB la CRL Je vais ici travailler avec un Apache 2.0 sous Debian Sarge. Je vous laisse transposer la méthode à votre version d'apache et à votre distribution préférée. Tout d'abord, il faut que l'accès au serveur Tomcat qui fait tourner OpenSI passe bien par Apache. Sinon, c'est une toute autre histoire et je ne sais pas comment utiliser une connexion SSL directement sous Tomcat (avis aux spécialistes). Cette partie est un peu hors sujet, mais voici en résumé ce qu'il faut mettre en place : 1. un connecteur JK2 dans la configuration Tomcat (c'est de base avec Tomcat4 sous Debian, sur le port 8009) 2. le module JK2 d'apache : apt-get install libapache2-mod-jk2 3. un fichier /etc/apache2/workers2.properties correctement configuré Pour le 1 vous devez avoir ça dans /etc/tomcat4/server.xml : <!-- Define a Coyote/JK2 AJP 1.3 Connector on port > <Connector classname="org.apache.coyote.tomcat4.coyoteconnector" port="8009" minprocessors="5" maxprocessors="75" enablelookups="true" acceptcount="10" debug="0" connectiontimeout="20000" useurivalidationhack="false" protocolhandlerclassname="org.apache.jk.server.jkcoyotehandler"/> Pour le 2, n'oubliez pas de vérifier que la dernière ligne du fichier /etc/apache2/mods-enabled/jk2.conf est bien dé-commentée : JkSet config.file /etc/apache2/workers2.properties Enfin en 3, le fichier workers2.properties doit contenir au moins ça : [logger] level=debug [config:] file=${serverroot}/conf/workers2.properties debugenv=0 [urimap:] info=maps the requests. Options: debug [lb:lb] info=default load balancer.

6 [channel.socket:localhost:8009] info=ajp13 forwarding over socket tomcatid=localhost:8009 [uri:/opensi] info=example webapp in the default context. context=/opensi [uri:/opensi/servlet/*] info=prefix mapping [uri:/opensi/*.jsp] info=extension mapping [uri:/opensi/*] info=map the whole webapp J'ai d'autres trucs dans mon fichier, mais je ne suis pas sûr que ça serve. Le plus simple, c'est de recopier /usr/share/doc/libapache2-mod-jk2/examples/workers2.properties et de rajouter les 4 derniers blocs ci-dessus (ceux concernant OpenSi). Note importante : vous avez vu les «localhost»? Ça veut dire que le serveur Tomcat4 peut être sur une autre machine que le serveur Apache2. Si! Il suffit à priori de changer ces «localhost» par le nom du serveur Tomcat4 (donc du serveur OpenSi). Les spécialistes de la sécurité auront compris qu'ils peuvent mettre leur serveur Apache dans une DMZ et n'ouvrir que le port 8009 entre cette DMZ et le LAN. Bien, tout le reste ne concerne plus que le serveur Apache, indépendamment de Tomcat. Tout d'abord, Le serveur doit écouter sur le port 443 (HTTPS) : /etc/apache2/ports.conf Listen 443 Attention, si votre serveur écoute aussi sur le port 80, cela permet de contourner l'utilisation des certificats. Il faut passer par des VirtualHost dans ce cas pour que l'accès au contexte OpenSI ou à toute autre zone protégée se fasse exclusivement par le port 443. Ensuite, il faut placer sur le serveur les certificats et clefs créés à l'étape 1. Vous avez toujours rêvé de faire comme les caissières de Carrefour? C'est le moment d'appeler un type de la sécurité pour qu'il vous escorte pendant que vous transportez votre disquette (ou votre clef USB) de la machine où tourne TinyCA et le serveur WEB. Apache2 s'installe (sous Debian) avec un répertoire /etc/apache2/ssl. Vous allez donc : dans.../ssl/crl copier MaitreDesClefs-crl.pem dans.../ssl/crt copier compteladessus.com-cert.pem et MaitreDesClefs-cacert.pem dans.../ssl/private copier compteladessus.com-key.pem Attention à ce dernier fichier : il n'est plus protégé par un mot de passe (rappelez-vous, c'était pour que Apache démarre sans rien demander). Assurez vous qu'il n'est lisible que par l'utilisateur qui fait tourner Apache (www-data sous Debian). Assurez vous également que le module ssl est autorisé (a2enmod ssl en tant que root). Puis ajoutez ceci dans apache2.conf (ou autre fichier de configuration tel que /etc/apache2/sitesenabled/default par exemple) : SSLEngine on SSLCACertificateFile /etc/apache2/ssl/crt/maitredesclefs-cacert.pem SSLCertificateFile /etc/apache2/ssl/crt/compteladessus.com-cert.pem

7 SSLCertificateKeyFile /etc/apache2/ssl/private/compteladessus.com-key.pem SSLCaRevocationFile /etc/apache2/ssl/crl/maitredesclefs-crl.pem SSLVerifyClient require Personnellement, j'ai simplement recopié /etc/apache2/sites-enabled/default en default_ssl, j'y ai placé les lignes ci-dessus (après le DocumentRoot) puis j'ai modifié les 2 premières lignes comme ceci : NameVirtualHost *:443 <VirtualHost *:443> Mon fichier ports.conf comporte 2 lignes (une pour le port 80 et une pour le 443), et mon garde barrière ne laisse passer que le 443 de l'extérieur. Ainsi, grâce au SSLVerifyClient require, vous ne pouvez rentrer chez moi que si je vous donne un certificat valide, et que en HTTPS. Étape 3 (alias étape 1-bis) : gestion des certificats utilisateurs. C'est très simple, il suffit de reprendre les opérations du 1 à partir de la création de la requête, avec les différences suivantes : Les données sont celles permettant d'identifier l'utilisateur (organisation, département, etc.) nous remplissons cette fois la case « », et nous ajoutons cette adresses au certificat (case «Add Address to Subject DN» lors de la signature de la requête) nous signons avec l'option «client» («Sign Request (Client)»). nous n'exportons pas la clef, mais nous exportons le certificat sous la forme PKCS#12 avec la clef (et avec le certificat du CA) : Le «Key Password» est le mot de passe de la clef, celui saisi lors de la création de la requête. Le «Export Password» va servir à l'étape 4. Il vous faudra le faire connaître à l'utilisateur pour qu'il puisse intégrer son certificat au format PKCS#12 dans Firefox.

8 Il ne vous reste plus qu'à transmettre ce fichier y compris par , pourquoi pas (il est protégé par le mot de passe d'exportation) à votre utilisateur. Par contre, prenez garde à ne laisser connaître le mot de passe d'exportation qu'à l'utilisateur. Si vous avez un doute sur l'intégrité du certificat (le mot de passe a été intercepté, l'utilisateur se met à boire ou devient dépressif), révoquez le! Et surtout : n'oubliez pas de ré-exporter la CRL après cette révocation pour mettre à jour celle déposée dans.../ssl/crl sur le serveur WEB. Note : En toute logique, et pour être parfaitement «sécure», c'est l'utilisateur qui devrait créer sa requête et sa clef, avec son propre TinyCA (ou autre outil), puis vous envoyer la requête pour que vous l'importiez sous votre propre TinyCA. Ensuite, vous signeriez cette requête, exporteriez le certificat ainsi signé (au format PEM). L'utilisateur ré-importerait alors ce certificat dans son outil et générerait son propre fichier PKCS#12 avec ce certificat et sa clef. Ainsi, vous ne connaîtriez jamais son mot de passe de clef, et même si le mot de passe d'exportation était volé, il ne servirait à rien sans le mot de passe de clef (connu, donc, uniquement de l'utilisateur ; suivez un peu). Le problème, c'est que TinyCA n'exporte pas les requêtes et n'importe pas les certificats (c'est ballot). Il faut jouer avec les fichiers créés par lui dans le répertoire ~/.TinyCA. Et vous savez comment il nome les fichiers là dedans? Avec la version codée Base64 du DN! En clair (si je puis dire), mon fichier de requête pour l'utilisateur Olivier Delemar s'appelle : T2xpdmllciBEZWxlbWFyOm9saXZpZXIuZGVsZW1hckBnZW50aWxjbGllbnQuY29tOlNlcnZpY2UgQ29t chrhomdlbnrpbensawvuddpncmvub2jsztppc2vyztpgug==.pem Si, je vous assure. En Base64, ça veut dire : Olivier Delemar:olivier.delemar@gentilclient.com:Service Compta:gentilClient:grenoble:isere:FR (évidemment, ça passerait moyennement comme nom de fichier...) Étape 4 : configuration de Firefox Il s'agit maintenant d'importer dans Firefox le certificat PKCS#12 que nous venons de préparer. Ce certificat est la clef qui autorisera à accéder au serveur. Il permettra d'utiliser OpenSI, mais aussi toutes les applications WEB protégées. Ce certificat est utilisable avec Firefox, mais aussi avec Internet Explorer. Pour importer le certificat dans Firefox, il faut aller dans le menu «Edition», puis «Préférences» et enfin dans la rubrique «Avancé». Déployer la partie «Certificats» pour accéder à la gestion des certificats :

9 Dans la fenêtre qui s'ouvre alors, cliquer sur «Importer» sous l'onglet «Vos certificats», puis repérer et sélectionner le fichier OD_gentilclient_com-cert.p12 là où il est (après extraction du mail, par exemple). À la demande de mot de passe, répondre avec le mot de passe d'exportation définit lors de l'exportation du certificat au format PKCS#12. Enfin la dernière étape est d'entrer les paramètres dans OpenSI pour qu'il se connecte au serveur en HTTPS. Pour cela, dans l'interface OpenSI, cliquer sur «Paramètres avancés», cocher «serveur sécurisé», entrer l'adresse de serveur et 443 comme port (j'ai eu la flème de refaire ma capture d'écran, alors j'ai noirci l'adresse du serveur ; ici, ce serait bien sûr) :