Guide pratique des certificats SSL

Version française du SSL Certificates HOWTO

Franck Martin

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.


Table des matières
1. Principes généraux
Introduction
Droits d'utilisation et limitation de responsabilité
Disclaimer and Licence
Pré-requis
Que sont SSL et les certificats?
Clef publique/ clef privée
Le certificat
La clef symétrique
Les algorithmes de chiffrement

Chapitre 1. Principes généraux


Introduction

Comme moi, vous avez sûrement 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 façon sécurisée avec des certificats. Ce document répond à 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 plaît vos ajouts et corrections. On peut me contacter en anglais à l'adresse suivante: .

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

La version française de ce document est publiée par le projet de traduction traduc.org. Vous y trouverez notamment la dernière version française de ce document.


Droits d'utilisation et limitation de responsabilité

Ce document est distribué dans l'espoir qu'il se révélera utile, mais SANS AUCUNE GARANTIE sans même la garantie implicite qu'il soit PROPRE À LA VENTE ou ADAPTÉ À UN BESOIN PARTICULIER.

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 ce n'est jamais de notre faute. Désolé.

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 française 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 créer des travaux dérivés de celui-ci et les distribuer si vous respectez les conditions suivantes:

  1. Faire parvenir vos travaux dérivés (dans le format le plus approprié tel que SGML) au Projet de documentation Linux (LDP), 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.

  2. 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.

  3. 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.

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


Disclaimer and Licence

Note : 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.

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


Pré-requis

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.


Que sont SSL et les certificats?

Le protocole SSL (Secure Socket Layer) 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 (CA/Certificate Authority) qui identifie n'importe laquelle des extrémités ou les deux. Il s'agit du fonctionnement en très résumé.

  1. Un navigateur demande une page web sécurisée (en général https://).

  2. Le serveur web émet sa clef publique accompagnée de son certificat.

  3. 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.

  4. 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.

  5. 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.

  6. Le serveur renvoie le document html et les données HTTP chiffrées avec la clef symétrique.

  7. Le navigateur déchiffre l'ensemble avec la clef symétrique et affiche les informations.

Plusieurs concepts méritent d'être assimilés.


Clef publique/ clef privée

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: 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: 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.

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.

Message-->[Clef publique]-->Message chiffré-->[Clef privée]-->Message

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 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: 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é (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'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.

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

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.


La clef symétrique

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.

Clef symétrique-->[Clef publique]-->Clef de session chiffrée-->[Clef privée]-->Clef symétrique

Les algorithmes de chiffrement

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 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é.