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

1.1.2. Disclaimer and Licence

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

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

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

1.2.2. Le certificat

Qu'est-ce qui vous garantit que vous dialoguez bien avec la bonne personne ou le bon site web ? En principe, quelqu'un aura fait l'effort (s'il est 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.

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

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

1.2.5. Le hachage

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 (Internet Engineering Task Force) préfère apparemment SHA1 à MD5 pour diverses raisons techniques (cf RFC2459 7.1.2 and 7.1.3).

1.2.6. La signature

La signature d'un message consiste à associer une identité à son contenu. Le plus souvent il s'agit de prouver qui en est l'auteur mais ce n'est pas toujours le cas. Le message peut être textuel ou être le certificat de quelqu'un d'autre. Pour signer un message, son haché est d'abord créé puis ce dernier est chiffré avec la clef 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.

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

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

1.2.7. Le mot de passe

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.

1.2.8. L'infrastructure de clefs publiques

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

2.1.1. L'utilitaire CA.pl

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.

Modifiez CA.pl de façon à ce que les appels à openssl ca et openssl req incluent l'option -config /etc/openssl.cnf.

#$SSLEAY_CONFIG=$ENV{"SSLEAY_CONFIG"};
$SSLEAY_CONFIG="-config /etc/openssl.cnf";
#$CATOP="./demoCA";
$CATOP="/var/ssl";

2.1.2. Le fichier openssl.cnf

/etc/openssl.cnf doit être configuré de façon à minimiser les données à renseigner à chaque invocation des utilitaires.

#---Begin---
#
# Fichier de configuration pour OpenSSL.
# S'emploie surtout pour les demandes de certificats.
#
# NdT: autre chose que de l'ASCII dans les fichiers de
# configuration me rend nerveux. Il y a donc un zest de triche
# dans ce qui suit. Vous ne voudriez pas me rendre nerveux, non ? :o)
#

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

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

[ new_oids ]

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

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

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

[ CA_default ]
dir             = /var/ssl                # Emplacement de base
certs           = $dir/certs              # Emplacement de stockage des 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----

Quelques remarques au sujet du fichier openssl.cnf

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

• Le fichier est basé sur des [Sections] de variables.

2.1.3. Création de l'autorité de certification

Utilisez la commande suivante après avoir modifié de façon adéquate le fichier openssl.cnf :

CA.pl -newca

L'utilitaire demande de choisir un fichier contenant le certificat de l'AC ou bien il propose d'en 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.

2.4.1. Netscape/Mozilla

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 : sécurisation web, signature de courrier électronique ou signature de code.

2.4.2. Galeon

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.

2.4.3. Opera

COMPLÉTEZ-MOI

2.4.4. Internet Explorer

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.

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.

2.5.1. Création et signature de demandes de certificats

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

La commande 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.

CA.pl -sign
(openssl ca -config /etc/openssl.cnf -policy policy_anything \
         -out newcert.pem -infiles newreq.pem)

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

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.

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.

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.

2.5.2. Révocation de certificat

La commande suivante révoque un certificat :

openssl -revoke newcert.pem

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 :

openssl ca -gencrl -config /etc/openssl.cnf -out crl/sopac-ca.crl

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

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.

openssl ca -gencrl -config /etc/openssl.cnf -crldays 7 \
           -crlexts crl_ext -out crl/sopac-ca.crl

2.5.3. Renouvellement d'un certificat

L'utilisateur transmet son ancienne demande de certificat ou en régénère une nouvelle basée sur sa clef privée.

Il faut alors révoquer l'ancien certificat et signer la nouvelle demande de certificat.

L'ancien certificat se retrouve en cherchant dans le fichier index.txt le nom qualifié (DN) qui correspond à la requête. La procédure de révocation s'effectue ensuite avec le numéro de série <xx> et le fichier de certificat cert/<xx>.pem.

La signature de la nouvelle requête peut être manuelle pour s'assurer que les dates de validité du certificat seront correctes.

openssl ca -config /etc/openssl.cnf -policy policy_anything -out newcert.pem \
-infiles newreq.pem -startdate [now] -enddate [previous enddate+365days]

[now] et [previous enddate+365days] sont à remplacer par des valeurs adéquates.

2.5.4. Affichage d'un certificat

L'affichage sous forme textuelle du contenu d'un certificat sous forme codée s'effectue avec la commande suivante :

openssl x509 -in newcert.pem -noout -text

2.5.5. Le fichier index.txt

Le fichier index.txt contient les 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é.

2.5.6. Élaborer son service web d'autorité de certification

Être une autorité de certification implique certaines tâches :

1. publier le certificat de CA racine pour qu'il puisse être déployé dans les applications ;

2. publier la liste de révocation ;

3. afficher le contenu détaillé des certificats, notamment leur numéro de série ;

4. fournir un formulaire de demande de certificats.

Un serveur web et quelques scripts permettent de réaliser toutes ces fonctions.

COMPLÉTEZ-MOI : code de l'interface web.

3.1.1. mod_ssl (Apache) et les certificats

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

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.

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 :

openssl rsa -in newreq.pem -out wwwkeyunsecure.pem

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.

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

On édite ensuite /etc/httpd/conf/ssl/ssl.default-vhost.conf :

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

On 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).

3.1.2. IMAPS et les certificats

Se reporter au paragraphe « POPS et les certificats » pour davantage de détails.

3.1.3. POPS et les certificats

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 9.0. La même procédure s'applique à imap avec le fichier /etc/ssl/imap/imapsd.pem.

