
Guide pratique des certificats SSL

Version franaise du _SSL Certificates HOWTO_

Franck Martin

   28 fvrier 2003
   _Historique des versions_
   Version v0.5.fr.1.0 2003-02-28 Revu par : FR
   Traduction franaise de Franois Romieu. Relecture de Pierre Machard.
   Traduction de la licence et quelques retouches de Jean-Philippe
   Gurard <jean-philippe.guerard@laposte.net>.
   Version v0.5        2002-10-20 Revu par : FM
   Ajout des information de Nate Carlson <natecars@natecarlson.com> sur
   IPsec -- Ajout des informations de Bill Shirley <webnut@telocity.com>
   sur IMAPS et POPS -- Ajout des informations de Colin McKinnon
   <colin@wew.co.uk> sur WinCrypt.
   Version v0.4        2002-06-22 Revu par : FM
   Corrections diverses -- ajout d'illustrations en ASCII
   Version v0.3        2002-05-09 Revu par : FM
   Ajout d'informations sur les extensions x509v3 -- Corrections de
   fautes
   Version v0.2        2001-12-06 Revu par : FM
   Ajout du fichier openssl.cnf -- Ajout d'information sur CRL de la part
   d'Averroes <a.averroes@libertysurf.fr> -- Corrections de fautes
   Version v0.1        2001-11-18 Revu par : FM
   Cration du guide pratique

   Une exprience de gestion d'une autorit de certification. La cration
   et la signature de certificats destins  la scurisation des
   transactions web, au courrier,  la signature du code et  d'autres
   usages.
     _________________________________________________________________

   _Table des matires_
   1. Principes gnraux

        1.1. Introduction
        1.2. Que sont SSL et les certificats ?
        1.3. Qu'en est-il de S/MIME et des autres protocoles ?

   2. Gestion des certificats

        2.1. Installation
        2.2. Cration d'une autorit de certification racine
        2.3. Cration d'une autorit de certification non-racine
        2.4. Mise en place du certificat de CA racine comme certificat
                fiable.

        2.5. Gestion des certificats

   3. Emploi des certificats avec les applications

        3.1. Scurisation des protocoles Internet
        3.2. Scurisation du courrier lectronique
        3.3. Protection des fichiers
        3.4. Scurisation des programmes
        3.5. IPSec

   4. PKI Globale

        4.1. PKIs existantes
        4.2. Le besoin d'une PKI globale
     _________________________________________________________________

Chapitre 1. Principes gnraux

1.1. Introduction

   Comme moi, vous avez srement lu avec attention les pages de manuel
   des applications fournies par le projet OpenSSL et, comme moi
   autrefois, vous ne voyez pas trop par o commencer ni comment
   travailler de faon scurise avec des certificats. Ce document rpond
    l'essentiel de vos questions.

   Ce guide pratique traite aussi d'applications hors du monde Linux. Il
   ne sert  rien d'mettre des certificats qu'on ne peut pas
   utiliser ... Toutes les applications ne figurent pas ici. Envoyez moi
   donc s'il vous plat vos ajouts et corrections. On peut me contacter
   en anglais  l'adresse suivante : <franck@sopac.org>.

   La version originale de ce guide pratique est publi via le Projet de
   documentation Linux. Vous y trouverez la dernire version originale de
   ce document.

   La version franaise de ce document est publie par le projet de
   traduction traduc.org. Vous y trouverez notamment la dernire version
   franaise de ce document.
     _________________________________________________________________

1.1.1. Droits d'utilisation et limitation de responsabilit

   Ce document est distribu dans l'espoir qu'il se rvlera utile, mais
   SANS AUCUNE GARANTIE  sans mme la garantie implicite qu'il soit
   PROPRE  LA VENTE ou ADAPT  UN BESOIN PARTICULIER.

   En rsum, si les conseils qui vous sont prodigus ici annihilent la
   scurit de votre application de commerce lectronique, eh bien, tant
   pis pour vous -- ce n'est jamais de notre faute. Dsol.

   Copyright  2001 Franck Martin et divers membres de la liste de
   diffusion openssl-users. Ce document est diffus selon les termes de
   la licence de documentation libre GNU (GFDL). Une version franaise
   officieuse de la version 1.1 de cette licence est disponible sur
   http://www.linux-france.org/prj/jargonf/general/gfdl.html.

   Vous pouvez librement copier et distribuer (commercialement ou
   gratuitement) ce document dans n'importe quel format. Il vous est
   demand de faire parvenir vos corrections et commentaires au
   responsable actuel de ce document. Vous pouvez crer des travaux
   drivs de celui-ci et les distribuer si vous respectez les conditions
   suivantes :

    1. Faire parvenir vos travaux drivs (dans le format le plus
       appropri tel que SGML) au Projet de documentation Linux (LDP), ou
        un projet du mme type pour qu'il soit diffus sur internet. Si
       vous n'envoyez pas votre document au LDP, informez le LDP de
       l'endroit o votre document est disponible.
    2. Diffuser vos travaux drivs sous la mme licence, ou sous la
       licence publique GNU (GPL). Inclure la notice prcisant les droits
       d'utilisation, et au moins un pointeur sur la licence utilise.
    3. Reconnatre la contribution des prcdents auteurs et
       contributeurs principaux. Si vous envisagez de raliser un travail
       driv autre qu'une traduction, il vous est demand d'en discuter
       au pralable avec le responsable actuel de ce document.

   Il vous est galement demand que si vous publiez ce guide pratique
   dans un format papier, vous envoyiez  ses auteurs quelques
   exemplaires  des fins d'_valuation_ :-). Vous voudrez peut-tre
   galement m'envoyer quelque chose pour assaisonner mes pinards ;-)
     _________________________________________________________________

1.1.2. Disclaimer and Licence

   Note

   La licence de ce document nous oblige  inclure une copie en anglais
   de ce texte. La version franaise de ce texte se trouve  la section
   prcdente.

   This document is distributed in the hope that it will be useful, but
   WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

   In short, if the advises given here break the security of your
   e-commerce application, then tough luck- it's never our fault. Sorry.

   Copyright  2001 by Franck Martin and others from the openssl-users
   mailing list under GFDL (the GNU Free Documentation License).

   Please freely copy and distribute (sell or give away) this document in
   any format. It's requested that corrections and/or comments be
   forwarded to the document maintainer. You may create a derivative work
   and distribute it provided that you:

    1. Send your derivative work (in the most suitable format such as
       sgml) to the LDP (Linux Documentation Project) or the like for
       posting on the Internet. If not the LDP, then let the LDP know
       where it is available.
    2. License the derivative work with this same license or use GPL.
       Include a copyright notice and at least a pointer to the license
       used.
    3. Give due credit to previous authors and major contributors. If
       you're considering making a derived work other than a translation,
       it's requested that you discuss your plans with the current
       maintainer.

   It is also requested that if you publish this HOWTO in hardcopy that
   you send the authors some samples for 'review purposes' :-). You may
   also want to send something to cook my noodles ;-)
     _________________________________________________________________

1.1.3. Pr-requis

   Comme indiqu dans l'introduction, ce document est un aide-mmoire et
   vous devez donc consulter les pages de manuel du paquet OpenSSL. La
   lecture de documents relatifs  la scurit est vivement conseille
   afin de comprendre comment votre scurit peut tre compromise. Les
   certificats sont destins  amliorer la scurit des transactions et
   il donc important que vous compreniez les implications de vos actes en
   terme de scurit ainsi que les limitations d'OpenSSL.
     _________________________________________________________________

