Un setup d'installation d'OpenSSL pour Windows est disponible ici.



Le travail sur les certificats nécessitera le paramètrage du fichier openssl.cnf.
Ce fichier adapté à vos besoins devra être pointé par la variable d'environnement OPENSSL_CONF.

set OPENSSL_CONF=C:\openssl-0.9.8h\apps\openssl.cnf

1. Création d'une autorité racine (Certificat Autority)

Cette autorité personnelle devra être diffusée auprès des futurs utilisateurs des certificats pour éviter les messages d'alerte concernant une autorité de certification inconnue lorsque de l'utilisation des certificats générés.

Création de la clef privée de la CA

openssl genrsa -aes256 -out CA_pvk.pem 1024
Loading 'screen' into random state - done
Generating RSA private key, 1024 bit long modulus
...................++++++
...++++++
e is 65537 (0x10001)
Enter pass phrase for CA_pvk.pem:mot de passe↵
Verifying - Enter pass phrase for CA_pvk.pem:mot de passe↵

Autogénération du certificat de la nouvelle autorité racine

openssl req -new -x509 -days 365 -key CA_pvk.pem -out CA_crt.pem
Enter pass phrase for CA_pvk.pem:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:↵
State or Province Name (full name) [Some-State]:↵
Locality Name (eg, city) []:↵
Organization Name (eg, company) [Internet Widgits Pty Ltd]:↵
Organizational Unit Name (eg, section) []:↵
Common Name (eg, YOUR name) []:↵
Email Address []:↵

CA_pvk.pem est le fichier contenant la clef privée, il sera nécessaire à la signature des certificats des clients.
CA_crt.pem est le fichier contenant le certificat, il doit être fournit aux clients avec leurs certificats.
Ces deux fichiers doivent être renseignés dans les variables certificate et private_key du fichier de configuration openssl.cnf.

Transformation au format Microsoft

openssl x509 -in CA_crt.pem -outform DER -out CA_crt.der

Il s'agit d'une simple convertion d'un format ascii Base64 en son équivalent binaire

2. Création d'un certificat client

Création du Certificat Signing Request (CSR) client

on commence par créer une clef privée

openssl genrsa -aes256 -out client_pvk.pem 1024
Loading 'screen' into random state - done
Generating RSA private key, 1024 bit long modulus
....++++++
...........................................................++++++
e is 65537 (0x10001)
Enter pass phrase for client_pvk.pem:↵
Verifying - Enter pass phrase for client_pvk.pem:↵

puis à partir de cette clef privée nous générons la CSR

openssl req -new -key client_pvk.pem -out client_csr.pem
Enter pass phrase for client_pvk.pem:↵
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:↵
State or Province Name (full name) [Some-State]:↵
Locality Name (eg, city) []:↵
Organization Name (eg, company) [Internet Widgits Pty Ltd]:↵
Organizational Unit Name (eg, section) []:↵
Common Name (eg, YOUR name) []:↵
Email Address []:↵

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:↵
An optional company name []:↵

Signature de la requête CSR

Maintenant, nous agissons en temps qu'autorité de certification pour valider les informations contenues dans la CSR

        Validity
            Not Before: Aug 26 14:56:09 2007 GMT
            Not After : Aug 25 14:56:09 2008 GMT
        Subject:
            countryName               = FR
            stateOrProvinceName       = Some-State
            organizationName          = Internet Widgits Pty Ltd
            commonName                = TEST
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            Netscape Comment:
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier:
                26:A6:C6:16:CF:2A:5B:D5:9D:FF:2C:48:60:B6:E0:E3:A6:3B:28:88
            X509v3 Authority Key Identifier:
                keyid:68:0D:3F:8A:D3:D7:11:35:EA:AC:C3:28:6C:78:92:04:36:EA:A3:2F

Si vous obtenez ce message :
failed to update database
TXT_DB error number 2
error in ca
Le numéro de série du certificat est déjà utilisé, vous devrez révoquer le certificat l'utilisant.

unable to load certificate
260:error:0906D06C:PEM routines:PEM_read_bio:no start line:.\crypto\pem\pem_lib.c:642:Expecting: TRUSTED CERTIFICATE
error in ca
La CA passée en paramètre n'est pas au format PEM.

Le certificat est créé.

Convertion de la clef privée au format pour IIS

openssl rsa –inform pem –outform net –in client_pvk.pem -out client_pvk.net
Enter pass phrase for client_pvk.pem:
writing RSA key
Enter Private Key password:
Verifying - Enter Private Key password:

