<!DOCTYPE book  PUBLIC "-//OASIS//DTD DocBook V4.1//EN" [
<!ENTITY howto         "http://www.traduc.org/docs/HOWTO/lecture/">
<!ENTITY mini-howto    "http://www.traduc.org/docs/HOWTO/mini/lecture/">
]>

<book lang="fr">
  <!--
    DocBook file was created by LyX 1.2
    See http://www.lyx.org/ for more information
  -->
<bookinfo>
  <title>Guide pratique des certificats SSL</title>
  <subtitle>Version française du <foreignphrase>SSL Certificates 
  HOWTO</foreignphrase></subtitle>
  <releaseinfo>v0.5.fr.1.0</releaseinfo>
  <pubdate>28 février 2003</pubdate>

  <author>
    <firstname>Franck</firstname>
    <surname>Martin</surname>
  </author>

  <othercredit role="traduction">
    <firstname>François</firstname>
    <surname>Romieu</surname>
    <affiliation>
      <jobtitle>Traduction française</jobtitle>
      <address><email>francois@ueimor.eu.org</email></address>
    </affiliation>
    <contrib>Traduction française</contrib>
  </othercredit>

  <othercredit role="relecture">
    <firstname>Pierre</firstname>
    <surname>Machard</surname>
    <affiliation>
      <jobtitle>Relecture de la version française</jobtitle>
      <address><email>pmachard@tuxfamily.org</email></address>
    </affiliation>
    <contrib>Relecture de la version française</contrib>
  </othercredit>

  <revhistory>
    <revision>
      <revnumber>v0.5.fr.1.0</revnumber>
      <date>2003-02-28</date>
      <authorinitials>FR</authorinitials>
      <revremark>
        Traduction française de François Romieu. Relecture de Pierre 
        Machard. Traduction de la licence et quelques retouches de 
        Jean-Philippe Guérard &lt;jean-philippe.guerard@laposte.net&gt;.
      </revremark>
    </revision>
    <revision>
      <revnumber>v0.5</revnumber>
      <date>2002-10-20</date>
      <authorinitials>FM</authorinitials>
      <revremark>
        Ajout des information de Nate Carlson 
        &lt;natecars@natecarlson.com&gt; sur IPsec &mdash; Ajout des 
        informations de Bill Shirley &lt;webnut@telocity.com&gt; sur 
        IMAPS et POPS &mdash; Ajout des informations de Colin McKinnon 
        &lt;colin@wew.co.uk&gt; sur WinCrypt.
      </revremark>
    </revision>
    <revision>
      <revnumber>v0.4</revnumber>
      <date>2002-06-22</date>
      <authorinitials>FM</authorinitials>
      <revremark>
        Corrections diverses&nbsp;&mdash; ajout d'illustrations en 
        ASCII
      </revremark>
    </revision>
    <revision>
      <revnumber>v0.3</revnumber>
      <date>2002-05-09</date>
      <authorinitials>FM</authorinitials>
      <revremark>
        Ajout d'informations sur les extensions 
        x509v3&nbsp;&mdash; Corrections de fautes
      </revremark>
    </revision>
    <revision>
      <revnumber>v0.2</revnumber>
      <date>2001-12-06</date>
      <authorinitials>FM</authorinitials>
      <revremark>
        Ajout du fichier openssl.cnf &mdash; Ajout d'information sur CRL 
        de la part d'Averroes &lt;a.averroes@libertysurf.fr&gt; &mdash; 
        Corrections de fautes
      </revremark>
    </revision>
    <revision>
      <revnumber>v0.1</revnumber>
      <date>2001-11-18</date>
      <authorinitials>FM</authorinitials>
      <revremark>Création du guide pratique</revremark>
    </revision>
  </revhistory>

  <abstract>
    <para>
      Une expérience de gestion d'une autorité de certification. La création
      et la signature de certificats destinés à la sécurisation des
      transactions web, au courrier, à la signature du code et à d'autres
      usages.
    </para>
  </abstract>
</bookinfo>