1.2. Que sont SSL et les certificats ?

   Le protocole SSL (_Secure Socket Layer_) a t cr par Netscape pour
   scuriser les transactions entre les serveur web et les outils de
   navigation. Il a recours  un tiers, l'autorit de certification
   (_CA/Certificate Authority_) qui identifie n'importe laquelle des
   extrmits ou les deux. Il s'agit du fonctionnement en trs rsum.

    1. Un navigateur demande une page web scurise (en gnral
       https://).
    2. Le serveur web met sa clef publique accompagne de son
       certificat.
    3. Le navigateur vrifie que le certificat a t mis par un tiers
       fiable (en gnral une autorit de certification racine), qu'il
       est toujours valide et qu'il se rapporte bien au site en cours.
    4. Le navigateur emploie la clef publique du serveur pour chiffrer
       une clef de chiffrement symtrique alatoire et l'envoie au
       serveur web avec l'URL demande et diverses donnes HTTP
       chiffres.
    5. Le serveur web dchiffre la clef de chiffrement symtrique grce 
       sa sa clef prive et utilise la clef de chiffrement symtrique
       pour rcuprer l'URL et les donnes HTTP.
    6. Le serveur renvoie le document html et les donnes HTTP chiffres
       avec la clef symtrique.
    7. Le navigateur dchiffre l'ensemble avec la clef symtrique et
       affiche les informations.

   Plusieurs concepts mritent d'tre assimils.
     _________________________________________________________________

1.2.1. Clef publique / clef prive

   Le chiffrement  base de clef publique garantit qu'une donne chiffre
   par une clef, publique ou prive, ne peut tre dchiffre que par la
   clef associe. Cela peut paratre surprenant mais croyez moi, a
   fonctionne. Les clefs sont de mme nature et leurs rles peuvent tre
   inverss : ce que l'une chiffre est dchiffrable par l'autre. La paire
   de clef repose sur des nombres premiers et leur longueur, exprime en
   digits binaires, traduit la difficult qu'il y a  dchiffrer un
   message sans connaissance  priori de la clef ncessaire. L'astuce
   consiste  conserver une clef secrte (la clef prive) et  distribuer
   l'autre clef (la clef publique)  tout le monde. N'importe qui peut
   vous envoyer un message chiffr mais personne d'autre que vous ne peut
   le dchiffrer tant que vous tes le seul  conserver un des deux
   membres de la paire de clefs. On peut galement prouver qu'un message
   provient de vous en le chiffrant avec votre clef prive : seule la
   clef publique correspondante le dchiffrera. Notez que le message
   n'est pas protg parce que vous le signez. Tout le monde a accs  la
   clef de dchiffrement, ne l'oubliez pas.

   Le problme consiste  obtenir la clef publique du correspondant. En
   gnral, vous lui demanderez de la transmettre via un message sign
   qui la contiendra accompagne d'un certificat.
   Message-->[Clef publique]-->Message chiffr-->[Clef prive]-->Message
     _________________________________________________________________

1.2.2. Le certificat

   Qu'est-ce qui vous garantit que vous dialoguez bien avec la bonne
   personne ou le bon site web ? En principe, quelqu'un aura fait
   l'effort (s'il est srieux) de vrifier que les propritaires du site
   sont bien ceux qu'ils affirment tre. On fait naturellement confiance
    ce quelqu'un : son certificat, un certificat racine, est incorpor 
   votre navigateur. Un certificat contient des informations relatives 
   son propritaire comme une adresse lectronique, un nom, l'usage prvu
   du certificat, une dure de validit, un identifiant de localisation
   ou un nom qualifi (_DN/Distinguished Name_) qui comprend le nom
   d'usage (_CN/Common Name_) et l'identifiant du signataire du
   certificat. Le certificat comprend galement la clef publique et un
   hach pour garantir l'intgrit du message. Comme vous avez dcid de
   faire confiance au signataire du certificat, vous accordez du crdit 
   son contenu. On parle d'arbre de confiance de certification ou de
   chemin de certification. En gnral, le navigateur et les applications
   incluent d'office le certificat racine d'autorits de certification
   bien connues. L'autorit de certification tient  jour une liste des
   certificats signs ainsi qu'une liste des certificats rvoqus. Un
   certificat n'est pas fiable tant qu'il n'est pas sign puisque seul un
   certificat sign ne peut pas tre modifi. Un certificat peut se
   signer lui-mme. On parle alors de certificat auto-sign. Tous les
   certificats de CA racines sont ce type.
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=SOPAC Root CA/Email=
administrator@sopac.org
        Validity
            Not Before: Nov 20 05:47:44 2001 GMT
            Not After : Nov 20 05:47:44 2002 GMT
        Subject: C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=www.sopac.org/Email
=administrator@sopac.org
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:ba:54:2c:ab:88:74:aa:6b:35:a5:a9:c1:d0:5a:
                    9b:fb:6b:b5:71:bc:ef:d3:ab:15:cc:5b:75:73:36:
                    b8:01:d1:59:3f:c1:88:c0:33:91:04:f1:bf:1a:b4:
                    7a:c8:39:c2:89:1f:87:0f:91:19:81:09:46:0c:86:
                    08:d8:75:c4:6f:5a:98:4a:f9:f8:f7:38:24:fc:bd:
                    94:24:37:ab:f1:1c:d8:91:ee:fb:1b:9f:88:ba:25:
                    da:f6:21:7f:04:32:35:17:3d:36:1c:fb:b7:32:9e:
                    42:af:77:b6:25:1c:59:69:af:be:00:a1:f8:b0:1a:
                    6c:14:e2:ae:62:e7:6b:30:e9
                Exponent: 65537 (0x10001)
         X509v3 extensions:
             X509v3 Basic Constraints:
                 CA:FALSE
             Netscape Comment:
                 OpenSSL Generated Certificate
             X509v3 Subject Key Identifier:
                 FE:04:46:ED:A0:15:BE:C1:4B:59:03:F8:2D:0D:ED:2A:E0:ED:F9:2F
             X509v3 Authority Key Identifier:
                 keyid:E6:12:7C:3D:A1:02:E5:BA:1F:DA:9E:37:BE:E3:45:3E:9B:AE:E5
:A6

                 DirName:/C=FJ/ST=Fiji/L=Suva/O=SOPAC/OU=ICT/CN=SOPAC Root CA/E
mail=administrator@sopac.org
                 serial:00

    Signature Algorithm: md5WithRSAEncryption
        34:8d:fb:65:0b:85:5b:e2:44:09:f0:55:31:3b:29:2b:f4:fd:
        aa:5f:db:b8:11:1a:c6:ab:33:67:59:c1:04:de:34:df:08:57:
        2e:c6:60:dc:f7:d4:e2:f1:73:97:57:23:50:02:63:fc:78:96:
        34:b3:ca:c4:1b:c5:4c:c8:16:69:bb:9c:4a:7e:00:19:48:62:
        e2:51:ab:3a:fa:fd:88:cd:e0:9d:ef:67:50:da:fe:4b:13:c5:
        0c:8c:fc:ad:6e:b5:ee:40:e3:fd:34:10:9f:ad:34:bd:db:06:
        ed:09:3d:f2:a6:81:22:63:16:dc:ae:33:0c:70:fd:0a:6c:af:
        bc:5a
-----BEGIN CERTIFICATE-----
MIIDoTCCAwqgAwIBAgIBATANBgkqhkiG9w0BAQQFADCBiTELMAkGA1UEBhMCRkox
DTALBgNVBAgTBEZpamkxDTALBgNVBAcTBFN1dmExDjAMBgNVBAoTBVNPUEFDMQww
CgYDVQQLEwNJQ1QxFjAUBgNVBAMTDVNPUEFDIFJvb3QgQ0ExJjAkBgkqhkiG9w0B
CQEWF2FkbWluaXN0cmF0b3JAc29wYWMub3JnMB4XDTAxMTEyMDA1NDc0NFoXDTAy
MTEyMDA1NDc0NFowgYkxCzAJBgNVBAYTAkZKMQ0wCwYDVQQIEwRGaWppMQ0wCwYD
VQQHEwRTdXZhMQ4wDAYDVQQKEwVTT1BBQzEMMAoGA1UECxMDSUNUMRYwFAYDVQQD
Ew13d3cuc29wYWMub3JnMSYwJAYJKoZIhvcNAQkBFhdhZG1pbmlzdHJhdG9yQHNv
cGFjLm9yZzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAulQsq4h0qms1panB
0Fqb+2u1cbzv06sVzFt1cza4AdFZP8GIwDORBPG/GrR6yDnCiR+HD5EZgQlGDIYI
2HXEb1qYSvn49zgk/L2UJDer8RzYke77G5+IuiXa9iF/BDI1Fz02HPu3Mp5Cr3e2
JRxZaa++AKH4sBpsFOKuYudrMOkCAwEAAaOCARUwggERMAkGA1UdEwQCMAAwLAYJ
YIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1Ud
DgQWBBT+BEbtoBW+wUtZA/gtDe0q4O35LzCBtgYDVR0jBIGuMIGrgBTmEnw9oQLl
uh/anje+40U+m67lpqGBj6SBjDCBiTELMAkGA1UEBhMCRkoxDTALBgNVBAgTBEZp
amkxDTALBgNVBAcTBFN1dmExDjAMBgNVBAoTBVNPUEFDMQwwCgYDVQQLEwNJQ1Qx
FjAUBgNVBAMTDVNPUEFDIFJvb3QgQ0ExJjAkBgkqhkiG9w0BCQEWF2FkbWluaXN0
cmF0b3JAc29wYWMub3JnggEAMA0GCSqGSIb3DQEBBAUAA4GBADSN+2ULhVviRAnw
VTE7KSv0/apf27gRGsarM2dZwQTeNN8IVy7GYNz31OLxc5dXI1ACY/x4ljSzysQb
xUzIFmm7nEp+ABlIYuJRqzr6/YjN4J3vZ1Da/ksTxQyM/K1ute5A4/00EJ+tNL3b
Bu0JPfKmgSJjFtyuMwxw/Qpsr7xa
-----END CERTIFICATE-----

   Comme vous avez pu le remarquer, le certificat mentionne son metteur,
   contient la clef publique de son propritaire, la priode de validit
   du certificat et une signature pour vrifier qu'il n'a pas t
   modifi. Le certificat ne contient PAS la clef prive qui ne doit
   jamais tre rvle. Ce certificat contient tous les lments
   ncessaires pour envoyer un message chiffr  son propritaire ou pour
   vrifier un message dont la signature lui est attribue.
     _________________________________________________________________