La transformation au format binaire de la clef privée est nécessaire pour l'insérer dans le gestionnaire de clefs de IIS.
Il reste à supprimer l'entête du certificat client (client_crt.pem ) et à importer la clef privée et le certificat dans le gestionnaire de clef de IIS.

Convertion du certificat pour importation sous IIS6

openssl pkcs12 -export -in client_crt.pem -inkey client_pvk.pem -out mycert.pfx -name "Mon certificat SSL personnel"
Loading 'screen' into random state - done
Enter pass phrase for client_pvk.pem:
Enter Export Password:
Verifying - Enter Export Password:

Il est à noter pour les utilisateurs sous Windows que le Platform SDK Redistributable: CAPICOM contient un script (CStore.vbs) permettant d'automatiser les actions sur les certificats stockés dans le gestionnaire de clefs de Windows.

3. Commandes utiles

Révocation d'un certificat

openssl ca -revoke client_crt.pem

Retirer la passphrase de la clef privée

openssl rsa -in client_pvk.pem -out client_unpvk.pem

Changer la passphrase de la clef privée

openssl rsa -der -in client_pvk.pem -out client_unpvk.pem
Enter pass phrase for client_pvk.pem:
writing RSA key
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:

Extraction des informations d'un certificat

    Data:
        Version: 3 (0x2)
        Serial Number:
            4b:a5:ae:59:de:dd:1c:c7:80:7c:89:22:91:f0:e2:43
        Signature Algorithm: md5WithRSAEncryption
        Issuer: C=ZA, O=Thawte Consulting (Pty) Ltd., CN=Thawte SGC CA
        Validity
            Not Before: May 15 23:18:11 2006 GMT
            Not After : May 15 23:18:11 2007 GMT
        Subject: C=US, ST=California, L=Mountain View, O=Google Inc, CN=www.google.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:e6:c5:c6:8d:cd:0b:a3:03:04:dc:ae:cc:c9:46:
                    be:bd:cc:9d:bc:73:34:48:fe:d3:75:64:d0:c9:c9:
                    76:27:72:0f:a9:96:1a:3b:81:f3:14:f6:ae:90:56:
                    e7:19:d2:73:68:a7:85:a4:ae:ca:24:14:30:00:ba:
                    e8:36:5d:81:73:3a:71:05:8f:b1:af:11:87:da:5c:
                    f1:3e:bf:53:51:84:6f:44:0e:b7:e8:26:d7:2f:b2:
                    6f:f2:f2:5d:df:a7:cf:8c:a5:e9:1e:6f:30:48:94:
                    21:0b:01:ad:ba:0e:71:01:0d:10:ef:bf:ee:2c:d3:
                    8d:fe:54:a8:fe:d3:97:8f:cb
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication, Netscape Server Gated Crypto
            X509v3 CRL Distribution Points:
                URI:http://crl.thawte.com/ThawteSGCCA.crl

            Authority Information Access:
                OCSP - URI:http://ocsp.thawte.com
                CA Issuers - URI:http://www.thawte.com/repository/Thawte_SGC_CA.crt

            X509v3 Basic Constraints: critical
                CA:FALSE
    Signature Algorithm: md5WithRSAEncryption
        57:4b:bc:a4:43:e7:e0:01:92:a0:96:35:f9:18:08:88:1d:7b:
        70:19:8f:f9:36:b2:05:3a:05:ca:14:59:4d:24:0e:e5:8a:af:
        4e:87:5a:f7:1c:2a:96:8f:cb:61:40:9e:d2:b4:38:40:21:24:
        c1:4f:1f:cb:13:4a:8f:95:02:df:91:3d:d6:40:eb:11:6f:9b:
        10:a1:6f:ce:91:5e:30:f6:6d:13:5e:15:a4:2e:c2:18:9e:00:
        c3:d8:32:67:47:fc:b8:1e:9a:d9:9a:8e:cc:ff:7c:12:b7:03:
        bf:52:20:cf:21:f4:f3:77:dd:12:15:f0:94:fa:90:d5:e3:59:
        68:81

Identité du propriétaire

Numéro de série du certificat