<chapter>
  <title>Principes généraux</title>
  <sect1>
    <title>Introduction</title>
    <para>
      Comme moi, vous avez sûrement lu avec attention les pages de manuel
      des applications fournies par le projet
      <ulink url="http://www.openssl.org/">OpenSSL</ulink> et, comme moi
      autrefois, vous ne voyez pas trop par où commencer ni comment
      travailler de façon sécurisée avec des certificats. Ce document
      répond à l'essentiel de vos questions.
    </para>
    <para>
      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&nbsp;&hellip; Toutes les applications ne figurent pas 
      ici. Envoyez moi donc s'il vous plaît vos ajouts et corrections. 
      On peut me contacter en anglais à l'adresse suivante&nbsp;: 
      <email>franck@sopac.org</email>.
    </para>
    <para>
      La version originale de ce guide pratique est publié via le <ulink 
      url="http://www.tldp.org/">Projet de documentation Linux</ulink>. 
      Vous y trouverez la dernière version originale de ce document. 
    </para>
    <para>
      La version française de ce document est publiée par le projet de 
      traduction <ulink url="http://www.traduc.org">traduc.org</ulink>. 
      Vous y trouverez notamment la dernière <ulink 
      url="&howto;SSL-Certificates-HOWTO.html">version française</ulink> 
      de ce document.
    </para>
    <sect2 id="copyright">
      <title>Droits d'utilisation et limitation de 
             responsabilité</title>
      <para>
	Ce document est distribué dans l'espoir qu'il se révélera utile, 
	mais SANS AUCUNE GARANTIE&nbsp; sans même la garantie implicite 
	qu'il soit PROPRE À LA VENTE ou ADAPTÉ À UN BESOIN PARTICULIER.
      </para>
      <para>
        En résumé, si les conseils qui vous sont prodigués ici 
        annihilent la sécurité de votre application de commerce 
        électronique, eh bien, tant pis pour vous&nbsp;&mdash; ce n'est 
        jamais de notre faute. Désolé.
      </para>
      <para>
        Copyright &copy; 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 <ulink 
        url="http://www.gnu.org/">GNU</ulink> (GFDL). Une version 
        française officieuse de la version 1.1 de cette licence est 
        disponible sur <ulink
        url="http://www.linux-france.org/prj/jargonf/general/gfdl.html"></ulink>.
      </para>
      <para>
        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 créer des travaux 
        dérivés de celui-ci et les distribuer si vous respectez les 
        conditions suivantes&nbsp;:
      </para>
      <orderedlist>
        <listitem><para>
          Faire parvenir vos travaux dérivés (dans le format le plus 
          approprié tel que SGML) au Projet de documentation Linux 
          (<ulink url="http://www.tldp.org">LDP</ulink>), ou à un projet 
          du même 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.
        </para></listitem>
        <listitem><para>
          Diffuser vos travaux dérivés sous la même licence, ou sous la 
          licence publique GNU (GPL). Inclure la notice précisant les 
          droits d'utilisation, et au moins un pointeur sur la licence 
          utilisée.
        </para></listitem>
        <listitem><para>
          Reconnaître la contribution des précédents auteurs et 
          contributeurs principaux. Si vous envisagez de réaliser un 
          travail dérivé autre qu'une traduction, il vous est demandé 
          d'en discuter au préalable avec le responsable actuel de ce 
          document.
        </para></listitem>
      </orderedlist>
      <para>
        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'<emphasis>évaluation</emphasis>&nbsp;:-). Vous voudrez 
        peut-être également m'envoyer quelque chose pour assaisonner mes 
        épinards&nbsp;;-)
      </para>
    </sect2>
    <sect2>
      <title>Disclaimer and Licence</title>
      <note><para>
        La licence de ce document nous oblige à inclure une copie en 
        anglais de ce texte. La version française de ce texte se 
        trouve à la section précédente.
      </para></note>
      <para>
	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.
      </para>
      <para>
        In short, if the advises given here break the security of your 
        e-commerce application, then tough luck- it's never our fault. 
        Sorry.
      </para>
      <para>
        Copyright &copy; 2001 by Franck Martin and others from the 
        openssl-users mailing list under GFDL (the <ulink 
        url="http://www.gnu.org/">GNU</ulink> Free Documentation 
        License).
      </para>
      <para>
        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:
      </para>
      <orderedlist>
        <listitem><para>
          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.
        </para></listitem>
        <listitem><para>
          License the derivative work with this same license or use GPL. 
          Include a copyright notice and at least a pointer to the 
          license used.
        </para></listitem>
        <listitem><para>
          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.
        </para></listitem>
      </orderedlist>
      <para>
        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 ;-)
      </para>
    </sect2>
    <sect2>
      <title>Pré-requis</title>
      <para>
        Comme indiqué dans l'introduction, ce document est un aide-mémoire et
        vous devez donc consulter les pages de manuel du paquet OpenSSL.
        La lecture de documents relatifs à la sécurité est vivement conseillée
        afin de comprendre comment votre sécurité peut être compromise.
        Les certificats sont destinés à améliorer la sécurité des transactions
        et il donc important que vous compreniez les implications de vos actes
        en terme de sécurité ainsi que les limitations d'OpenSSL.
      </para>
    </sect2>
  </sect1>
  <sect1>
    <title>Que sont SSL et les certificats&nbsp;?</title>
    <para>
      Le protocole SSL (<emphasis>Secure Socket Layer</emphasis>) a été 
      créé par Netscape pour sécuriser les transactions entre les 
      serveur web et les outils de navigation. Il a recours à un tiers, 
      l'autorité de certification (<emphasis>CA/Certificate 
      Authority</emphasis>) qui identifie n'importe laquelle des
      extrémités ou les deux. Il s'agit du fonctionnement en très résumé.
    </para>
    <orderedlist>
      <listitem><para>
        Un navigateur demande une page web sécurisée (en général https://).
      </para></listitem>
      <listitem><para>
        Le serveur web émet sa clef publique accompagnée de son certificat.
      </para></listitem>
      <listitem><para>
        Le navigateur vérifie que le certificat a été émis par un tiers fiable
        (en général une autorité de certification racine), qu'il est toujours
        valide et qu'il se rapporte bien au site en cours.
      </para></listitem>
      <listitem><para>
        Le navigateur emploie la clef publique du serveur pour chiffrer une
        clef de chiffrement symétrique aléatoire et l'envoie au serveur web
        avec l'URL demandée et diverses données HTTP chiffrées.
      </para></listitem>
      <listitem><para>
        Le serveur web déchiffre la clef de chiffrement symétrique grâce à sa
        sa clef privée et utilise la clef de chiffrement symétrique pour
        récupérer l'URL et les données HTTP.
      </para></listitem>
      <listitem><para>
        Le serveur renvoie le document html et les données HTTP chiffrées avec
        la clef symétrique.
      </para></listitem>
      <listitem><para>
        Le navigateur déchiffre l'ensemble avec la clef symétrique et affiche les
        informations.
      </para></listitem>
    </orderedlist>
    <para>
      Plusieurs concepts méritent d'être assimilés.
    </para>
    <sect2>
      <title>Clef publique&nbsp;/ clef privée</title>
      <para>
        Le chiffrement à base de clef publique garantit qu'une donnée
        chiffrée par une clef, publique ou privée, ne peut être
        déchiffrée que par la clef associée. Cela peut paraître surprenant
        mais croyez moi, ça fonctionne. Les clefs sont de même nature et
        leurs rôles peuvent être inversés&nbsp;: ce que l'une chiffre est
        déchiffrable par l'autre. La paire de clef repose sur des nombres
        premiers et leur longueur, exprimée en digits binaires, traduit la
        difficulté qu'il y a à déchiffrer un message sans connaissance à
        priori de la clef nécessaire. L'astuce consiste à conserver une
        clef secrète (la clef privée) 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 déchiffrer 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 privée&nbsp;: seule la clef publique
        correspondante le déchiffrera. Notez que le message n'est pas
        protégé parce que vous le signez. Tout le monde a accès à la clef
        de déchiffrement, ne l'oubliez pas.
      </para>
      <para>
        Le problème consiste à obtenir la clef publique du correspondant.
        En général, vous lui demanderez de la transmettre via un message
        signé qui la contiendra accompagnée d'un certificat.
      </para>
<programlisting>
Message-->[Clef publique]-->Message chiffré-->[Clef privée]-->Message
</programlisting>
    </sect2>
    <sect2>
      <title>Le certificat</title>
      <para>
        Qu'est-ce qui vous garantit que vous dialoguez bien avec la bonne
        personne ou le bon site web&nbsp;? En principe, quelqu'un aura fait
        l'effort (s'il est sérieux) de vérifier que les propriétaires du
        site sont bien ceux qu'ils affirment être. On fait naturellement
        confiance à ce quelqu'un&nbsp;: son certificat, un certificat racine, est
        incorporé à votre navigateur. Un certificat contient des informations
        relatives à son propriétaire comme une adresse électronique, un nom,
        l'usage prévu du certificat, une durée de validité, un identifiant
        de localisation ou un nom qualifié (<emphasis>DN/Distinguished 
        Name</emphasis>) qui comprend le nom d'usage 
        (<emphasis>CN/Common Name</emphasis>) et l'identifiant du
        signataire du certificat. Le certificat comprend également la
        clef publique et un haché pour garantir l'intégrité du message.
        Comme vous avez décidé de faire confiance au signataire du
        certificat, vous accordez du crédit à son contenu.
        On parle d'arbre de confiance de certification ou de chemin de
        certification. En général, le navigateur et les applications
        incluent d'office le certificat racine d'autorités de certification
        bien connues. L'autorité de certification tient à jour une liste des
        certificats signés ainsi qu'une liste des certificats révoqués.
        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-même. On parle alors de certificat auto-signé. Tous les
        certificats de CA racines sont ce type.
      </para>
<programlisting>
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/Email=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-----
</programlisting>
      <para>
        Comme vous avez pu le remarquer, le certificat mentionne son
        émetteur, contient la clef publique de son propriétaire, la période
        de validité du certificat et une signature pour vérifier qu'il n'a
        pas été modifié. Le certificat ne contient PAS la clef privée qui
        ne doit jamais être révélée. Ce certificat contient tous les éléments
        nécessaires pour envoyer un message chiffré à son propriétaire ou
        pour vérifier un message dont la signature lui est attribuée.
      </para>
    </sect2>
    <sect2>
      <title>La clef symétrique</title>
      <para>
        Les algorithmes de chiffrement à paire de clefs publique/privée
        sont intéressants mais pas toujours pratiques. Ils sont
        asymétriques parce que des clefs différentes sont requises au
        chiffrement et au déchiffrement. La même clef ne peut remplir
        les deux rôles. Les algorithmes symétriques actuels sont
        nettement plus rapides que les algorithmes asymétriques. Une clef
        symétrique est toutefois potentiellement peu sûre. Il suffit qu'un 
        individu
        nuisible se la procure et il n'y a plus d'information protégée.
        La clef symétrique doit donc être transmise au correspondant sans
        être interceptée. Rien n'est sûr dans l'Internet. La solution
        consiste à envelopper la clef symétrique dans un message chiffré
        au moyen d'un algorithme asymétrique. Comme personne d'autre que
        vous ne connaît la clef privée, le message chiffré avec la clef
        privée est sûr (enfin, relativement, rien n'est garanti en ce bas
        monde sinon la mort et les impôts). La clef de chiffrement
        symétrique est choisie aléatoirement de telle sorte qu'une
        compromission accidentelle n'ait pas d'impact sur les transactions
        futures.
      </para>