1.2.3. La clef symtrique

   Les algorithmes de chiffrement  paire de clefs publique/prive sont
   intressants mais pas toujours pratiques. Ils sont asymtriques parce
   que des clefs diffrentes sont requises au chiffrement et au
   dchiffrement. La mme clef ne peut remplir les deux rles. Les
   algorithmes symtriques actuels sont nettement plus rapides que les
   algorithmes asymtriques. Une clef symtrique est toutefois
   potentiellement peu sre. Il suffit qu'un individu nuisible se la
   procure et il n'y a plus d'information protge. La clef symtrique
   doit donc tre transmise au correspondant sans tre intercepte. Rien
   n'est sr dans l'Internet. La solution consiste  envelopper la clef
   symtrique dans un message chiffr au moyen d'un algorithme
   asymtrique. Comme personne d'autre que vous ne connat la clef
   prive, le message chiffr avec la clef prive est sr (enfin,
   relativement, rien n'est garanti en ce bas monde sinon la mort et les
   impts). La clef de chiffrement symtrique est choisie alatoirement
   de telle sorte qu'une compromission accidentelle n'ait pas d'impact
   sur les transactions futures.
Clef symtrique-->[Clef publique]-->Clef de session chiffre-->[Clef prive]-->
Clef symtrique
     _________________________________________________________________

1.2.4. Les algorithmes de chiffrement

   Diffrents algorithmes existent, symtriques ou non, avec diverses
   longueurs de clef. En principe les algorithmes ne peuvent pas tre
   brevets. Si Henri Poincar l'avait fait, il aurait pu poursuivre
   Albert Einstein ... Les algorithmes ne peuvent donc pas tre brevets,
    l'exception toutefois des tats-Unis. OpenSSL est mis au point dans
   des pays o les algorithmes ne sont pas brevets et o l'usage de la
   cryptographie n'est pas rserv  des agences d'tat pour des fins
   militaires ou d'espionnage. Lors de la ngociation entre le navigateur
   et le serveur web, les applications fournissent l'une  l'autre une
   liste d'algorithmes qu'elles peuvent traiter, classs par ordre de
   prfrence. L'algorithme prfr en commun est choisi. OpenSSL peut
   tre compil sans inclure la gestion de certains algorithmes de faon
    rester utilisable dans des pays o l'usage de la cryptographie est
   rglement.
     _________________________________________________________________

1.2.5. Le hachage

   Un hachage s'obtient par application d'une fonction, dite  sens
   unique,  un message. La fonction prsente cette proprit qu'il n'est
   pas possible de former un message initial  partir du hach. En outre,
   le hach est compltement modifi en cas de changement, mme mineur,
   du message d'origine. Il est donc pratiquement impossible de modifier
   un message  hach constant. Les fonctions de hachage s'emploient dans
   des mcanismes  base de mot de passe, des vrifications d'intgrit
   (MD5) et en gnral pour vrifier que des donnes n'ont pas t
   altres. L'IETF (_Internet Engineering Task Force_) prfre
   apparemment SHA1  MD5 pour diverses raisons techniques (cf RFC2459
   7.1.2 and 7.1.3).
     _________________________________________________________________

1.2.6. La signature

   La signature d'un message consiste  associer une identit  son
   contenu. Le plus souvent il s'agit de prouver qui en est l'auteur mais
   ce n'est pas toujours le cas. Le message peut tre textuel ou tre le
   certificat de quelqu'un d'autre. Pour signer un message, son hach est
   d'abord cr puis ce dernier est chiffr avec la clef prive. Le
   rsultat et votre certificat accompagnent ensuite le message
   d'origine. Le destinataire de l'ensemble recalcule le hach et le
   compare au rsultat du dchiffrement de la signature avec votre clef
   publique suppose. Il vrifie ensuite la validit de votre certificat.

   Ce type de signature permet de transmettre la clef publique et le
   certificat  chaque correspondant.

   Il y a deux faons de signer, soit en incluant le message  la
   signature, soit en chiffrant le message et sa signature. Cette
   dernire forme n'est qu'un chiffrement trs pauvre car n'importe
   quelle application qui dispose de la clef publique peut l'inverser. La
   premire forme permet de passer un contenu textuel  l'utilisateur en
   toute circonstance tandis que la deuxime l'interdit ds que le
   message a t altr.
     _________________________________________________________________

1.2.7. Le mot de passe

   Le mot de passe correspond  un mot de passe originel Unix  ceci prs
   qu'il est normalement plus long que 8 caractres et ne se limite pas
   forcment  un seul mot. De nos jours les systmes Unix utilisent des
   hachs MD5 ou autres qui n'imposent plus de limitation de longueur de
   mot de passe.
     _________________________________________________________________

1.2.8. L'infrastructure de clefs publiques

   L'infrastructure de clefs publiques (PKI/Public Key Infrastructure)
   dsigne le systme de gestion et la base de donnes qui permettent de
   signer les certificats, de tenir  jour une liste de certificats
   rvoquer, de distribuer les clefs publiques, etc. Il est le plus
   souvent accessible via un site web ou un serveur LDAP. Certaines
   entits sont galement charges de vrifier que vous tes bien qui
   vous prtendez tre. On peut avoir recours  une PKI commerciale
   connue dont le certificat racine se trouve dj dans votre
   application. Un problme apparat au niveau du courrier lectronique
   pour lequel vous avez le choix entre l'emploi d'un certificat
   gnrique ou une facturation d'environ 100E par an pour chaque adresse
   lectronique. De plus, il n'y a aucun moyen d'obtenir la clef publique
   de quelqu'un sans avoir reu auparavant de ce correspondant son
   certificat (accompagn de sa clef publique).
     _________________________________________________________________

1.3. Qu'en est-il de S/MIME et des autres protocoles ?

   Bien que SSL ait t mis au point pour les services web, il peut
   s'appliquer au chiffrement de n'importe quel protocole. C'est le cas
   d'IMAPS, de POPS, de SMTPS ... Ces protocoles dupliquent sur un port
   alternatif leur service originel non-scuris. SSL peut galement
   chiffrer n'importe quelle transaction sans qu'elle ait besoin d'tre
   en ligne. S/MIME est construit de cette faon en insrant un message
   chiffr dans un courrier lectronique usuel. Le message est chiffr
   avec la clef publique du destinataire. Si vous n'tes pas en contact
   avec votre correspondant, vous devez connatre sa clef publique, soit
   que vous l'ayez rcupre depuis son site web, depuis un annuaire ou
   qu'il vous l'ait envoye au pralable par courrier lectronique
   accompagne de son certificat (pour s'assurer qu'il s'agit bien de la
   personne souhaite).

   Dans l'autre sens, un navigateur peut transmettre son propre
   certificat au serveur web afin de se faire identifier.
     _________________________________________________________________

Chapitre 2. Gestion des certificats

2.1. Installation

   De nos jours l'installation d'OpenSSL ne soulve gure de difficults.
   Les distributions incluent des gestionnaires de paquets. Reportez-vous
    la documentation de votre distribution ou aux fichiers README et
   INSTALL qu'inclut l'archive tar d'OpenSSL. Ce guide pratique n'a pas
   pour objectif de traiter de l'installation mais de l'utilisation.

   Je dcris quelques options d'installation standard dont la
   connaissance est ncessaire pour les exemples qui suivent. Votre
   installation peut diffrer.

   Les certificats OpenSSL sont stocks dans /var/ssl. Toutes les
   commandes et rpertoires de ce document partent de /var/ssl. Ce n'est
   pas indispensable mais les exemples en sont facilit.

   OpenSSL cherche par dfaut son fichier de configuration dans
   /usr/lib/ssl/openssl.cnf. Ajoutez donc systmatiquement -config
   /etc/openssl.cnf aux commandes telles openssl ca et openssl req (par
   exemple). Je me sers de /etc/openssl.cnf pour maintenir l'ensemble des
   fichiers de configuration dans /etc.

   Les utilitaires et diverses bibliothques se trouvent dans
   /usr/lib/ssl
     _________________________________________________________________

2.1.1. L'utilitaire CA.pl

   Vrifiez que CA.pl se trouve dans un rpertoire qui figure dans le
   chemin d'accs par dfaut aux programmes. Il peut se trouver dans le
   rpertoire /usr/lib/ssl. CA.pl permet de masquer la complexit des
   commandes openssl. Je l'utilise dans tous les exemples en indiquant
   entre crochets l'quivalent openssl.

   Modifiez CA.pl de faon  ce que les appels  openssl ca et openssl
   req incluent l'option -config /etc/openssl.cnf.
#$SSLEAY_CONFIG=$ENV{"SSLEAY_CONFIG"};
$SSLEAY_CONFIG="-config /etc/openssl.cnf";
#$CATOP="./demoCA";
$CATOP="/var/ssl";
     _________________________________________________________________

2.1.2. Le fichier openssl.cnf

   /etc/openssl.cnf doit tre configur de faon  minimiser les donnes
    renseigner  chaque invocation des utilitaires.
#---Begin---
#
# Fichier de configuration pour OpenSSL.
# S'emploie surtout pour les demandes de certificats.
#
# NdT: autre chose que de l'ASCII dans les fichiers de
# configuration me rend nerveux. Il y a donc un zest de triche
# dans ce qui suit. Vous ne voudriez pas me rendre nerveux, non ? :o)
#