Nécessaire à la CRL ('certification revocation list)

Identification de l'émetteur du certificat

Date de début de validité du certificat

Validation de la CA émettrice du certificat

openssl verify -CAfile CA1_crt.pem client_crt.pem
client_crt.pem: OK

Validation du rôle du certificat

openssl verify -CAfile CA1_crt.pem -purpose sslclient client_crt.pem
client_crt.pem: OK

Le certificat est-il autosigné ?

openssl verify -CAfile google.crt google.crt
google.crt: /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
error 20 at 0 depth lookup:unable to get local issuer certificate

openssl verify -CAfile "Verisignroot.cer" "Verisign root.cer"
Verisign root.cer: OK

4. Divers

Connexion manuelle à un serveur HTTPS

Si pour se connecter à une serveur HTTP, une connexion telnet sur le port 80 suffit, se connecter en ligne de commande à un serveur HTTPS reste possible grâce à OpenSSL. Ci-dessous, un exemple de GET aveugle sur https://www.google.fr :

 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
   i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority

    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: D596685E782544409A2AAA0209CB1DC93C9136FA7BD704E9F6E2CF9034F5ED3A
    Session-ID-ctx:
    Master-Key: DD3B0CDF8BCC32ECFB9AF7B97AB46CCF2D731E929B0048444D62EA45486774E74F23FF950F3BBBE0992AFED425413FBA
    Key-Arg   : None
    Start Time: 1169126487
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)