<programlisting>
Clef symétrique-->[Clef publique]-->Clef de session chiffrée-->[Clef privée]-->Clef symétrique
</programlisting>
    </sect2>
    <sect2>
      <title>Les algorithmes de chiffrement</title>
      <para>
        Différents algorithmes existent, symétriques ou non, avec
        diverses longueurs de clef. En principe les algorithmes ne
        peuvent pas être brevetés. Si Henri Poincaré l'avait fait, il
        aurait pu poursuivre Albert Einstein&nbsp;&hellip; Les algorithmes ne
        peuvent donc pas être brevetés, à l'exception toutefois des
        États-Unis. OpenSSL est mis au point dans des pays où les
        algorithmes ne sont pas brevetés et où l'usage de la cryptographie
        n'est pas réservé à des agences d'état pour des fins militaires
        ou d'espionnage. Lors de la négociation entre le navigateur et le
        serveur web, les applications fournissent l'une à l'autre une liste
        d'algorithmes qu'elles peuvent traiter, classés par ordre de
        préférence. L'algorithme préféré en commun est choisi. OpenSSL peut
        être compilé sans inclure la gestion de certains algorithmes de
        façon à rester utilisable dans des pays où l'usage de la
        cryptographie est réglementé.
      </para>
    </sect2>
    <sect2>
      <title>Le hachage</title>
      <para>
        Un hachage s'obtient par application d'une fonction, dite à
        sens unique, à un message. La fonction présente cette propriété
        qu'il n'est pas possible de former un message initial à partir
        du haché. En outre, le haché est complètement modifié
        en cas de changement, même mineur, du message d'origine. Il est
        donc pratiquement impossible de modifier un message à haché
        constant. Les fonctions de hachage s'emploient dans des
        mécanismes à base de mot de passe, des vérifications d'intégrité
        (MD5) et en général pour vérifier que des données n'ont pas été
        altérées. L'IETF (<emphasis>Internet Engineering Task Force</emphasis>) préfère
        apparemment SHA1 à MD5 pour diverses raisons techniques (cf
        RFC2459 7.1.2 and 7.1.3).
      </para>
    </sect2>
    <sect2>
      <title>La signature</title>
      <para>
        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 privée. Le résultat et
        votre certificat accompagnent ensuite le message d'origine.
        Le destinataire de l'ensemble recalcule le haché et le
        compare au résultat du déchiffrement de la signature avec
        votre clef publique supposée. Il vérifie ensuite la validité
        de votre certificat.
      </para>
      <para>
        Ce type de signature permet de transmettre la clef publique
        et le certificat à chaque correspondant.
      </para>
      <para>
        Il y a deux façons de signer, soit en incluant le message à la
        signature, soit en chiffrant le message et sa signature. Cette
        dernière forme n'est qu'un chiffrement très pauvre car n'importe
        quelle application qui dispose de la clef publique peut
        l'inverser. La première forme permet de passer un contenu textuel
        à l'utilisateur en toute circonstance tandis que la deuxième
        l'interdit dès que le message a été altéré.
      </para>
    </sect2>
    <sect2>
      <title>Le mot de passe</title>
      <para>
        Le mot de passe correspond à un mot de passe originel Unix à ceci
        près qu'il est normalement plus long que 8 caractères et ne se
        limite pas forcément à un seul mot. De nos jours les systèmes Unix
        utilisent des hachés MD5 ou autres qui n'imposent plus de
        limitation de longueur de mot de passe.
      </para>
    </sect2>
    <sect2>
      <title>L'infrastructure de clefs publiques</title>
      <para>
        L'infrastructure de clefs publiques (PKI/Public Key
        Infrastructure) désigne le système de gestion et la base de
        données qui permettent de signer les certificats, de tenir à
        jour une liste de certificats révoquer, de distribuer les clefs
        publiques, etc. Il est le plus souvent accessible via un site
        web ou un serveur LDAP. Certaines entités sont également chargées
        de vérifier que vous êtes bien qui vous prétendez être. On
        peut avoir recours à une PKI commerciale connue dont le
        certificat racine se trouve déjà dans votre application. Un
        problème apparaît au niveau du courrier électronique pour lequel
        vous avez le choix entre l'emploi d'un certificat générique 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 reçu auparavant de ce
        correspondant son certificat (accompagné de sa clef publique).
      </para>
    </sect2>
  </sect1>
  <sect1>
    <title>Qu'en est-il de S/MIME et des autres protocoles&nbsp;?</title>
    <para>
      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&nbsp;&hellip; Ces protocoles dupliquent sur
      un port alternatif leur service originel non-sécurisé. SSL peut
      également chiffrer n'importe quelle transaction sans qu'elle ait
      besoin d'être en ligne. S/MIME est construit de cette façon en
      insérant 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
      connaître sa clef publique, soit que vous l'ayez récupérée depuis
      son site web, depuis un annuaire ou qu'il vous l'ait envoyée au
      préalable par courrier électronique accompagnée de son
      certificat (pour s'assurer qu'il s'agit bien de la personne
      souhaitée).
    </para>
    <para>
      Dans l'autre sens, un navigateur peut transmettre son propre
      certificat au serveur web afin de se faire identifier.
    </para>
  </sect1>
</chapter>
<chapter>
  <title>Gestion des certificats</title>
  <sect1>
    <title>Installation</title>
    <para>
      De nos jours l'installation d'OpenSSL ne soulève guère de
      difficultés. 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.
    </para>
    <para>
      Je décris quelques options d'installation standard dont la
      connaissance est nécessaire pour les exemples qui suivent.
      Votre installation peut différer.
    </para>
    <para>
      Les certificats OpenSSL sont stockés dans /var/ssl. Toutes
      les commandes et répertoires de ce document partent de 
      /var/ssl. Ce n'est pas indispensable mais les exemples en sont
      facilité.
    </para>
    <para>
      OpenSSL cherche par défaut son fichier de configuration dans
      /usr/lib/ssl/openssl.cnf. Ajoutez donc systématiquement
      -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.
    </para>
    <para>
      Les utilitaires et diverses bibliothèques se trouvent dans
      /usr/lib/ssl
    </para>
    <sect2>
      <title>L'utilitaire CA.pl</title>
      <para>
        Vérifiez que CA.pl se trouve dans un répertoire qui figure dans
        le chemin d'accès par défaut aux programmes. Il peut se trouver
        dans le répertoire /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.
      </para>
      <para>
        Modifiez CA.pl de façon à ce que les appels à openssl ca et
        openssl req incluent l'option -config /etc/openssl.cnf.
      </para>
<programlisting>
#$SSLEAY_CONFIG=$ENV{"SSLEAY_CONFIG"};
$SSLEAY_CONFIG="-config /etc/openssl.cnf";
#$CATOP="./demoCA";
$CATOP="/var/ssl";
</programlisting>
    </sect2>
    <sect2>
      <title>Le fichier openssl.cnf</title>
      <para>
        /etc/openssl.cnf doit être configuré de façon à minimiser les
        données à renseigner à chaque invocation des utilitaires.
      </para>