Le CN doit correspondre au nom auquel le client de messagerie se connecte (par exemple mail.xyz.org). Avec MS-Outlook, le nom du serveur pop se rentre dans l'onglet à cet effet et on active l'option « This server requires a secure connection (SSL) » dans les 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é.

3.1.4. Postfix et les certificats

COMPLÉTEZ-MOI

3.1.5. Stunnel et les certificats

COMPLÉTEZ-MOI

3.1.6. Création et signature de clef avec Microsoft Key Manager

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:\NewKeyRq.txt. Key Manager indique la clef avec un signe qui signale qu'elle n'est pas signée.

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

CA.pl -sign

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

openssl x509 -in newcert.pem -out newcertx509.pem

Un éditeur remplit également cette tâche.

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

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.

3.2.1. Création et emploi d'un certificat S/MIME

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

On peut alors signer un message de test test.txt avec le nouveau certificat newcert.pem et la clef newreq.pem :

openssl smime -sign -in test.txt -text -out test.msg -signer newcert.pem -inkey newreq.pem

test.msg peut être transmis à n'importe qui et cette procédure s'applique pour émettre des notes signées ou tout autre document signé destiné à être publié électroniquement.

3.2.2. Emploi du certificat S/MIME avec MS Outlook

Il faut l'importer dans Outlook sous forme de fichier pkcs12. La création du fichier pkcs12 s'effectue comme suit :

CA.pl -pkcs12 "Franck Martin"
(openssl pkcs12 -export -in newcert.pem -inkey newreq.pem \
         -out newcert.p12 -name "Franck Martin")

Il est possible de lier le certificat de signature au fichier pkcs12 :

openssl pkcs12 -export -in newcert.pem -inkey newreq.pem \
        -certfile cacert.pem -out newcert.p12 -name "Franck Martin"

Ce certificat contient les clefs 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ù.

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

On clique ensuite sur le bouton Settings puis, MS Outlook ayant normalement 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.

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.

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.

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.

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

COMPLÉTEZ-MOI

3.2.4. Emploi du certificat S/MIME avec Netscape Messenger

COMPLÉTEZ-MOI

3.2.5. Emploi du certificat S/MIME avec Evolution

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.

3.2.6. Emploi du certificat S/MIME avec Balsa

COMPLÉTEZ-MOI

3.2.7. Emploi du certificat S/MIME avec KMail

COMPLÉTEZ-MOI

3.3.1. WinCrypt

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

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.

Un fichier filename.sgn signé avec WinCrypt se vérifie avec la commande :

openssl smime -verify -inform der -in filename.sgn -CAfile cacert.crt

La commande suivante permet de signer un fichier avec OpenSSL de façon compatible :

openssl smime -sign -outform der -nodetach -out filename.sgn \
-signer certificate.pem -in filename.txt

Pour visualiser l'organisation d'un fichier signé :

openssl asn1parse -inform der -in filename.sgn

3.4.1. Micosoft Code

Il est possible de signer ses programmes et ses applets pour prouver qu'on en est l'auteur. Il est important pour les clients de savoir que personne n'a modifié le code en y 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.

On génère un certificat comme à l'accoutumé mais avec un nom d'usage de la forme « ACME Software Cert ». Le certificat doit ensuite être signé par l'autorité de certification et converti au format pkcs12.

CA.pl -newreq
CA.pl -sign
CA.pl -pkcs12 "ACME Software Cert"

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

Le certificat peut alors servir à signer du code :

signcode -cn "ACME Software cert" -tr 5 -tw 2 -n "My Application" \
-i http://www.acme.com/myapp/ \
-t http://timestamp.verisign.com/scripts/timstamp.dll myapp.exe

A l'installation et à l'exécution de l'application, une boite de dialogue apparaît sous le nom « My Application » avec le lien pointé par l'argument -i.

3.5.1. FreeS/WAN

FreeS/WAN 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 site. 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 Nate's pour davantage d'informations.

mv newreq.pem /etc/freeswan/ipsec.d/private/host.example.com.key
mv newcert.pem /etc/freeswan/ipsec.d/host.example.com.pem

mv cacert.pem /etc/freeswan/ipsec.d/cacerts

openssl ca -genrcl -out /etc/freeswan/ipsec.d/crls/crl.pem

: RSA host.example.com.key 
          "password"

config setup
interfaces=%defaultroute
klipsdebug=none
plutodebug=none
plutoload=%search
plutostart=%search
uniqueids=yes
  
conn %default
keyingtries=1
compress=yes
disablearrivalcheck=no
authby=rsasig
leftrsasigkey=%cert
rightrsasigkey=%cert
 
conn roadwarrior-net
leftsubnet=<sous_reseau>/<masque_de_sous_reseau>
also=roadwarrior

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

mv newreq.pem /etc/freeswan/ipsec.d/private/clienthost.example.com.key
mv newcert.pem /etc/freeswan/ipsec.d/clienthost.example.com.pem

mv cacert.pem /etc/freeswan/ipsec.d/cacerts

openssl ca -genrcl -out /etc/freeswan/ipsec.d/crls/crl.pem

mv host.example.com.pem /etc/fresswan/ipsec.d/host.example.com.pem

: RSA clienthost.example.com.key
        "password"

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

ipsec auto --up roadwarrior
ipsec auto --up roadwarrior-net

openssl x509 -in cacert.pem -noout -subject

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

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>