RANDFILE  = $ENV::HOME/.rnd
oid_file  = $ENV::HOME/.oid
oid_section  = new_oids

# Section des extension X.509v3 pour se servir du
# fichier avec l'option -extfile de la commande
# "openssl x509"
# extensions  =
# (Variante: employer un fichier de configuration qui
# n'a que des extensions X.509v3 dans sa section
# principale [= default])

[ new_oids ]

# On ajoute des OID pour les commandes 'ca' et 'req'.
# Par exemple:
# testoid1=1.2.3.4
# L'emploi de substitutions est possible:
# testoid2=${testoid1}.5.6

####################################################################
[ ca ]
default_ca = CA_default  # Section de la CA standard

####################################################################

[ CA_default ]
dir             = /var/ssl                # Emplacement de base
certs           = $dir/certs              # Emplacement de stockage des nouveau
x certificats
crl_dir         = $dir/crl                # Emplacement des nouvelles CRL
database        = $dir/index.txt          # Fichier d'index
new_certs_dir   = $dir/newcerts           # Emplacement des nouveaux certificat
s

certificate     = $dir/cacert.pem         # Certificat de la CA
serial          = $dir/serial             # Numero de serie en cours
crl             = $dir/crl.pem            # CRL en cours
private_key     = $dir/private/cakey.pem  # Clef privee
RANDFILE        = $dir/private/.rand      # Fichier d'alea
x509_extensions = usr_cert                # Extensions pour les certificats

# Extensions pour la CRL. Remarque: Netscape communicator n'aime pas les CRL de
 version 2,
# on commente donc pour avoir une CRL version 1
# crl_extensions = crl_ext

default_days    = 365                     # Duree de vie d'un certificat
default_crl_days= 7                       # Intervalle entre CRLs
default_md      = sha1                    # Algorithme de hachage
preserve        = no                      # Conserve-t-on l'ordre du DN ?

# Diverses facons de specifier l'allure des requetes
# Pour une requete de type CA, les attributs doivent etre les memes
# Les champs 'optional' et 'supplied' correspondent respectivement
# a des champs optionnels et fournis :o)
policy  = policy_match

# Typage CA
[ policy_match ]
countryName            = match
stateOrProvinceName    = optional
localityName           = match
organizationName       = match
organizationalUnitName = optional
commonName             = supplied
emailAddress           = optional

# Typage tout-venant
# Tous les types d'objets acceptables doivent etre enumeres
[ policy_anything ]
countryName            = optional
stateOrProvinceName    = optional
localityName           = optional
organizationName       = optional
organizationalUnitName = optional
commonName             = supplied
emailAddress           = optional

####################################################################
[ req ]
default_bits       = 1024
default_keyfile    = privkey.pem
distinguished_name = req_distinguished_name
attributes         = req_attributes
default_md         = sha1
x509_extensions    = v3_ca # Extensions pour un certificat auto-signant

# Mot de passe pour les clefs privees (l'application le demande s'il est vide).
# input_password = secret
# output_password = secret

# Masque pour les types de chaines valides. Plusieurs choix sont possibles.
# default: PrintableString, T61String, BMPString.
# pkix : PrintableString, BMPString.
# utf8only: only UTF8Strings.
# nombstr : PrintableString, T61String (pas de BMPStrings ni de UTF8Strings).
# MASK:XXXX valeur litterale.
# Attention: certaines versions de Netscape plantent sur les BMPStrings ou les
UTF8Strings.
# A utiliser avec prudence!
string_mask = nombstr

# req_extensions = v3_req # Extensions pour une demande de certificat

[ req_distinguished_name ]
countryName         = Nom du pays (code sur 2 lettres)
countryName_default = FJ
countryName_min     = 2
countryName_max     = 2

stateOrProvinceName         = Etat ou province (nom complet)
stateOrProvinceName_default = Fiji

localityName          = Ville
localityName_default  = Suva

0.organizationName         = Organisation (nom de l'entreprise par exemple)
0.organizationName_default = SOPAC

# Possible mais pas normalement pas necessaire :-)
#1.organizationName         = Second nom de l'organization
#1.organizationName_default = World Wide Web SARL

organizationalUnitName         = Nom du departement dans l'organisation
organizationalUnitName_default = ITU

commonName       = Nom d'usage
commonName_max   = 64
emailAddress     = Addresse e-mail
emailAddress_max = 40

# SET-ex3   = SET extension number 3

[ req_attributes ]
challengePassword     = Un mot de passe de challenge
challengePassword_min = 4
challengePassword_max = 20

unstructuredName      = Nom optionnel

[ usr_cert ]

# Extensions ajoutees quand 'ca' signe une requete.
# Contraire aux suggestions PKIX mais des CA le font et certains
# logiciels le demandent pour ne pas confondre un certificat
# utilisateur avec un certificat de CA

basicConstraints=CA:FALSE

# Examples d'utilisation de nsCertType. En cas d'omission,
# le certificat peut servir a tout sauf a signer des objets

# Serveur SSL
# nsCertType   = server

# Certificat promis a signer des objets.
# nsCertType = objsign

# Client normal.
# nsCertType = client, email

# Tout.
# nsCertType = client, email, objsign

# Classique pour un certificat client.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment

# Pour la boiboite de commentaire de Netscape.
nsComment  = "Certificate issued by https://www.sopac.org/ssl/"

# Recommandations PKIX sans effets secondaires facheux.
subjectKeyIdentifier=hash

authorityKeyIdentifier=keyid,issuer:always

# On importe l'adresse e-mail
# pour les attributs subjectAltName et issuerAltname.
# subjectAltName=email:copy

# Informations relatives au sujet.
# issuerAltName=issuer:copy

# Adresse de base des autres URL si on n'en donne pas
# au cas par cas.
nsBaseUrl  = https://www.sopac.org/ssl/

# Adresse de la CRL du moment.
nsCaRevocationUrl = https://www.sopac.org/ssl/sopac-ca.crl

# Adresse pour revoquer un certificat.
nsRevocationUrl  = https://www.sopac.org/ssl/revocation.html?

# Adresse pour renouveller un certificat.
nsRenewalUrl  = https://www.sopac.org/ssl/renewal.html?

# Adresse des pratiques de la CA.
nsCaPolicyUrl  = https://www.sopac.org/ssl/policy.html.

# Adresse du certificat du signataire.
issuerAltName = URI:https://www.sopac.org/ssl/sopac.crt.

# Adresse de la CRL du moment.
crlDistributionPoints = URI:https://www.sopac.org/ssl/sopac-ca.crl

[ v3_ca ]

# Extensions d'une CA standard

# Recommandation PKIX

subjectKeyIdentifier=hash

authorityKeyIdentifier=keyid:always,issuer:always

# Recommandation PKIX que certains bugware n'aiment pas
# basicConstraints = critical,CA:true
# On utilise donc plutot ceci
basicConstraints = CA:true

# Emploi de la clef: typique d'un certificat de CA.
# On le laisse inactif pour prevenir l'emploi d'un
# certificat auto-signant de test.
# keyUsage = cRLSign, keyCertSign

# En fonction des besoins.
# nsCertType = sslCA, emailCA

# On inclut l'adresse e-mail dans le nom alternatif du sujet (recommendation PK
IX)
# subjectAltName=email:copy
# On copie les informations du signataire
# issuerAltName=issuer:copy

# Encodage DER en base 16 d'une extension: licence de pilotage requise!
# 1.2.3.5=RAW:02:03
# On peut surcharger une extension standard:
# basicConstraints= critical, RAW:30:03:01:01:FF

# Message pour la boite d'affichage de Netscape.
nsComment  = "Certificat en provenance de https://www.sopac.org/ssl/"

# Adresse de base des autres URL si on n'en donne pas
# au cas par cas.
nsBaseUrl  = https://www.sopac.org/ssl/

# Adresse de la CRL du moment.
nsCaRevocationUrl = https://www.sopac.org/ssl/sopac-ca.crl

# Adresse pour revoquer un certificat.
nsRevocationUrl  = https://www.sopac.org/ssl/revocation.html?

# Adresse pour renouveller un certificat.
nsRenewalUrl  = https://www.sopac.org/ssl/renewal.html?

# Adresse des pratiques de la CA.
nsCaPolicyUrl  = https://www.sopac.org/ssl/policy.html

# Adresse du certificat du signataire.
issuerAltName = URI:https://www.sopac.org/ssl/sopac.crt

# Adresse de la CRL du moment.
crlDistributionPoints = URI:https://www.sopac.org/ssl/sopac-ca.crl

[ crl_ext ]
# Extensions de CRL
# Seuls issuerAltName et authorityKeyIdentifier se justifient dans une CRL.
# issuerAltName=issuer:copy
authorityKeyIdentifier=keyid:always,issuer:always


#----End----

   Quelques remarques au sujet du fichier openssl.cnf

     * Plusieurs variables se prsentent avec les suffixes _default, _min
       et _max pour leurs valeurs minimales ou leurs nombres minimaux et
       maximaux de caractres respectivement.
     * Le fichier est bas sur des [Sections] de variables.

   dir :
          rpertoire de base.

   default_ca :
          dsigne la section des variables pour un certificat dont le
          type n'est pas spcifi.

   basicConstraints :
          dfinit l'usage du certificat. CA:TRUE dsigne un certificat de
          CA racine par exemple.
     _________________________________________________________________