<programlisting>
#---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 nouveaux certificats
crl_dir         = $dir/crl                # Emplacement des nouvelles CRL
database        = $dir/index.txt          # Fichier d'index
new_certs_dir   = $dir/newcerts           # Emplacement des nouveaux certificats

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 PKIX)
# 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----
</programlisting>
      <para>
        Quelques remarques au sujet du fichier openssl.cnf
      </para>
      <itemizedlist>
        <listitem><para>
          Plusieurs variables se présentent avec les suffixes _default,
          _min et _max pour leurs valeurs minimales ou leurs nombres minimaux
          et maximaux de caractères respectivement.
        </para></listitem>
        <listitem><para>
          Le fichier est basé sur des &lsqb;Sections&rsqb; de variables.
        </para></listitem>
      </itemizedlist>
      <variablelist>
        <varlistentry>
          <term>dir&nbsp;:</term>
          <listitem><para>
            répertoire de base.
          </para></listitem>
        </varlistentry>
        <varlistentry>
          <term>default_ca&nbsp;:</term>
          <listitem><para>
            désigne la section des variables pour un certificat dont
            le type n'est pas spécifié.
          </para></listitem>
        </varlistentry>
        <varlistentry>
          <term>basicConstraints&nbsp;:</term>
          <listitem><para>
            définit l'usage du certificat. CA:TRUE désigne un certificat
            de CA racine par exemple.
          </para></listitem>
        </varlistentry>
      </variablelist>
    </sect2>
    <sect2>
      <title>Création de l'autorité de certification</title>
      <para>
        Utilisez la commande suivante après avoir modifié de façon
        adéquate le fichier openssl.cnf&nbsp;:
      </para>
<programlisting>
CA.pl -newca
</programlisting>
      <para>
        L'utilitaire demande de choisir un fichier contenant le
        certificat de l'AC ou bien il propose d'en créer un. A titre
        d'exercice, laissez vous guider dans la création d'une AC.
        La partie suivante remplace cette AC par une AC de durée de
        vie plus importante. CA.pl ne génère que des certificats
        valables 365 jours.
      </para>
    </sect2>
  </sect1>
  <sect1>
    <title>Création d'une autorité de certification racine</title>
    <para>
      La commande suivante crée un certificat auto-signé (pour une
      autorité de certification donc).
    </para>
<programlisting>
CA.pl -newcert
openssl req -config /etc/openssl.cnf -new -x509 -keyout newreq.pem \
        -out newreq.pem -days 365
</programlisting>
    <para>
      Le nouveau certificat se trouve dans le fichier newreq.pem.
      Utilisez un CN du type «&nbsp;ACME root Certificate&nbsp;».
      Le fichier est à diviser en deux parties, cacert.pem et
      private/cakey.pem. La partie délimitée par -RSA PRIVATE KEY-
      va dans le fichier private/cakey.pem tandis que la partie
      -CERTIFICATE- est destinée au fichier cacert.pem. Supprimez
      newreq.pem une fois l'opération effectuée.
    </para>
    <para>
      Vérifiez à présent que le fichier index.txt est vide et que le
      fichier serial contient la valeur 01.
    </para>
    <para>
      Afin de ne pas avoir à renouveler tous les certificats émis
      par une AC lorsque son certificat racine expire, il est
      souhaitable d'augmenter la durée de vie de ce dernier. Les
      autorités de certification commerciales emploient des durées
      de 5 à 10 ans.
    </para>
<programlisting>
openssl req -config /etc/openssl.cnf -new -x509 -keyout private/cakey.pem \
       -out cacert.pem -days 3650
</programlisting>
    <para>
      La commande précédente est plus efficace que 
      «&nbsp;CA.pl&nbsp;-newcert&nbsp;» car elle place les fichiers créés
      à l'emplacement souhaité et génère une AC racine valable 10 ans.
    </para>
    <para>
      Il reste à s'assurer que le certificat auto-signé racine n'est
      employé que pour signer des certificats. La confidentialité de
      la clef privée est très 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 accéder qu'en cas de besoin. Si la
      machine est compromise, la clef privée est ailleurs.
    </para>
    <para>
      On dispose maintenant d'une autorité de certification racine.
      Les utilisateurs doivent faire confiance à votre certificat de
      CA et donc le récupérer et le charger dans leurs navigateurs.
    </para>
    <para>
      Il faudra renseigner le mot de passe lors de la signature de
      chaque certificat.
    </para>
  </sect1>
  <sect1>
    <title>Création d'une autorité de certification non-racine</title>
    <para>
      CORRIGEZ-MOI parce que je ne suis pas tout à fait sûr de la
      procédure.
    </para>
    <para>
      Un certificat peut être employé pour en signer un autre pourvu
      qu'il soit valide et ait été autorisé à le faire lors de sa
      création. On peut donc créer une demande de certificat et une
      clef privée, faire signer le certificat par un tiers et installer
      le certificat signé et la clef privée. La partie -PRIVATE KEY-
      va dans le fichier private/cakey.pem tandis que la partie
       -CERTIFICATE- va dans cacert.pem.
    </para>
  </sect1>
  <sect1>
    <title>
      Mise en place du certificat de CA racine comme certificat fiable.
    </title>
    <para>
      On commence par ôter du certificat tout ce qui n'appartient pas à
      la section -CERTIFICATE-.
    </para>
<programlisting>
openssl x509 -in cacert.pem -out cacert.crt
</programlisting>
    <para>
      On place ensuite le fichier obtenu sur son site web, par exemple
      http://mysite.com/ssl/cacert.crt. Le serveur web doit intégrer une
      description MIME pour les fichiers .crt. Le certificat est prêt à
      être téléchargé et utilisé par n'importe quel navigateur.
    </para>
    <para>
      Il est important de publier son certificat racine de CA sur un
      site web car il est peu probable que les utilisateurs l'aient
      déjà 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 contrôler.
    </para>
    <para>
      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 données et intégré à leurs futurs paquets.
    </para>
    <sect2>
      <title>Netscape/Mozilla</title>
      <para>
        On récupère le certificat depuis le web ou le système de
        fichiers avec Netscape. Ce dernier identifie automatiquement
        le fichier comme un certificat racine et propose de l'intégrer.
        Un assistant guide dans l'installation. A la fin du processus,
        on précise le domaine d'application du certificat&nbsp;: sécurisation
        web, signature de courrier électronique ou signature de code.
      </para>
    </sect2>
    <sect2>
      <title>Galeon</title>
      <para>
        Galeon fonctionne comme Mozilla en ce qu'il repose sur le
        même moteur de rendu HTML. Il n'inclut toutefois pas d'outil
        de gestion des certificats.
      </para>
    </sect2>
    <sect2>
      <title>Opera</title>
      <para>COMPLÉTEZ-MOI</para>
    </sect2>
    <sect2>
      <title>Internet Explorer</title>
      <para>
        On commence par aller à l'adresse de téléchargement 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
        spontanément les certificats auto-signés dans la liste des
        autorités de certification. A partir de ce point, Internet
        Explorer cesse d'émettre des avertissements et considère comme
        fiables les certificats signés avec ce certificat de CA racine.
      </para>
      <para>
        Il est également possible d'ouvrir le certificat depuis
        Internet Explorer qui en affiche alors le contenu. L'assistant
        démarre ensuite en appuyant sur le bouton d'installation du
        certificat.
      </para>
    </sect2>
  </sect1>
  <sect1>
    <title>Gestion des certificats</title>
    <sect2>
      <title>Création et signature de demandes de certificats</title>