On remarquera que le CN du certificat retourné par le serveur Web de Google (https://www.google.com) ne correspond pas à l'URL accédée ce qui générerait une alerte dans un navigateur web

Génération d'un mot de passe aléatoire

openssl rand 15 -base64
Loading 'screen' into random state - done
6TMCLEgKG4JFot/XFETj

5. Signature de fichiers

Signature au format hexadécimale d'un fichier avec un certificat

openssl dgst -hex -sha1 -sign client_pvk.pem -out test.sha1 C:\archive.zip
Enter pass phrase for client_pvk.pem:

Nous obtenons alors un fichier contenant ceci :

SHA1(C:\archive.zip)= 3a5bf992899216c320835e98b700a1e669c1716e9145c4e2fec91eb3ee473d3d3d1dc264
e139f6bffc76d4d00e2cac6c6687e7d53613c94f0ca866334f9d6d43bfeb23a0d1bd51af8f500d129146d2a83d58c
b4051f112805beb7519489abd79f75d4878f834005631f5c59b5fbbcd0ecb391c5a9f1dbdcef1f9d2f287cd3e41

A noter que le format hex n'est pas supporté par la méthode verify, la signature devra être au format binaire.

Signature au format binaire d'un fichier avec un certificat

openssl dgst -sha1 -sign client_pvk.pem -out test.sha1 C:\archive.zip

Extraction de la clef publique contenue dans le certificat

openssl x509 -in client_crt.pem -pubkey -noout > client_pub.pem

La clef publique étant extraite du certificat, il ne sera pas nécessaire de la fournir avec le fichier de signature

Vérification de la concordance fichier / clef publique

openssl dgst -sha1 -verify client_pub.pem -signature test.sha1 C:\archive.zip
Verified OK ou Verification Failure

vous obtenez un unable to load key file si vous utilisez un certificat au lieu d'une clef publique

Nous en concluons que le fichier a été signé par le propriétaire du certificat et qu'il n'a pas été modifié depuis.
Nous devons maintenant vérifier le contenu du certificat.

L'identité de son propriétaire

openssl x509 -in pubcert2.pem -noout -subject
subject= /C=FR/ST=FRANCE/O=Le nom du client/OU=Service/CN=www.test.com/emailAddress=monemail@test.com

L'identité de l'émetteur du certificat

openssl x509 -in pubcert2.pem -noout -issuer
issuer= /C=FR/ST=France/L=Lille/O=Domain Public Primary Certification autority/OU=www.grandville.net/CN=cdn/emailAddress=nospam_autority@remove_grandville.net

6. Chiffrement par clef symétrique

Le chiffrement par clef symétrique est aujourd'hui le seul moyen performant pour la protection des données. [ la suite ]

7. Chiffrement par clef asymétrique

Le but est ici de rendre illisible le contenu d'un fichier par un algorythme à sens unique dont la spécificité est de permettre à tout le monde le chiffrement de ces données tout en ne permettant le déchiffrement qu'au seul destinatataire.

S'agissant d'un chiffrement par bloc, la quantité de données chiffrables par la clef est limitée à la taille de la clef moins la taille nécessaire à la déclaration du padding.
La taille de la clef RSA est de 1024 bits, petite vérification :

1024 bits, est-ce une taille acceptable pour le chiffrement de mes données ?
Oui car 2^1024 est un chiffre absolument gigantesque, un exemple pour en caresser l'idée.
Par an, en France, entre 10 et 30 personnes meurent foudroyées ce qui correspond à une probabilité inverse de 2^21
La probabilité qu'une de ces mêmes personnes gagne à l'euromillion LE MEME JOUR n'est que de 2^46
Nous sommes encore bien loin du compte car 46 est largement plus petit que 1024.
Remarquons au passage que les dernières estimations de l'âge de l'univers sont de 2^59 secondes (13.7x10^9 années)...
Maintenant que nous sommes rassurés sur la taille et donc la complexité de notre clef de chiffrement, voyons comment l'utiliser.

Rappellons que des clefs de 1024 bits ne peuvent chiffrer qu'un bloc de données au maximum égal à 128 (1024/8 octets) caractères moins le padding.

Chiffrer 128 octets de données avec un certificat 1024 bits

Le chiffrement d'un bloc de données d'exactement 128 octets avec une clef 1024 bits ne pose pas de problème leurs tailles sont les mêmes.

On obtient une erreur
RSA operation error
816:error:0406B07A:rsa routines:RSA_padding_add_none:data too small for key size:.\crypto\rsa\rsa_none.c:76:
error in rsautl
si le fichier à chiffrer fait moins de 128 caractères car nous avons précisé qu'il ne faut pas utiliser de padding (-raw) et
816:error:0406B06E:rsa routines:RSA_padding_add_none:data too large for key size:.\crypto\rsa\rsa_none.c:70:
si le fichier à crypter est d'une taille supérieure à la clef

Chiffrer 128 octets de données (ou moins) avec un certificat

Pour un bloc de données de taille inférieure à la taille de la clef, la commande à utiliser sera

Sans paramètre, le padding sera PKCS#1 v1.5, les tailles de données cryptables en fonction des padding sont les suivantes :
http://www.openssl.org/docs/crypto/RSA_public_encrypt.html
- exactement 128 octets si pas de padding (-raw)
- moins de 117 octets pour un padding PKCS #1 v1.5 ou SSL (-pkcs, -ssl)
- moins de 87 octets pour un padding PKCS#1 OAEP (-oaep)

Déchiffrer un bloc de données cryptées

La déchiffrement se fait uniquement avec la clef privée du certificat, le type de padding doit être indiqué et biensûr ne peut être deviné !

Utilisation du chiffrement asymétrique

Dans la pratique, les données à transférer sont cryptées avec une clef symétrique pour passer outre la limitation des 128 octets et c'est cette clef symétrique protégée par le chiffrement asymétrique qui est envoyée avec les données sécurisées au destinataire. Cette méthode accélére grandement le processus de chiffrage car ce travail sur les clefs asymétriques est environ 500 fois plus couteux que le même travail sur des clefs symétriques.
Voici un test de performance :

 The 'numbers' are in 1000s of bytes per second processed.
 type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
 aes-128 cbc      47866.52k    48210.39k    48913.17k    49207.26k    48419.09k
                  sign    verify    sign/s verify/s
 rsa 1024 bits 0.011421s 0.000544s     87.6   1838.3

Le chiffrement avec une clef asymétrique est 49207/87 = 565 fois plus couteux en temps processeur qu'un chiffrement symétrique AES-CBC.

Exemple de chiffrement d'un fichier

Commençons par chiffrer le fichier avec une clef symétrique et protégeons cette clef avec le ou les certificats des destinataires.
Après avoir généré les certificats de chaque destinataire, générons une clef symétrique

Le fichier pass.txt contient maintenant une chaine de caractères au format Base64 qui sera la clef de chiffrement symétrique.

Chiffrons le fichier archive.rar.

Chiffrons la clef de déchiffrement.

Précisons qu'il n'est pas nécessaire de connaitre la clef privée pour protéger les données à envoyer.
La clef de déchiffrement est maintenant irrémédiablement cryptée avec la clef publique du certificat du destinataire (client1_crt.pem).

Le destinataire recevra ces fichiers :
- archive.rar.enc
- pass.client1.enc

Procédure de déchiffrement

Le fichier archive.rar est maintenant lisible.

8. Format S/MIME

c'est par ici

9. Structure binaire des certificats

Un certificat X509 v3 est un fichier binaire dont la structure est définie par la RFC2459... [ la suite ]