2.1.3. Cration de l'autorit de certification

   Utilisez la commande suivante aprs avoir modifi de faon adquate le
   fichier openssl.cnf :
   CA.pl -newca

   L'utilitaire demande de choisir un fichier contenant le certificat de
   l'AC ou bien il propose d'en crer un. A titre d'exercice, laissez
   vous guider dans la cration d'une AC. La partie suivante remplace
   cette AC par une AC de dure de vie plus importante. CA.pl ne gnre
   que des certificats valables 365 jours.
     _________________________________________________________________

2.2. Cration d'une autorit de certification racine

   La commande suivante cre un certificat auto-sign (pour une autorit
   de certification donc).
CA.pl -newcert
openssl req -config /etc/openssl.cnf -new -x509 -keyout newreq.pem \
        -out newreq.pem -days 365

   Le nouveau certificat se trouve dans le fichier newreq.pem. Utilisez
   un CN du type  ACME root Certificate . Le fichier est  diviser en
   deux parties, cacert.pem et private/cakey.pem. La partie dlimite par
   -RSA PRIVATE KEY- va dans le fichier private/cakey.pem tandis que la
   partie -CERTIFICATE- est destine au fichier cacert.pem. Supprimez
   newreq.pem une fois l'opration effectue.

   Vrifiez  prsent que le fichier index.txt est vide et que le fichier
   serial contient la valeur 01.

   Afin de ne pas avoir  renouveler tous les certificats mis par une AC
   lorsque son certificat racine expire, il est souhaitable d'augmenter
   la dure de vie de ce dernier. Les autorits de certification
   commerciales emploient des dures de 5  10 ans.
openssl req -config /etc/openssl.cnf -new -x509 -keyout private/cakey.pem \
       -out cacert.pem -days 3650

   La commande prcdente est plus efficace que  CA.pl -newcert  car
   elle place les fichiers crs  l'emplacement souhait et gnre une
   AC racine valable 10 ans.

   Il reste  s'assurer que le certificat auto-sign racine n'est employ
   que pour signer des certificats. La confidentialit de la clef prive
   est trs importante. Ne la compromettez jamais en tant le mot de
   passe. On peut envisager de la ranger sur un support amovible et de
   n'y accder qu'en cas de besoin. Si la machine est compromise, la clef
   prive est ailleurs.

   On dispose maintenant d'une autorit de certification racine. Les
   utilisateurs doivent faire confiance  votre certificat de CA et donc
   le rcuprer et le charger dans leurs navigateurs.

   Il faudra renseigner le mot de passe lors de la signature de chaque
   certificat.
     _________________________________________________________________

2.3. Cration d'une autorit de certification non-racine

   CORRIGEZ-MOI parce que je ne suis pas tout  fait sr de la procdure.

   Un certificat peut tre employ pour en signer un autre pourvu qu'il
   soit valide et ait t autoris  le faire lors de sa cration. On
   peut donc crer une demande de certificat et une clef prive, faire
   signer le certificat par un tiers et installer le certificat sign et
   la clef prive. La partie -PRIVATE KEY- va dans le fichier
   private/cakey.pem tandis que la partie -CERTIFICATE- va dans
   cacert.pem.
     _________________________________________________________________

2.4. Mise en place du certificat de CA racine comme certificat fiable.

   On commence par ter du certificat tout ce qui n'appartient pas  la
   section -CERTIFICATE-.
   openssl x509 -in cacert.pem -out cacert.crt

   On place ensuite le fichier obtenu sur son site web, par exemple
   http://mysite.com/ssl/cacert.crt. Le serveur web doit intgrer une
   description MIME pour les fichiers .crt. Le certificat est prt  tre
   tlcharg et utilis par n'importe quel navigateur.

   Il est important de publier son certificat racine de CA sur un site
   web car il est peu probable que les utilisateurs l'aient dj d'inclus
   dans leur navigateur. Notez que n'importe qui peut imiter votre site
   web et votre certificat de CA racine. Dans la mesure o on dispose de
   plusieurs chemins pour transmettre l'information, il devient fortement
   improbable qu'un attaquant arrive  tout contrler.

   Microsoft propose un service de mise  jour de Windows qui propagera
   votre certificat racine aux programmes Internet Explorer en
   circulation. Contactez Microsoft pour que votre certificat soit ajout
    leur base de donnes et intgr  leurs futurs paquets.
     _________________________________________________________________

2.4.1. Netscape/Mozilla

   On rcupre le certificat depuis le web ou le systme de fichiers avec
   Netscape. Ce dernier identifie automatiquement le fichier comme un
   certificat racine et propose de l'intgrer. Un assistant guide dans
   l'installation. A la fin du processus, on prcise le domaine
   d'application du certificat : scurisation web, signature de courrier
   lectronique ou signature de code.
     _________________________________________________________________

2.4.2. Galeon

   Galeon fonctionne comme Mozilla en ce qu'il repose sur le mme moteur
   de rendu HTML. Il n'inclut toutefois pas d'outil de gestion des
   certificats.
     _________________________________________________________________

2.4.3. Opera

   COMPLTEZ-MOI
     _________________________________________________________________

2.4.4. Internet Explorer

   On commence par aller  l'adresse de tlchargement du certificat
   avant de le sauvegarder en local. L'assistant d'installation de
   certificat est invoqu par double-clic sur le fichier de certificat.
   Internet Explorer installe spontanment les certificats auto-signs
   dans la liste des autorits de certification. A partir de ce point,
   Internet Explorer cesse d'mettre des avertissements et considre
   comme fiables les certificats signs avec ce certificat de CA racine.

   Il est galement possible d'ouvrir le certificat depuis Internet
   Explorer qui en affiche alors le contenu. L'assistant dmarre ensuite
   en appuyant sur le bouton d'installation du certificat.
     _________________________________________________________________

2.5. Gestion des certificats

2.5.1. Cration et signature de demandes de certificats

CA.pl -newreq
(openssl req -config /etc/openssl.cnf -new -keyout newreq.pem \
         -out newreq.pem -days 365)

   La commande prcdente cre une nouvelle clef prive et une demande de
   certificat qu'elle place dans newreq.pem. Pour scuriser un site web,
   par exemple www.sopac.org, on utilise le nom d'usage (CN)
   www.sopac.org. Pour le courrier lectronique de franck@sopac.org, on
   utiliserait franck@sopac.org.
CA.pl -sign
(openssl ca -config /etc/openssl.cnf -policy policy_anything \
         -out newcert.pem -infiles newreq.pem)

   Cette commande signe la demande avec cacert.pem et sauve le certificat
   dans newcert.pem. Le mot de passe de cacert.pem (le certificat de CA)
   est ncessaire. Un fichier newcerts/xx.pem est cr et les fichiers
   index.txt, serial sont mis  jour.

   La clef prive se trouve donc dans la section -PRIVATE KEY- de
   newreq.pem et le certificat dans la section -CERTIFICATE- de
   newcert.pem.

   Une copie de newcert.pem est mise dans le rpertoire newcerts/ et
   l'enregistrement correspondant ajout  index.txt de telle sorte qu'un
   client puisse accder  l'information via un serveur web et vrifier
   l'authenticit du certificat.

   On note que le fichier newreq.pem contient aussi bien la demande de
   certificat que la clef prive. La section -PRIVATE KEY- n'est pas
   ncessaire  la signature et il faut absolument la retirer avant de
   transmettre la demande  quelqu'un d'autre pour qu'il la signe. De
   mme, pour signer une demande de certificat, il suffit d'obtenir la
   section -CERTIFICATE REQUEST-. Il n'y a aucune raison de demander la
   clef prive.
     _________________________________________________________________

2.5.2. Rvocation de certificat

   La commande suivante rvoque un certificat :
   openssl -revoke newcert.pem

   La base de donnes index.txt est modifie en consquence et le
   certificat est annot comme rvoqu. Il reste  rgnrer la liste de
   rvocation des certificats :
   openssl ca -gencrl -config /etc/openssl.cnf -out crl/sopac-ca.crl

   La liste de rvocation (CRL/Certificate Revokation List) doit tre
   rendue publique, par exemple sur un site web.

   Les paramtres crldays, crlhours permettent de prciser la prochaine
   date de mise  jour de la CRL. crlexts spcifie la section du fichier
   openssl.cnf  employer pour crer une CRL de version 2 en place d'une
   CRL de version 1.
openssl ca -gencrl -config /etc/openssl.cnf -crldays 7 \
           -crlexts crl_ext -out crl/sopac-ca.crl
     _________________________________________________________________

2.5.3. Renouvellement d'un certificat

   L'utilisateur transmet son ancienne demande de certificat ou en
   rgnre une nouvelle base sur sa clef prive.

   Il faut alors rvoquer l'ancien certificat et signer la nouvelle
   demande de certificat.

   L'ancien certificat se retrouve en cherchant dans le fichier index.txt
   le nom qualifi (DN) qui correspond  la requte. La procdure de
   rvocation s'effectue ensuite avec le numro de srie <xx> et le
   fichier de certificat cert/<xx>.pem.

   La signature de la nouvelle requte peut tre manuelle pour s'assurer
   que les dates de validit du certificat seront correctes.