<programlisting>
CA.pl -newreq
(openssl req -config /etc/openssl.cnf -new -keyout newreq.pem \
         -out newreq.pem -days 365)
</programlisting>
      <para>
        La commande précédente crée une nouvelle clef privée et une
        demande de certificat qu'elle place dans newreq.pem. Pour
        sécuriser 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.
      </para>
<programlisting>
CA.pl -sign
(openssl ca -config /etc/openssl.cnf -policy policy_anything \
         -out newcert.pem -infiles newreq.pem)
</programlisting>
      <para>
        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 nécessaire. Un fichier newcerts/xx.pem
        est créé et les fichiers index.txt, serial sont mis à jour.
      </para>
      <para>
        La clef privée se trouve donc dans la section -PRIVATE KEY- de
        newreq.pem et le certificat dans la section -CERTIFICATE- de
        newcert.pem.
      </para>
      <para>
        Une copie de newcert.pem est émise dans le répertoire newcerts/
        et l'enregistrement correspondant ajouté à index.txt de telle
        sorte qu'un client puisse accéder à l'information via un
        serveur web et vérifier l'authenticité du certificat.
      </para>
      <para>
        On note que le fichier newreq.pem contient aussi bien la demande
        de certificat que la clef privée. La section -PRIVATE KEY- n'est
        pas nécessaire à la signature et il faut absolument la retirer
        avant de transmettre la demande à quelqu'un d'autre pour qu'il
        la signe. De même, pour signer une demande de certificat, il
        suffit d'obtenir la section -CERTIFICATE REQUEST-. Il n'y a
        aucune raison de demander la clef privée.
      </para>
    </sect2>
    <sect2>
      <title>Révocation de certificat</title>
      <para>
        La commande suivante révoque un certificat&nbsp;:
      </para>
<programlisting>
openssl -revoke newcert.pem
</programlisting>
      <para>
        La base de données index.txt est modifiée en conséquence et le
        certificat est annoté comme révoqué. Il reste à régénérer la
        liste de révocation des certificats&nbsp;:
      </para>
<programlisting>
openssl ca -gencrl -config /etc/openssl.cnf -out crl/sopac-ca.crl
</programlisting>
      <para>
        La liste de révocation (CRL/Certificate Revokation List) doit
        être rendue publique, par exemple sur un site web.
      </para>
      <para>
        Les paramètres crldays, crlhours permettent de préciser la 
        prochaine date de mise à jour de la CRL. crlexts spécifie la
        section du fichier openssl.cnf à employer pour créer une CRL
        de version 2 en place d'une CRL de version 1.
      </para>
<programlisting>
openssl ca -gencrl -config /etc/openssl.cnf -crldays 7 \
           -crlexts crl_ext -out crl/sopac-ca.crl
</programlisting>
    </sect2>
    <sect2>
      <title>Renouvellement d'un certificat</title>
      <para>
        L'utilisateur transmet son ancienne demande de certificat ou
        en régénère une nouvelle basée sur sa clef privée.
      </para>
      <para>
        Il faut alors révoquer l'ancien certificat et signer la nouvelle
        demande de certificat.
      </para>
      <para>
        L'ancien certificat se retrouve en cherchant dans le fichier
        index.txt le nom qualifié (DN) qui correspond à la requête.
        La procédure de révocation s'effectue ensuite avec le numéro de
        série &lt;xx&gt; et le fichier de certificat cert/&lt;xx&gt;.pem.
      </para>
      <para>
        La signature de la nouvelle requête peut être manuelle pour
        s'assurer que les dates de validité du certificat seront
        correctes.
      </para>
<programlisting>
openssl ca -config /etc/openssl.cnf -policy policy_anything -out newcert.pem \
-infiles newreq.pem -startdate [now] -enddate [previous enddate+365days]
</programlisting>
      <para>
        &lsqb;now&rsqb; et &lsqb;previous enddate+365days&rsqb; sont à
        remplacer par des valeurs adéquates.
      </para>
    </sect2>
    <sect2>
      <title>Affichage d'un certificat</title>
      <para>
        L'affichage sous forme textuelle du contenu d'un certificat sous
        forme codée s'effectue avec la commande suivante&nbsp;:
      </para>
<programlisting>
openssl x509 -in newcert.pem -noout -text
</programlisting>
    </sect2>
    <sect2>
      <title>Le fichier index.txt</title>
      <para>
        Le fichier index.txt contient les références des certificats
        créés par OpenSSL. Les enregistrements sont annotés avec un
        R pour indiquer que le certificat est révoqué, V qu'il est
        valide et E qu'il a expiré.
      </para>
    </sect2>
    <sect2>
      <title>Élaborer son service web d'autorité de certification</title>
      <para>
        Être une autorité de certification implique certaines tâches&nbsp;:
      </para>
      <orderedlist>
        <listitem><para>
          publier le certificat de CA racine pour qu'il puisse être
          déployé dans les applications&nbsp;;
        </para></listitem>
        <listitem><para>
          publier la liste de révocation&nbsp;;
        </para></listitem>
        <listitem><para>
          afficher le contenu détaillé des certificats, notamment leur
          numéro de série&nbsp;;
        </para></listitem>
        <listitem><para>
          fournir un formulaire de demande de certificats.
        </para></listitem>
      </orderedlist>
      <para>
        Un serveur web et quelques scripts permettent de réaliser toutes
        ces fonctions.
      </para>
      <para>COMPLÉTEZ-MOI&nbsp;: code de l'interface web.</para>
    </sect2>
  </sect1>
</chapter>
<chapter>
  <title>Emploi des certificats avec les applications</title>
  <sect1>
    <title>Sécurisation des protocoles Internet</title>
    <sect2>
      <title>mod_ssl (Apache) et les certificats</title>
      <para>
        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 privée.
      </para>
      <para>
        On commence par créer 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.
      </para>
      <para>
        La clef doit être déverrouillée en en autorisant l'usage sans
        devoir rentrer le mot de passe. On supprime donc le mot de passe
        du fichier newreq.pem&nbsp;:
      </para>
<programlisting>
openssl rsa -in newreq.pem -out wwwkeyunsecure.pem
</programlisting>
      <para>
        Comme la clef privée n'est plus protégée, on a intérêt à savoir
        ce qu'on fait et notamment à vérifier les droits d'accès aux
        fichiers. Si quelqu'un arrive à s'en emparer, le site est
        compromis. On peut à présent utiliser newcert et
        wwwkeyunsecure.pem avec Apache.
      <!-- Typo de l'auteur ici: cakeyunsecure.pem -->
      </para>
      <para>
        On copie wwwkeyunsecure.pem et newcert.pem dans le répertoire
        /etc/httpd/conf/ssl/ dans les fichiers wwwkeyunsecure.pem et
        wwwcert.crt respectivement.
      </para>
      <para>
        On édite ensuite /etc/httpd/conf/ssl/ssl.default-vhost.conf&nbsp;:
      </para>