openssl ca -config /etc/openssl.cnf -policy policy_anything -out newcert.pem \
-infiles newreq.pem -startdate [now] -enddate [previous enddate+365days]

   [now] et [previous enddate+365days] sont  remplacer par des valeurs
   adquates.
     _________________________________________________________________

2.5.4. Affichage d'un certificat

   L'affichage sous forme textuelle du contenu d'un certificat sous forme
   code s'effectue avec la commande suivante :
   openssl x509 -in newcert.pem -noout -text
     _________________________________________________________________

2.5.5. Le fichier index.txt

   Le fichier index.txt contient les rfrences des certificats crs par
   OpenSSL. Les enregistrements sont annots avec un R pour indiquer que
   le certificat est rvoqu, V qu'il est valide et E qu'il a expir.
     _________________________________________________________________

2.5.6. laborer son service web d'autorit de certification

   tre une autorit de certification implique certaines tches :

    1. publier le certificat de CA racine pour qu'il puisse tre dploy
       dans les applications ;
    2. publier la liste de rvocation ;
    3. afficher le contenu dtaill des certificats, notamment leur
       numro de srie ;
    4. fournir un formulaire de demande de certificats.

   Un serveur web et quelques scripts permettent de raliser toutes ces
   fonctions.

   COMPLTEZ-MOI : code de l'interface web.
     _________________________________________________________________

Chapitre 3. Emploi des certificats avec les applications

3.1. Scurisation des protocoles Internet

3.1.1. mod_ssl (Apache) et les certificats

   Il ne faut jamais se servir du certificat auto-sign de la CA racine
   avec quelque application que ce soit, notamment avec Apache qui oblige
    supprimer le mot de passe de protection de la clef prive.

   On commence par crer et signer une demande de certificat dont le nom
   d'usage (CN) est du type www.mysite.com. On ne conserve que la section
   ---CERTIFICATE --- du certificat.

   La clef doit tre dverrouille en en autorisant l'usage sans devoir
   rentrer le mot de passe. On supprime donc le mot de passe du fichier
   newreq.pem :
   openssl rsa -in newreq.pem -out wwwkeyunsecure.pem

   Comme la clef prive n'est plus protge, on a intrt  savoir ce
   qu'on fait et notamment  vrifier les droits d'accs aux fichiers. Si
   quelqu'un arrive  s'en emparer, le site est compromis. On peut 
   prsent utiliser newcert et wwwkeyunsecure.pem avec Apache.

   On copie wwwkeyunsecure.pem et newcert.pem dans le rpertoire
   /etc/httpd/conf/ssl/ dans les fichiers wwwkeyunsecure.pem et
   wwwcert.crt respectivement.

   On dite ensuite /etc/httpd/conf/ssl/ssl.default-vhost.conf :
----
# Server Certificate:
# SSLCertificateFile doit pointer vers un certificat en PEM.
# Si on verrouille le certificat, un mot de passe est requis.
# kill -HUP demande de nouveau le certificat. On cree un
# certificat de test via `make certificate' lors de la
# compilation.
#SSLCertificateFile conf/ssl/ca.crt
SSLCertificateFile wwwcert.crt
# Clef secrete du serveur:
# A employer lorsque la clef est separee du certificat.
#SSLCertificateKeyFile conf/ssl/ca.key.unsecure
SSLCertificateKeyFile wwwkeyunsecure.pem
----

   On arrte httpd (/etc/rc.d/init.d/httpd stop) puis on vrifie que tous
   les processus ont disparu (killall httpd) avant de relancer le dmon
   (/etc/rc.d/init.d/httpd start).
     _________________________________________________________________

3.1.2. IMAPS et les certificats

   Se reporter au paragraphe  POPS et les certificats  pour davantage
   de dtails.
     _________________________________________________________________

3.1.3. POPS et les certificats

   Un fichier pem pour ipop3sd se cre en gnrant un certificat, en
   dverrouillant la clef prive et et combinant les deux dans le fichier
   /etc/ssl/imap/ipop3sd.pem. Ce dernier fichier correspond 
   l'emplacement attendu par le rpm de la Mandrake 9.0. La mme procdure
   s'applique  imap avec le fichier /etc/ssl/imap/imapsd.pem.

   Le CN doit correspondre au nom auquel le client de messagerie se
   connecte (par exemple mail.xyz.org). Avec MS-Outlook, le nom du
   serveur pop se rentre dans l'onglet  cet effet et on active l'option
    This server requires a secure connection (SSL)  dans les proprits
   avances. Les connexions s'effectuent alors sur le port 995 (imaps).
   Le certificat de la CA doit tre install dans MS Internet Explorer
   pour que le certificat de mail.xyz.org soit valid.
     _________________________________________________________________

3.1.4. Postfix et les certificats

   COMPLTEZ-MOI
     _________________________________________________________________

3.1.5. Stunnel et les certificats

   COMPLTEZ-MOI
     _________________________________________________________________

3.1.6. Cration et signature de clef avec Microsoft Key Manager

   Dans Microsoft Key Manager, on choisit le service pour lequel on
   souhaite crer un certificat, par exemple IMAP (ou WWW). L'assistant
   permet de gnrer une nouvelle clef. Il faut s'assurer de ce que le
   nom qualifi n'est pas identique  celui d'une clef existante. Un nom
   d'usage (CN) tel imap.mycompany.com fait l'affaire. L'assistant sauve
   la demande dans le fichier C:\NewKeyRq.txt. Key Manager indique la
   clef avec un signe qui signale qu'elle n'est pas signe.

   On copie ce fichier dans le rpertoire /var/ssl d'OpenSSL sous le nom
   newreq.pem et on signe la requte comme  l'accoutum.
   CA.pl -sign

   newcert.pem n'est pas intelligible par Key Manager car il contient du
   texte et une section -CERTIFICATE-. Il faut supprimer le texte :
   openssl x509 -in newcert.pem -out newcertx509.pem

   Un diteur remplit galement cette tche.

   newcertx509.pem ne contient plus qu'une section -CERTIFICATE-.

   On recopie newcertx509.pem sur la machine o s'excute Key Manager. Il
   suffit alors de cliquer du bouton droit dessus dans l'application Key
   Manager et de renseigner le mot de passe. La clef est alors
   fonctionnelle.
     _________________________________________________________________

3.2. Scurisation du courrier lectronique

3.2.1. Cration et emploi d'un certificat S/MIME

   Il faut simplement gnrer et signer une demande de certificat avec
   l'adresse lectronique en guise de nom d'usage (CN).

   On peut alors signer un message de test test.txt avec le nouveau
   certificat newcert.pem et la clef newreq.pem :
openssl smime -sign -in test.txt -text -out test.msg -signer newcert.pem -inkey
 newreq.pem

   test.msg peut tre transmis  n'importe qui et cette procdure
   s'applique pour mettre des notes signes ou tout autre document sign
   destin  tre publi lectroniquement.
     _________________________________________________________________

3.2.2. Emploi du certificat S/MIME avec MS Outlook

   Il faut l'importer dans Outlook sous forme de fichier pkcs12. La
   cration du fichier pkcs12 s'effectue comme suit :
CA.pl -pkcs12 "Franck Martin"
(openssl pkcs12 -export -in newcert.pem -inkey newreq.pem \
         -out newcert.p12 -name "Franck Martin")

   Il est possible de lier le certificat de signature au fichier pkcs12 :
openssl pkcs12 -export -in newcert.pem -inkey newreq.pem \
        -certfile cacert.pem -out newcert.p12 -name "Franck Martin"

   Ce certificat contient les clefs prives et publique. Seul le mot de
   passe protge cette dernire. Le fichier ne doit donc pas traner
   n'importe o.

   On suit les menus Tools, Options et Security de MS Outlook. Un clic
   sur le bouton import/export active l'import du fichier pkcs12. Il n'y
   a plus qu' renseigner le mot de passe d'export et l'identit de
   l'utilisateur, "Franck Martin" dans mon cas ( adapter).

   On clique ensuite sur le bouton Settings puis, MS Outlook ayant
   normalement slectionn les choix par dfaut, sur New. Il est alors
   possible d'envoyer des courriers lectroniques signs. La clef
   publique est transmise en mme temps que les messages signs et le
   destinataire est donc en mesure de renvoyer des donnes chiffres.

   Comme le certificat a t gnr  partir d'un certificat auto-sign,
   le chemin de validation ne sera pas valide tant que l'application ne
   connat pas le certificat de l'AC racine. On se reportera  la section
   d'installation du certificat de l'AC racine dans Internet Explorer
   pour la dtail de la marche  suivre.

   Le message est envoy sign/chiffr ou simplement sign en clair. Le
   chiffrement n'en est pas vraiment un dans la mesure o le message
   contient tout le ncessaire pour effectuer le dchiffrement.

   Certaines anciennes versions de MS Outlook pour XP parcourent Internet
   pour vrifier la validit du certificat. Plusieurs secondes peuvent
   alors s'couler avant que le courrier ne soit affich, voire plusieurs
   minutes pour que le hors-temps de MS Outlook ne se dclenche si on
   n'est pas connect en permanence. Ce processus bloque toute la machine
   jusqu' ce que MS Outlook l'ait achev d'une faon ou d'une autre.
     _________________________________________________________________