<programlisting>
----
# 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
----
</programlisting>
      <para>
        On arrête httpd (/etc/rc.d/init.d/httpd stop) puis on vérifie
        que tous les processus ont disparu (killall httpd) avant de
        relancer le démon (/etc/rc.d/init.d/httpd start).
      </para>
    </sect2>
    <sect2>
      <title>IMAPS et les certificats</title>
      <para>
        Se reporter au paragraphe «&nbsp;POPS et les certificats&nbsp;»
        pour davantage de détails.
      </para>
    </sect2>
    <sect2>
      <title>POPS et les certificats</title>
      <para>
        Un fichier pem pour ipop3sd se crée en générant un certificat, 
        en déverrouillant la clef privée 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&nbsp;9.0.
        La même procédure s'applique à imap avec le fichier
        /etc/ssl/imap/imapsd.pem.
        </para>
        <para>
        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 «&nbsp;This server requires a secure connection
        (SSL)&nbsp;» dans les propriétés avancées. 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é.
      </para>
    </sect2>
    <sect2>
      <title>Postfix et les certificats</title>
      <para>COMPLÉTEZ-MOI</para>
    </sect2>
    <sect2>
      <title>Stunnel et les certificats</title>
      <para>COMPLÉTEZ-MOI</para>
    </sect2>
    <sect2>
      <title>
        Création et signature de clef avec Microsoft Key Manager
      </title>
      <para>
        Dans Microsoft Key Manager, on choisit le service pour lequel on
        souhaite créer un certificat, par exemple IMAP (ou WWW).
        L'assistant permet de générer 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:&bsol;NewKeyRq.txt. Key Manager indique la clef avec un signe
        qui signale qu'elle n'est pas signée.
      </para>
      <para>
        On copie ce fichier dans le répertoire /var/ssl d'OpenSSL sous le
        nom newreq.pem et on signe la requête comme à l'accoutumé.
      </para>
<programlisting>
CA.pl -sign
</programlisting>
      <para>
        newcert.pem n'est pas intelligible par Key Manager car il contient
        du texte et une section -CERTIFICATE-. Il faut supprimer le texte&nbsp;:
      </para>
<programlisting>
openssl x509 -in newcert.pem -out newcertx509.pem
</programlisting>
      <para>
        Un éditeur remplit également cette tâche.
      </para>
      <para>
        newcertx509.pem ne contient plus qu'une section -CERTIFICATE-.
      </para>
      <para>
        On recopie newcertx509.pem sur la machine où s'exécute 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.
      </para>
    </sect2>
  </sect1>
  <sect1>
    <title>Sécurisation du courrier électronique</title>
    <sect2>
      <title>Création et emploi d'un certificat S/MIME</title>
      <para>
        Il faut simplement générer et signer une demande de certificat
        avec l'adresse électronique en guise de nom d'usage (CN).
      </para>
      <para>
        On peut alors signer un message de test test.txt avec le nouveau
        certificat newcert.pem et la clef newreq.pem&nbsp;:
      </para>
<programlisting>
openssl smime -sign -in test.txt -text -out test.msg -signer newcert.pem -inkey newreq.pem
</programlisting>
      <para>
        test.msg peut être transmis à n'importe qui et cette procédure
        s'applique pour émettre des notes signées ou tout autre document
        signé destiné à être publié électroniquement.
      </para>
    </sect2>
    <sect2>
      <title>Emploi du certificat S/MIME avec MS Outlook</title>
      <para>
        Il faut l'importer dans Outlook sous forme de fichier pkcs12.
        La création du fichier pkcs12 s'effectue comme suit&nbsp;:
      </para>
<programlisting>
CA.pl -pkcs12 "Franck Martin"
(openssl pkcs12 -export -in newcert.pem -inkey newreq.pem \
         -out newcert.p12 -name "Franck Martin")
</programlisting>
      <para>
        Il est possible de lier le certificat de signature au fichier
        pkcs12&nbsp;:
      </para>
<programlisting>
openssl pkcs12 -export -in newcert.pem -inkey newreq.pem \
        -certfile cacert.pem -out newcert.p12 -name "Franck Martin"