3.2.3. Emploi du certificat S/MIME avec MS Outlook Express

   COMPLTEZ-MOI
     _________________________________________________________________

3.2.4. Emploi du certificat S/MIME avec Netscape Messenger

   COMPLTEZ-MOI
     _________________________________________________________________

3.2.5. Emploi du certificat S/MIME avec Evolution

   Evolution 1.0 ne gre pas S/MIME mais seulement PGP. La prise en
   charge S/MIME est prvue pour une version ultrieure (d'aprs la base
   de donnes de suivi des bogues d'Evolution). Evolution remarque quand
   mme parfois que le document est sign en clair et l'affiche
   correctement bien qu'il ne puisse en vrifier la validit. Des
   versions antrieures d'Evolution n'assimilaient pas un des trois types
   MIME de signature que MS Outlook emploie hlas assez souvent.
     _________________________________________________________________

3.2.6. Emploi du certificat S/MIME avec Balsa

   COMPLTEZ-MOI
     _________________________________________________________________

3.2.7. Emploi du certificat S/MIME avec KMail

   COMPLTEZ-MOI
     _________________________________________________________________

3.3. Protection des fichiers

3.3.1. WinCrypt

   WinCrypt s'appuie sur l'API de chiffrage de Microsoft pour chiffrer et
   signer les fichiers. Il cre en outre de faon optionnelle une archive
   zip avant la signature. Il dispose d'un frontal pour grer la liste
   des certificats, les parcourir, en installer, en supprimer et choisir
   celui  employer avec WinCrypt.

   La procdure de cration d'un certificat est identique  celle de
   Microsoft Outlook. La mme liste de certificats est utilise par les
   deux applications.

   Un fichier filename.sgn sign avec WinCrypt se vrifie avec la
   commande :
   openssl smime -verify -inform der -in filename.sgn -CAfile cacert.crt

   La commande suivante permet de signer un fichier avec OpenSSL de faon
   compatible :
openssl smime -sign -outform der -nodetach -out filename.sgn \
-signer certificate.pem -in filename.txt

   Pour visualiser l'organisation d'un fichier sign :
   openssl asn1parse -inform der -in filename.sgn
     _________________________________________________________________

3.4. Scurisation des programmes

3.4.1. Micosoft Code

   Il est possible de signer ses programmes et ses applets pour prouver
   qu'on en est l'auteur. Il est important pour les clients de savoir que
   personne n'a modifi le code en y insrant un virus ou un cheval de
   Troie. L'tape de signature ncessite le SDK Microsoft Authenticode.
   Ce dernier est disponible dans la section MSDN du site web de
   Microsoft.

   On gnre un certificat comme  l'accoutum mais avec un nom d'usage
   de la forme  ACME Software Cert . Le certificat doit ensuite tre
   sign par l'autorit de certification et converti au format pkcs12.
CA.pl -newreq
CA.pl -sign
CA.pl -pkcs12 "ACME Software Cert"

   On obtient un fichier newcert.p12 qu'on importe dans la liste des
   certificats en cliquant dessus une fois sous MS Windows.

   Le certificat peut alors servir  signer du code :
signcode -cn "ACME Software cert" -tr 5 -tw 2 -n "My Application" \
-i http://www.acme.com/myapp/ \
-t http://timestamp.verisign.com/scripts/timstamp.dll myapp.exe

   A l'installation et  l'excution de l'application, une boite de
   dialogue apparat sous le nom  My Application  avec le lien point
   par l'argument -i.
     _________________________________________________________________

3.5. IPSec

   IPSec est un nouveau protocole bas sur IP qui autorise les liens
   chiffrs  la demande entre deux machines. La mise en oeuvre d'IPSec
   est obligatoire dans le cadre d'IPv6 et peut tre incorpore dans
   IPv4. Qu'IPSec soit obligatoire pour IPv6 ne signifie pas pour autant
   qu'il est systmatiquement dploy par les administrateurs rseau.
   IPSec n'est pas facile  mettre en oeuvre  cause des mcanismes de
   dploiement automatiques des clefs. Le DNS peut aider mais cette
   mthode n'est pas encore courante. En outre, les autorits de
   certification ne proposent pas d'outils pour un dploiement  grande
   chelle en entreprise.
     _________________________________________________________________

3.5.1. FreeS/WAN

   FreeS/WAN est une souche IPSec renomme pour GNU/Linux. La version
   actuelle (1.9.7) doit tre patche pour grer les certificats X.509v3.
   Une telle version modifie est disponible sur ce site. Certaines
   distributions l'incluent en standard, il est donc conseill de
   commencer par vrifier si c'est le cas pour celle qu'on utilise. Cette
   version prsente l'intrt de permettre l'usage d'OpenSSL pour la
   cration des certificats de FreeS/WAN et des enregistrements CERT du
   DNS. En outre, l'interaction avec la souche IPSec de Microsoft est
   ralisable. On se reportera  la page de Nate's pour davantage
   d'informations.
     _________________________________________________________________

3.5.1.1. Passerelle FreeS/WAN

   On cre un certificat dont le CN correspond au nom de domaine
   compltement qualifi de la passerelle IPSec, par exemple
   host.example.com. Ne pas oublier de signer le certificat. On dispose
   des deux fichiers newcert.pem et newreq.pem. Le fichier newreq.pem
   doit tre dit pour ne plus contenir que la clef prive : on supprime
   tout ce qui n'est pas compris entre les balises --BEGIN RSA PRIVATE
   KEY-- et --END RSA PRIVATE KEY--. Il faut ensuite copier ces fichiers
   sur la passerelle en faisant attention  ce que le transfert soit
   scuris. Les fichiers de configuration de FreeS/WAN se trouvent dans
   le rpertoire /etc/freeswan pour ma distribution.  ajuster suivant
   les cas.
mv newreq.pem /etc/freeswan/ipsec.d/private/host.example.com.key
mv newcert.pem /etc/freeswan/ipsec.d/host.example.com.pem

   On copie le certificat racine dans le rpertoire de configuration de
   FreeS/WAN. Il ne faut copier que le certificat, pas la clef.
   mv cacert.pem /etc/freeswan/ipsec.d/cacerts

   On gnre une liste de rvocation ou on copie l'existante 
   l'emplacement adquat :
   openssl ca -genrcl -out /etc/freeswan/ipsec.d/crls/crl.pem

   Toujours sur la passerelle, on inclut dans le fichier ipsec.secrets la
   ligne ci-dessous :
: RSA host.example.com.key
          "password"

   Le mot de passe est celui qui a servi  crer la paire de clef. On
   configure le fichier ipsec.conf comme suit :
config setup
interfaces=%defaultroute
klipsdebug=none
plutodebug=none
plutoload=%search
plutostart=%search
uniqueids=yes

conn %default
keyingtries=1
compress=yes
disablearrivalcheck=no
authby=rsasig
leftrsasigkey=%cert
rightrsasigkey=%cert

conn roadwarrior-net
leftsubnet=<sous_reseau>/<masque_de_sous_reseau>
also=roadwarrior

conn roadwarrior
right=%any
left%defaultroute
leftcert=host.example.com.pem
auto=add
pfs=yes

   Comme on peut le voir, deux liens sont tablis, l'un avec la
   passerelle, l'autre avec le rseau situ derrire la passerelle. Ceci
   s'avre trs pratique si un pare-feu ou un traducteur d'adresses est
   actif sur la passerelle. La configuration autorise tout propritaire
   d'un certificat valide  se connecter  la passerelle.
     _________________________________________________________________

3.5.1.2. Client FreeS/WAN

   La procdure est semblable. Il faut crer un certificat dont le CN
   correspond au nom de domaine compltement qualifi de l'hte, par
   exemple clienthost.example.com. Le certificat doit tre sign par la
   mme autorit de certification que la passerelle. Le lien est alors
   autoris.

   Comme pour la passerelle, on copie de faon scurise les fichiers
   suivants dans les rpertoires de configuration :
mv newreq.pem /etc/freeswan/ipsec.d/private/clienthost.example.com.key
mv newcert.pem /etc/freeswan/ipsec.d/clienthost.example.com.pem

   On copie le certificat racine dans le rpertoire de configuration de
   FreeS/WAN. Il ne faut copier que le certificat, pas la clef.
   mv cacert.pem /etc/freeswan/ipsec.d/cacerts

   On gnre une liste de rvocation ou on copie l'existante 
   l'emplacement adquat :
   openssl ca -genrcl -out /etc/freeswan/ipsec.d/crls/crl.pem

   Enfin, on copie le certificat (mais pas la clef prive) de la
   passerelle :
   mv host.example.com.pem /etc/fresswan/ipsec.d/host.example.com.pem

   Le fichier ipsec.secrets est dit de la mme faon pour charger la
   clef prive :
: RSA clienthost.example.com.key
        "password"

   On dite le fichier ipsec.conf pour activer la connexion :
config setup
interfaces=%defaultroute
klipsdebug=none
plutodebug=none
plutoload=%search
plutostart=%search
uniqueids=yes

conn %default
keyingtries=0
compress=yes
disablearrivalcheck=no
authby=rsasig
leftrsasigkey=%cert
rightrsasigkey=%cert

conn roadwarrior-net
left=(ip of host)
leftsubnet=(gateway_host_subnet)/(gateway_host_netmask)
also=roadwarrior

conn roadwarrior
left=(ip of host)
leftcert=host.example.com.pem
right=%defaultroute
rightcert=clienthost.example.com.pem
auto=add
pfs=yes

   On met ensuite le VPN en action :
ipsec auto --up roadwarrior
ipsec auto --up roadwarrior-net

   Afin que le lien s'tablisse automatiquement, on remplace dans le
   fichier de configuration la directive  auto=add  par  auto=start .
     _________________________________________________________________

3.5.1.3. Client MS Windows 2000/XP

   La procdure est identique  celle du client FreeS/WAN. On cre un
   certificat, par exemple pour winhost.example.com, qui doit  prsent
   tre converti au format pkcs12. On se reportera  la section  MS
   Outlook et les certificats  pour le dtail de la marche  suivre. On
   s'assure de ce que le fichier .p12 est attach au certificat de
   l'autorit de certification racine.

   On note le rsultat de la commande :
   openssl x509 -in cacert.pem -noout -subject

   Ce fichier doit tre copi de faon scurise sur la machine MS
   Windows.

   On installe  prsent l'utilitaire ipsec.exe de Marcus Muller, par
   exemple dans le rpertoire c:\ipsec.

   On ouvre la console de gestion Microsoft (Microsoft Management
   Console/MMC) puis on clique sur  Add/Remove Snap-in ,  Add ,
    Certificates ,  Add ,  Computer Account  et  Next . On
   choisit alors  Local computer  et  Finish . Dans  IP Security
   Policy Management , choisir  Add ,  Local Computer  puis
    Finish ,  Close  et enfin  OK .

   On peut  prsent ajouter le certificat .p12.

   On clique sur la flche d'ajout pour  Certificates (Local Computer) 
   puis avec le bouton droit sur  Personal  avant de cliquer sur  All
   Tasks ,  Import  et  Next . On renseigne ensuite le chemin
   d'accs au fichier .p12 (ou on navigue pour atteindre le fichier) et
   on clique sur  Next . On rentre alors le mot de passe de protection
   du fichier puis on clique sur  Next . On choisit  Automatically
   select the certificate store based on the type of certificate ,
    Next ,  Finish  et on rpond positivement  toutes les questions
   qui se prsentent. On sort de la console et on enregistre la squence
   correspondante dans un fichier pour ne pas avoir  se la farcir 
   chaque fois.

   On installe ipsecpol.exe (Windows 2000) ou ipseccmd.exe (Windows XP)
   comme indiqu dans la documentation de l'utilitaire ipsec. On dite le
   fichier ipsec.conf de la machine MS Windows en remplaant "RightCA"
   par la sortie de la commande  openssl x509 -in cacert.pem -noout
   -subject ; mise en forme comme indiqu ci dessous (il faut remplacer
   les / par des virgules et changer le nom de quelques champs comme
   indiqu dans l'exemple) :
conn roadwarrior
left=%any
right=(ip_du_systeme_distant)
rightca="C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=SOPAC Root"
network=auto
auto=start
pfs=yes

conn roadwarrior-net
left=%any
right=(ip_du_systeme_distant)
rightsubnet=(sous_reseau)/(masque_de_sous_reseau)
rightca="C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=SOPAC Root"
network=auto
auto=start
pfs=yes

   On dmarre  prsent le lien.

   Pour cela on invoque la commande  ipsec.exe . Voici un exemple de
   sortie de cette commande :
C:\ipsec>ipsec
IPSec Version 2.1.4 (c) 2001,2002 Marcus Mueller
Getting running Config ...
Microsoft's Windows XP identified
Host name is: (local_hostname)
No RAS connections found.
LAN IP address: (local_ip_address)
Setting up IPSec ...

Deactivating old policy...
Removing old policy...

Connection roadwarrior:
MyTunnel : (local_ip_address)
MyNet : (local_ip_address)/255.255.255.255
PartnerTunnel: (ip_of_remote_system)
PartnerNet : (ip_of_remote_system)/255.255.255.255
CA (ID) : C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=SOPAC Root...
PFS : y
Auto : start
Auth.Mode : MD5
Rekeying : 3600S/50000K
Activating policy...

Connection roadwarrior-net:
MyTunnel : (local_ip_address)
MyNet : (local_ip_address)/255.255.255.255
PartnerTunnel: (ip_of_remote_system)
PartnerNet : (remote_subnet)/(remote_netmask)
CA (ID) : C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=SOPAC Root...
PFS : y
Auto : start
Auth.Mode : MD5
Rekeying : 3600S/50000K
Activating policy...
C:\ipsec>

   On met un ping vers la passerelle qui devrait afficher  Negotiating
   IP Security  pendant quelques instants avant de rpondre au ping.
   Pour une T1 qui attaque un VPN derrire un modem cable, il s'coule
   typiquement de trois  quatre pings. Une fois la mme chose faite
   depuis le rseau interne  l'autre extrmit du lien, ce dernier
   devrait tre oprationnel.
     _________________________________________________________________

Chapitre 4. PKI Globale

4.1. PKIs existantes

   Aujourd'hui on a le choix entre avoir recours  une PKI commerciale ou
   utiliser la sienne. Les PKI commerciales ont t cres  l'origine
   pour permettre le commerce lectronqiue via Internet et plus
   particulirement sur le web. Le prix des certificats dpendait du
   nombre d'htes. Le prix est plus lev que pour un nom de domaine
   parce que les cots d'identification des demandeurs sont plus levs
   et parce qu'il n'y a pas de raison de se priver d'un pourcentage sur
   l'activit des sites marchands. Etrangement ce type de vision atteint
   assez vite ses limites quand il ne s'agit plus seulement de scuriser
   quelques serveurs, fussent-ils POP ou IMAP, mais que chaque hte a
   besoin de son certificat quand ce n'est pas chaque utilisateur ou
   chaque application. Le cot s'envole avec l'espoir d'un systme un
   tant soit peu administrable.

   Pourquoi ne pas voir un certificat pour signer tous les autres ? Pour
   l'instant la seule solution consiste  construire sa propre autorit
   de certification, ce qui permet une gestion souple mais limite la
   porte du procd  l'organisation qui y a recours. Le reste du monde
   doit rcuprer des clefs d'autorits de certification racine au cas
   par cas.

   La solution consiste en une PKI unique gre par une entit centrale
   de faon analogue au DNS. On parle alors de PKI globale.
     _________________________________________________________________

4.2. Le besoin d'une PKI globale

   La scurit des ordinateurs personnels est devenu un sujet d'une telle
   importance aujourd'hui que Bill Gates a annonc que Microsoft
   choisirait  prsent la scurit aux fonctionnalits si la dcision
   devait tre prise (NdT : il _peut_ le dire).

   Le nombre de nuisibles sur l'Internet a augment. N'importe qui peut
   envoyer n'importe quoi n'importe o et essayer de faire installer
   diverses saloperies sur les machines des autres. Une fois tout le
   monde identifi, on sait au moins de qui se plaindre en cas de
   problme. C'est particulirement vrai dans le cas du courrier
   non-sollicit pour lequel il est souvent difficile d'authentifier
   l'metteur d'origine. Le traitement d'une donne peut tre diffrent
   si elle n'est pas traable au moyen d'un certificat. Il s'agit de la
   mme approche que celle de la prsentation du numro d'appel
   tlphonique. Les certificats X.509v3 l'autorisent pour toutes les
   applications sur Internet, pour le courrier lectronique (S/MIME), les
   transactions commerciales (HTTPS), les installations de logiciel ...
   Ils ne sont toutefois pas trs rpandus en raison de leur cot quand
   il faut les dployer  grande chelle. Combien d'utilisateurs de Yahoo
   mail, d'Hotmail, de CA Online peuvent s'offrir un certificat
   lectronique ? Il existe des projets de certificats gratuits mais ils
   ne peuvent prouver que l'existence d'une adresse lectronique et n'ont
   pas les moyens de garantir l'identit de leur propritaire.

   Une PKI Globale est ncessaire. Les protocoles et les standards
   existent sans qu'il y ait besoin de rinventer la roue. L'IETF dispose
   de l'outillage ncessaire. Un serveur LDAP peut stocker les
   certificats, le DNS les annoncer et S/MIME scuriser les courriers. Il
   ne reste plus qu'un problme de politique : quels services doivent
   cooprer au sein d'une PKI globale, qui doit offrir un tel service,
   quel sera le niveau de scurit offert ?

   Cette partie sera tenue  jour au fur et  mesure de l'avancement des
   travaux du groupe de travail PKI de l'Internet Society. L'ISOC gre
   galement le TLD .org et dispose donc de moyens pour s'attaquer au
   problme du spam.