</programlisting>
      <para>
        Ce certificat contient les clefs privées et publique. Seul le mot
        de passe protège cette dernière. Le fichier ne doit donc pas
        traîner n'importe où.
      </para>
      <para>
        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, &quot;Franck Martin&quot; dans mon
        cas (à adapter).
      </para>
      <para>
        On clique ensuite sur le bouton Settings puis, MS Outlook ayant
        normalement sélectionné les choix par défaut, sur New. Il est
        alors possible d'envoyer des courriers électroniques signés.
        La clef publique est transmise en même temps que les messages
        signés et le destinataire est donc en mesure de renvoyer des
        données chiffrées.
      </para>
      <para>
        Comme le certificat a été généré à partir d'un certificat
        auto-signé, le chemin de validation ne sera pas valide tant que
        l'application ne connaît 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 détail de la marche à suivre.
      </para>
      <para>
        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 nécessaire pour effectuer le
        déchiffrement.
      </para>
      <para>
        Certaines anciennes versions de MS Outlook pour XP parcourent
        Internet pour vérifier 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 déclenche si on n'est pas connecté en permanence.
        Ce processus bloque toute la machine jusqu'à ce que MS Outlook
        l'ait achevé d'une façon ou d'une autre.
      </para>
    </sect2>
    <sect2>
      <title>Emploi du certificat S/MIME avec MS Outlook Express</title>
      <para>COMPLÉTEZ-MOI</para>
    </sect2>
    <sect2>
      <title>Emploi du certificat S/MIME avec Netscape Messenger</title>
      <para>COMPLÉTEZ-MOI</para>
    </sect2>
    <sect2>
      <title>Emploi du certificat S/MIME avec Evolution</title>
      <para>
        Evolution 1.0 ne gère pas S/MIME mais seulement PGP. La prise en
        charge S/MIME est prévue pour une version ultérieure (d'après la
        base de données de suivi des bogues d'Evolution). Evolution remarque
        quand même parfois que le document est signé en clair et l'affiche
        correctement bien qu'il ne puisse en vérifier la validité. Des
        versions antérieures d'Evolution n'assimilaient pas un des trois
        types MIME de signature que MS Outlook emploie hélas assez
        souvent.
      </para>
    </sect2>
    <sect2>
      <title>Emploi du certificat S/MIME avec Balsa</title>
      <para>COMPLÉTEZ-MOI</para>
    </sect2>
    <sect2>
      <title>Emploi du certificat S/MIME avec KMail</title>
      <para>COMPLÉTEZ-MOI</para>
    </sect2>
  </sect1>
  <sect1>
    <title>Protection des fichiers</title>
    <sect2>
      <title>WinCrypt</title>
      <para>
        <ulink url="http://www.wincrypt.de/">WinCrypt</ulink> s'appuie sur
        l'API de chiffrage de Microsoft pour chiffrer et signer les
        fichiers. Il crée en outre de façon optionnelle une archive zip
        avant la signature. Il dispose d'un frontal pour gérer la liste
        des certificats, les parcourir, en installer, en supprimer et
        choisir celui à employer avec WinCrypt.
      </para>
      <para>
        La procédure de création d'un certificat est identique à celle
        de Microsoft Outlook. La même liste de certificats est utilisée
        par les deux applications.
      </para>
      <para>
        Un fichier filename.sgn signé avec WinCrypt se vérifie avec la
        commande&nbsp;:
      </para>
<programlisting>
openssl smime -verify -inform der -in filename.sgn -CAfile cacert.crt
</programlisting>
      <para>
        La commande suivante permet de signer un fichier avec OpenSSL
        de façon compatible&nbsp;:
      </para>
<programlisting>
openssl smime -sign -outform der -nodetach -out filename.sgn \
-signer certificate.pem -in filename.txt
</programlisting>
      <para>
        Pour visualiser l'organisation d'un fichier signé&nbsp;:
      </para>
<programlisting>
openssl asn1parse -inform der -in filename.sgn
</programlisting>
    </sect2>
  </sect1>
  <sect1>
    <title>Sécurisation des programmes</title>
    <sect2>
      <title>Micosoft Code</title>
      <para>
        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 insérant un virus ou un cheval
        de Troie. L'étape de signature nécessite le SDK Microsoft
        Authenticode. Ce dernier est disponible dans la section MSDN du site
        web de Microsoft.
      </para>
      <para>
        On génère un certificat comme à l'accoutumé mais avec un nom
        d'usage de la forme «&nbsp;ACME Software 
        Cert&nbsp;». Le certificat doit ensuite être signé par 
        l'autorité de certification et converti au format pkcs12.
      </para>
<programlisting>
CA.pl -newreq
CA.pl -sign
CA.pl -pkcs12 "ACME Software Cert"
</programlisting>
      <para>
        On obtient un fichier newcert.p12 qu'on importe dans la liste des
        certificats en cliquant dessus une fois sous MS Windows.
      </para>
      <para>
        Le certificat peut alors servir à signer du code&nbsp;:
      </para>

<programlisting>
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
</programlisting>

      <para>
        A l'installation et à l'exécution de l'application, une boite de
        dialogue apparaît sous le nom «&nbsp;My Application&nbsp;» avec
        le lien pointé par l'argument -i.
      </para>
    </sect2>
  </sect1>
  <sect1>
    <title>IPSec</title>
    <para>
      IPSec est un nouveau protocole basé sur IP qui autorise les liens
      chiffrés à la demande entre deux machines. La mise en &oelig;uvre d'IPSec
      est obligatoire dans le cadre d'IPv6 et peut être incorporée dans
      IPv4. Qu'IPSec soit obligatoire pour IPv6 ne signifie pas pour autant
      qu'il est systématiquement déployé par les administrateurs réseau.
      IPSec n'est pas facile à mettre en &oelig;uvre à cause des mécanismes de
      déploiement automatiques des clefs. Le DNS peut aider mais cette
      méthode n'est pas encore courante. En outre, les autorités de
      certification ne proposent pas d'outils pour un déploiement à grande
      échelle en entreprise.
    </para>
    <sect2>
      <title>FreeS/WAN</title>
      <para>
        <ulink url="http://www.freeswan.org/">FreeS/WAN</ulink> est une
        souche IPSec renommée pour GNU/Linux. La version actuelle (1.9.7)
        doit être patchée pour gérer les certificats X.509v3. Une telle
        version modifiée est disponible sur ce 
        <ulink url="http://www.freeswan.ca/">site</ulink>. Certaines
        distributions l'incluent en standard, il est donc conseillé de
        commencer par vérifier si c'est le cas pour celle qu'on utilise.
        Cette version présente l'intérêt de permettre l'usage d'OpenSSL
        pour la création des certificats de FreeS/WAN et des enregistrements
        CERT du DNS. En outre, l'interaction avec la souche IPSec de
        Microsoft est réalisable. On se reportera à la page de
        <ulink url="http://www.natecarlson.com/linux/ipsec-x509.php">Nate's</ulink>
        pour davantage d'informations.
      </para>
      <sect3>
        <title>Passerelle FreeS/WAN</title>
        <para>
          On crée un certificat dont le CN correspond au nom de domaine
          complètement 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 privée&nbsp;: 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 sécurisé. Les fichiers de
          configuration de FreeS/WAN se trouvent dans le répertoire
          /etc/freeswan pour ma distribution. À ajuster suivant les cas.
        </para>
<programlisting>
mv newreq.pem /etc/freeswan/ipsec.d/private/host.example.com.key
mv newcert.pem /etc/freeswan/ipsec.d/host.example.com.pem
</programlisting>
        <para>
          On copie le certificat racine dans le répertoire de configuration
          de FreeS/WAN. Il ne faut copier que le certificat, pas la clef.
        </para>
<programlisting>
mv cacert.pem /etc/freeswan/ipsec.d/cacerts
</programlisting>
        <para>
          On génère une liste de révocation ou on copie l'existante à
          l'emplacement adéquat&nbsp;:
        </para>
<programlisting>
openssl ca -genrcl -out /etc/freeswan/ipsec.d/crls/crl.pem
</programlisting>
        <para>
          Toujours sur la passerelle, on inclut dans le fichier
          ipsec.secrets la ligne ci-dessous&nbsp;:
        </para>
<programlisting>
: RSA host.example.com.key 
          "password"
</programlisting>
        <para>
          Le mot de passe est celui qui a servi à créer la paire de clef.
          On configure le fichier ipsec.conf comme suit&nbsp;:
        </para>
<programlisting>
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=&lt;sous_reseau&gt;/&lt;masque_de_sous_reseau&gt;
also=roadwarrior

conn roadwarrior
right=%any
left%defaultroute
leftcert=host.example.com.pem
auto=add
pfs=yes
</programlisting>
        <para>
          Comme on peut le voir, deux liens sont établis, l'un avec
          la passerelle, l'autre avec le réseau situé derrière la
          passerelle. Ceci s'avère très pratique si un pare-feu ou un 
          traducteur d'adresses est actif sur la passerelle. La
          configuration autorise tout propriétaire d'un certificat valide
          à se connecter à la passerelle.
        </para>
      </sect3>
      <sect3>
        <title>Client FreeS/WAN</title>
        <para>
          La procédure est semblable. Il faut créer un certificat dont
          le CN correspond au nom de domaine complètement qualifié de
          l'hôte, par exemple clienthost.example.com. Le certificat doit
          être signé par la même autorité de certification que la
          passerelle. Le lien est alors autorisé.
        </para>
        <para>
          Comme pour la passerelle, on copie de façon sécurisée les fichiers
          suivants dans les répertoires de configuration&nbsp;:
        </para>
<programlisting>
mv newreq.pem /etc/freeswan/ipsec.d/private/clienthost.example.com.key
mv newcert.pem /etc/freeswan/ipsec.d/clienthost.example.com.pem
</programlisting>
        <para>
          On copie le certificat racine dans le répertoire de configuration
          de FreeS/WAN. Il ne faut copier que le certificat, pas la clef.
        </para>
<programlisting>
mv cacert.pem /etc/freeswan/ipsec.d/cacerts
</programlisting>
        <para>
          On génère une liste de révocation ou on copie l'existante à
          l'emplacement adéquat&nbsp;:
        </para>
<programlisting>
openssl ca -genrcl -out /etc/freeswan/ipsec.d/crls/crl.pem
</programlisting>
        <para>
          Enfin, on copie le certificat (mais pas la clef privée) de la
          passerelle&nbsp;:
        </para>
<programlisting>
mv host.example.com.pem /etc/fresswan/ipsec.d/host.example.com.pem
</programlisting>
        <para>
          Le fichier ipsec.secrets est édité de la même façon pour charger
          la clef privée&nbsp;:
        </para>
<programlisting>
: RSA clienthost.example.com.key
        "password"
</programlisting>
        <para>
          On édite le fichier ipsec.conf pour activer la connexion&nbsp;:
        </para>
<programlisting>
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
</programlisting>
        <para>
          On met ensuite le VPN en action&nbsp;:
        </para>
<programlisting>
ipsec auto --up roadwarrior
ipsec auto --up roadwarrior-net
</programlisting>
        <para>
          Afin que le lien s'établisse automatiquement, on remplace dans le
          fichier de configuration la directive «&nbsp;auto=add&nbsp;» par 
          «&nbsp;auto=start&nbsp;».
        </para>
      </sect3>
      <sect3>
        <title>Client MS Windows 2000/XP</title>
        <para>
          La procédure est identique à celle du client FreeS/WAN. On crée
          un certificat, par exemple pour winhost.example.com, qui doit à
          présent être converti au format pkcs12. On se reportera à la
          section «&nbsp;MS Outlook et les certificats&nbsp;» pour le
          détail de la marche à suivre. On s'assure de ce que le fichier
          .p12 est attaché au certificat de l'autorité de certification
          racine.
        </para>
        <para>
          On note le résultat de la commande&nbsp;:
        </para>
<programlisting>
openssl x509 -in cacert.pem -noout -subject
</programlisting>
        <para>
          Ce fichier doit être copié de façon sécurisée sur la machine
          MS Windows.
        </para>
        <para>
          On installe à présent l'utilitaire
          <ulink url="http://vpn.ebootis.de/">ipsec.exe</ulink> de
          Marcus Muller, par exemple dans le répertoire c:&bsol;ipsec.
        </para>
        <para>
          On ouvre la console de gestion Microsoft (Microsoft Management 
          Console/MMC) puis on clique sur «&nbsp;Add/Remove 
          Snap-in&nbsp;», «&nbsp;Add&nbsp;», 
          «&nbsp;Certificates&nbsp;», 
          «&nbsp;Add&nbsp;», «&nbsp;Computer 
          Account&nbsp;» et «&nbsp;Next&nbsp;». On 
          choisit alors «&nbsp;Local computer&nbsp;» et 
          «&nbsp;Finish&nbsp;». Dans «&nbsp;IP 
          Security Policy Management&nbsp;», choisir 
          «&nbsp;Add&nbsp;», «&nbsp;Local 
          Computer&nbsp;» puis «&nbsp;Finish&nbsp;», 
          «&nbsp;Close&nbsp;» et enfin 
          «&nbsp;OK&nbsp;».
        </para>
        <para>
          On peut à présent ajouter le certificat .p12.
        </para>
        <para>
          On clique sur la flèche d'ajout pour «&nbsp;Certificates 
          (Local Computer)&nbsp;» puis avec le bouton droit sur 
          «&nbsp;Personal&nbsp;» avant de cliquer sur 
          «&nbsp;All Tasks&nbsp;», 
          «&nbsp;Import&nbsp;» et  
          «&nbsp;Next&nbsp;». On renseigne ensuite le chemin
          d'accès au fichier .p12 (ou on navigue pour atteindre le 
          fichier) et on clique sur «&nbsp;Next&nbsp;». On 
          rentre alors le mot de passe de protection du fichier puis on 
          clique sur «&nbsp;Next&nbsp;». On choisit 
          «&nbsp;Automatically select the certificate store based 
          on the type of certificate&nbsp;», 
          «&nbsp;Next&nbsp;», 
          «&nbsp;Finish&nbsp;» et on répond positivement à 
          toutes les questions qui se présentent. On sort de la console 
          et on enregistre la séquence correspondante dans un fichier 
          pour ne pas avoir à se la farcir à chaque fois.
        </para>
        <para>
          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
          remplaçant &quot;RightCA&quot; par la sortie de la commande
          «&nbsp;openssl x509 -in cacert.pem -noout 
          -subject&nbsp;»; 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)&nbsp;:
        </para>
<programlisting>
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
</programlisting>
        <para>
          On démarre à présent le lien.
        </para>
        <para>
          Pour cela on invoque la commande 
          «&nbsp;ipsec.exe&nbsp;». Voici un exemple de 
          sortie de cette commande&nbsp;:
        </para>
<programlisting>
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>
</programlisting>
        <para>
          On émet un ping vers la passerelle qui devrait afficher
          «&nbsp;Negotiating IP Security&nbsp;» pendant quelques instants avant de
          répondre au ping. Pour une T1 qui attaque un VPN derrière un
          modem cable, il s'écoule typiquement de trois à quatre pings.
          Une fois la même chose faite depuis le réseau interne à l'autre
          extrémité du lien, ce dernier devrait être opérationnel.
        </para>
      </sect3>
    </sect2>
  </sect1>
</chapter>
<chapter>
  <title>PKI Globale</title>
  <sect1>
    <title>PKIs existantes</title>
    <para>
      Aujourd'hui on a le choix entre avoir recours à une PKI commerciale
      ou utiliser la sienne. Les PKI commerciales ont été créées à l'origine
      pour permettre le commerce électronqiue via Internet et plus
      particulièrement sur le web. Le prix des certificats dépendait du
      nombre d'hôtes. Le prix est plus élevé que pour un nom de domaine
      parce que les coûts d'identification des demandeurs sont plus élevés
      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 sécuriser
      quelques serveurs, fussent-ils POP ou IMAP, mais que chaque hôte a
      besoin de son certificat quand ce n'est pas chaque utilisateur ou
      chaque application. Le coût s'envole avec l'espoir d'un système un
      tant soit peu administrable.
    </para>
    <para>
      Pourquoi ne pas voir un certificat pour signer tous les autres&nbsp;?
      Pour l'instant la seule solution consiste à construire sa propre
      autorité de certification, ce qui permet une gestion souple mais
      limite la portée du procédé à l'organisation qui y a recours.
      Le reste du monde doit récupérer des clefs d'autorités de
      certification racine au cas par cas.
    </para>
    <para>
      La solution consiste en une PKI unique gérée par une entité centrale
      de façon analogue au DNS. On parle alors de PKI globale.
    </para>
  </sect1>
  <sect1>
    <title>Le besoin d'une PKI globale</title>
    <para>
      La sécurité des ordinateurs personnels est devenu un sujet d'une
      telle importance aujourd'hui que Bill Gates a annoncé que Microsoft
      choisirait à présent la sécurité aux fonctionnalités si la décision
      devait être prise (NdT&nbsp;: il _peut_ le dire).
    </para>
    <para>
      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
      problème. C'est particulièrement vrai dans le cas du courrier
      non-sollicité pour lequel il est souvent difficile d'authentifier
      l'émetteur d'origine. Le traitement d'une donnée peut être
      différent si elle n'est pas traçable au moyen d'un certificat.
      Il s'agit de la même approche que celle de la présentation du
      numéro d'appel téléphonique. 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&nbsp;&hellip; Ils ne sont toutefois pas très répandus
      en raison de leur coût quand il faut les déployer à grande échelle.
      Combien d'utilisateurs de Yahoo mail, d'Hotmail, de CA Online peuvent
      s'offrir un certificat électronique&nbsp;? 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 propriétaire.
    </para>
    <para>
      Une PKI Globale est nécessaire. Les protocoles et les standards
      existent sans qu'il y ait besoin de réinventer la roue.
      L'<ulink url="http://www.ietf.org/">IETF</ulink> dispose de 
      l'outillage nécessaire. Un serveur LDAP peut stocker les certificats,
      le DNS les annoncer et S/MIME sécuriser les courriers. Il ne reste
      plus qu'un problème de politique&nbsp;: quels services doivent coopérer au
      sein d'une PKI globale, qui doit offrir un tel service, quel sera le
      niveau de sécurité offert&nbsp;?
    </para>
    <para>
      Cette partie sera tenue à jour au fur et à mesure de l'avancement des
      travaux du groupe de travail PKI de l'<ulink url="http://www.isoc.org/">Internet Society</ulink>.
      L'ISOC gère également le TLD .org et dispose donc de moyens pour
      s'attaquer au problème du spam.
    </para>
  </sect1>
</chapter>
</book>
