Master ICONE Université de la Rochelle Cryptologie / PKI

TP 2 – Cryptologie, SSL, PKI et Apache

Ce TP consiste en un enchaînement de différents outils informatiques que vous devrez mettre en

place pour présenter une approche de type PKI (Public Key Infrastructure). Vous allez donc
apprendre à :
• Créer un certificat x509 auto-signé
• Récupérer, visualiser et transcoder un certificat
• Tester une liaison SSL
• Créer une Autorité de Certification (CA) et signer des certificats
• La sécurisation d’une page web avec Apache

1. Mise en place de l’infrastructure globale

Afin de mener à bien ce TP, vous allez devoir mettre en place une architecture virtuelle composée de
deux serveurs virtuels et de votre machine hôte. Pour cela vous devez :
Q1. Créer 2 machines virtuelles sous ubuntu server 14.04 LTS (fichier iso disponible sur moodle)
a. La première machine vous servira de serveur Apache et de Certification Authority
(CA)
Q2. Configurez les machines pour qu’elles soient sur le même réseau local (réseau privé hôte)
a. Si ce n’est déjà fait, attribuez des adresses IP qui vont bien

N’installez pas 2 fois l’OS sur les VM, pensez à faire un clone de la première. Enfin, il est possible
d’installer OpenSSL et Apache directement lors de l’installation du système (choisissez openssl et
LAMP dans le menu concerné lors de l’installation).

2. Créer un certificat x509 auto-signé

Un certificat est un document qui comprend essentiellement une clé publique et des renseignements
sur le propriétaire de cette clé, le tout signé avec la clé privée d’un organisme reconnu, un CA
(Certification Authority).
Un certificat permet de dialoguer de manière sûre (chiffrée) avec la personne ou la société qu’il
décrit. Si l’on possède le certificat du signataire (CA) et que l’on a confiance en lui, on a l’assurance
de l’identité du propriétaire de la clé.
Q1. Le logiciel firefox contient plusieurs certificats de CA, dont celui de la société Verisign.
Affichez le.
Firefox -> Préférences -> Avancé -> Certificats

1
Master ICONE Université de la Rochelle Cryptologie / PKI

Il y en a plusieurs de disponibles

L’ISO a établi un protocole, baptisé x509, permettant l’authentification sur un réseau. Ce protocole
utilise des certificats au format normalisé : x509. Ces certificats ont été utilisés au début pour la
sécurisation du courrier électronique dans le cadre du protocole PEM (Privacy Enhanced Mail),
l’ancêtre de S/MIME. Maintenant ils sont utilisés aussi bien dans la sécurisation du Web (via SSL) que
dans bien d’autres domaines. Les différents champs présents dans un certificat sont les suivants :
1. La version
2. Le numéro de série du certificat
3. L’algorithme utilisé pour la signature du certificat
4. L’organisme émetteur du certificat
5. La période de validité
6. Le sujet (nom, prénom, organisation, ….)
7. La clé publique du détenteur du certificat
8. La signature de l’émetteur

Les certificats sont stockés dans des fichiers, et les formats les plus courants sont :
DER Le format DER, de l’OSI, est le format binaire qui traduit l’ASN.1
PEM Format ASCII, codé en Base64. Le texte est encadré de lignes « BEGIN
CERTIFICATE » et « END CERTIFICATE »
PKCS#7 Le standard RSA est principalement utilisé pour les certificats des utilisateurs. Un
fichier PKCS#7 contient non seulement le certificat d’un utilisateur mais aussi sa
clé privée normalement protégée par un mot de passe.

La description du sujet (possesseur de la clé publique) et du CA peuvent utiliser des abréviations

suivantes :
• C (Country) : pays
• S (State) ou P (Province) : état ou province
• L (Locality) : ville
• (organization) : société
• OU (Organization Unit) : le service
• CN (Common Name) : le nom du sujet ou l’adresse DNS du serveur

2
Master ICONE Université de la Rochelle Cryptologie / PKI

• E (E-mail) : adresse e-mail

Un certificat d’un CA intermédiaire peut signer d’autres certificats. Mais il est lui-même signé par un
CA hiérarchiquement supérieur, et ainsi de suite. Au sommet de cette pyramide, il y a les certificats
des CA racines qui sont auto signés : le sujet et le signataire sont les mêmes.

Q2. A partir de la documentation fournie sur Moodle pour la commande « openssl x509 »,
visualiser le contenu d’un certificat
openssl x509 –in fichierCertificat –text –noout

Vous allez maintenant créer un certificat x509 auto-signé

Q3. Créez un couple de clés publique/privée à partir de la fonction « openssl genrsa » en vous
aidant de la documentation fournie sur Moodle
Cf documentation : openssl genrsa -out server.key 1024
Q4. Appliquez cette commande sur votre clé :
chmod 440 server.key
A quoi sert-elle ?
Q5. Créer une requête de certificat. Un certain nombre d’informations vous seront demandées.
La plus importante est le Common Name pour laquelle Il faut saisir le FQDN (adresse IP dans
votre cas) du serveur pour lequel est destiné le certificat. Visualisez la requête
openssl req -new -key server.key -out server.req
vi server.req
Q6. Le certificat est normalement créé par un CA quand il signe la requête avec sa clé privée.
Dans le cas d’un certificat auto-signé, c’est le même organisme qui crée la requête qui la
signe. Appliquez la commande suivante pour créer le certificat :
openssl x509 -req -days 365 -in server.req -signkey server.key -out server.crt

A quoi correspondent les paramètres ? Affichez le certificat que vous venez de créer

Vous allez maintenant apprendre à visualiser et transcoder un certificat :

Q7. Saisissez le script retreive-cert.sh ci-dessous
- vi retrieve-cert.sh
# !/bin/sh
# usage : retrieve-cert.sh remote.host.name [port]
REMHOST=$1
REMPORT=${2:-443}
echo |\
openssl s_client -connect ${REMHOST}:${REMPORT} 2>&1 |\
sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'

Q8. A partir du script ci-dessus, récupérez un certificat et affichez-le (exemple de site : apps.univ-
lr.fr).
sh retrieve-cert.sh apps.univ-lr.fr > univ.pem

vi univ.pem
Q9. Que fait le script ?
Récupère le certificat et ne garde que le certificat
Q10.Visualiser un certificat qui est au format PEM
openssl x509 -in univ.pem –text –noout | more
Q11.Convertir un certificat d’un format en un autre (ici de PEM à DER)
openssl x509 –inform PEM -in univ.pem –outform DER –out univ.der
Q12.Visualiser un certificat qui est au format DER.

3
Master ICONE Université de la Rochelle Cryptologie / PKI

openssl x509 -inform DER -in univ.der -text | head

3. Tester une liaison SSL

Vous allez maintenant tester une liaison SSL à partir d’un de vos serveurs. Pour cela :
Q1. Activer le serveur de test avec la commande suivante :
openssl s_server -accept 5000 -cert server.crt -key server.key -www -state

On donne en argument le port d’écoute (ici 5000) ainsi que le chemin du certificat et de la clé
privée. Visualisez les informations après une connexion en local avec un navigateur. (Ctrl-C
pour mettre fin au serveur - https://localhost:5000 en local)

Q2. Que signifie le message d'avertissement ?

Q3. Visualisez le certificat à travers le navigateur. Retrouvez les informations saisies lors de la
création du certificat (exercice précédent)

Q4. Tester l’accès à partir d’un client (votre hôte ou l’autre VM)
a. lynx https://localhost:5000
b. wget --no-proxy ‘https://localhost:5000’
c. wget --no-proxy --no-check-certificate ‘https://localhost:5000’

Q5. Analyser et discuter des informations affichées (vérifiez avec votre adresse IP à la place de
localhost).

Q6. Affichez la trace d’une session SSL avec le client de test

openssl s_client@ -connect localhost:5000

puis

GET / HTTP/1.0

Q7. Accéder à un site SSL présent sur Internet avec le programme de test
openssl s_ client –connect apps.univ-lr.fr:443
Vous devez avoir le message Verify return code 0 ok. Puis tapez la commande
GET / HTTP/1.0
et deux fois entrée

Q8. Activer un serveur SSL n’utilisant que le protocole Diffie-Hellman

openssl s_server -accept 5000 -nocert -www –state
Q9. Essayer de vous connecter à partir d’un client et analysez les messages apparaissant sur
l’écran de l’ordinateur

4. Créer un CA et signer des certificats

Dés que l'on souhaite mettre en oeuvre une connection cryptée par SSL (comme pour Apache –
HTTPS par exemple), il est nécessaire d'avoir un certificat. Ce certificat installé sur le serveur contient
une paire de clef qui va permettre aux deux parties de mettre en place un échange chiffré. Une des
informations échangée à ce stade est une autre clef qui va servir quant à elle à chiffrer, par un
algorithme dit "symétrique", le reste de la communication. La raison de ce changement de clef tient à

4
Master ICONE Université de la Rochelle Cryptologie / PKI

ce que le chiffrement asymétrique est plus demandeur en ressources, mais aussi plus sécurisé, que
sa contrepartie symétrique. Ce protocole permet en quelque sorte d'arriver au meilleur des deux
mondes.

Un certificat peut très facilement être généré en utilisant les outils du paquet openssl. Mais pour
qu'un certificat serveur soit déclaré valide sur le client il doit répondre à trois règles, et tout
manquement à l'une de ces règles entraîne l'affichage d'un message d'avertissement sur le
navigateur client :
1. Le certificat doit contenir le nom du site qu'il sécurise (ex. www.mon_site.fr). Si ce n'est pas
le cas, le navigateur protestera que le certificat ne provient pas de la bonne adresse
2. Le certificat doit contenir une signature fiable. Si ce n'est pas le cas, certains navigateurs se
contenterons de vous le signaler, d'autres, comme FireFox, bloqueront l'accès avec un
signature invalide
3. Le certificat doit être signé par une CA (Autorité de Certification) ou par un certificat qui lui
même est signée par une CA. C'est ce point que nous allons traiter ci-dessous

Une autorité de certification est un service proposé et donc les fichiers de ce services doivent être
hébergés sur votre serveur. Nous allons modestement faire notre petite PKI (Private Key
Infrastructure) qui va nous permettre de générer et de signer à la chaîne nos certificats.
Il est important de préciser que cette PKI est « modeste » puisqu’une vraie PKI est composée d’un
ensemble complexe comprenant non seulement la génération des certificats, mais aussi et entre
autre leur révocation. Cependant, nous disposerons bientôt d'une mini-pki avec son AC et sa base de
certificats ce qui n'est déjà pas si mal.

Première étape créer un dossier qui contiendra nos données, disons /root/pki, et la base de données
des certificats. Afin de garantir la sécurité de ces fichiers (configuration, certificats validés, clé privée,
…), il est important de placer ces fichiers dans un répertoire sûr :
# Création de l'infrastructure
mkdir /root/pki
cd /root/pki
mkdir -p db/ca.db.certs
mkdir config
mkdir certificats

# Initialisation des numéros de séries à 1

echo '01'> db/ca.db.serial

# Initialisation de l'index des certificats

cp /dev/null db/ca.db.index

Q1. Pourquoi faut-il éviter les fuites / failles de sécurité sur ce dossier ?
Car sinon n’importe qui pourrait créer des certificats au nom de l’entité
responsable du serveur et il n’y aurait donc plus de confiance dans le tiers

Maintenant nous allons créer le fichier de configuration config/ca.config qui va permettre à

openssl d'utiliser notre nouvelle base :

[ ca ]
default_ca = CA_own

[ CA_own ]
dir = /root/pki/db
certs = /root/pki/db
new_certs_dir = /root/pki/db/ca.db.certs

5
Master ICONE Université de la Rochelle Cryptologie / PKI

database = /root/pki/db/ca.db.index
serial = /root/pki/db/ca.db.serial
RANDFILE = /root/pki/db/ca.db.rand
certificate = /root/pki/certificats/ca.crt
private_key = /root/pki/certificats/ca.key
default_days = 3000
default_crl_days = 30
default_md = md5
preserve = no
policy = policy_anything

[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

Q2. Maintenant que votre serveur est en place, vous allez générer la clef privée de votre CA
openssl genrsa -des3 -out certificats/ca.key 1024
Q3. La clef de votre CA étant générée, vous allons créer un certificat "auto-signé" valable pour
3000 jours
openssl req -utf8 -new -x509 -days 3000 -key certificats/ca.key -out
certificats/ca.crt

Les informations rentrées ici ont une très grande importance (tout du moins le seraient si vous deviez
faire une vraie CA). Pensez donc à les compléter de manière la plus crédible possible.

A ce stade, votre CA est complète. Vous allez maintenant devoir générer le fichier de certificat
(fichier "DER") à fournir aux clients (navigateur web entre autres) pour que la 3ième règle soit
satisfaite et que le client n’affiche pas de message d’erreur pour tous les futurs certificats générés.

openssl x509 -in certificats/ca.crt -outform DER -out certificats/ca.der

Le fichier « ca.der » est le seul fichier que vous donnerez aux utilisateurs. Tout le reste doit rester
strictement privé !!
Vous avez maintenant une pki fonctionnelle, et il ne vous reste plus qu'à la tester en générant votre
premier certificat serveur.
Pour avoir un certificat en règle, vous devez d'abord générer une clef
openssl genrsa -out certificats/https.www.monsite.fr.key 1024

Afin de pouvoir faire signer votre certificat, vous allez devoir générer un ficher intermédiaire appelé
Certificate Signature Request (CSR ou Demande de Signature de Certificat). Ce fichier contient déjà
tout ce qu'un certificat contiendra sauf la signature du CA. C'est là qu'intervient le tiers de confiance
qui, en signant votre demande de certificat, vous permet d'obtenir en retour un certificat valide. La
seule chose que vous devez donner comme information est le nom de la machine. C'est très
important car sans cela, vous violeriez la règle n°2 donnée plus haut.
openssl req -days 365 -new -key certificats/https.www.monsite.fr.key -out
certificats/https.www.monsite.fr.csr

Enfin, la dernière étape consiste à faire valider votre demande et d’utiliser votre PKI et votre CA pour
signer tout cela et obtenir votre certificat final :

6
Master ICONE Université de la Rochelle Cryptologie / PKI

openssl ca -config config/ca.config -out https.www.monsite.fr.crt -infiles

certificats/ https.www.monsite.fr.csr

Q4. Voilà, vous avez maintenant un certificat tout neuf. Vérifiez son contenu comme vu dans les
exercices précédents.
openssl x509 -text -in certificats/https.www.casimir.fr.crt

5. Sécurisation d’une page web avec Apache et OpenSSL

Maintenant que vous avez créé des certificats qui sont validés par votre propre PKI, vous allez mettre
tout cela en place pour pouvoir diffuser une page web sécurisée (HTTPS). Pour que le protocole SSL
puisse fonctionner avec le Serveur HTTP Apache2, il faut activer le module ssl avec la commande :
sudo a2enmod ssl

puis recharger la configuration d'Apache2 faites :

sudo service apache2 force-reload

Il va maintenant vous falloir configurer Apache pour écouter à la fois sur le port 80 et sur le port 443
(https). Une façon simple de faire cela consiste à créer un hôte virtuel dédié aux accès sécurisés. Pour
cela :
Q1. Allez dans le dossier de configuration des sites apache
cd /etc/apache2/sites-available/
Q2. Recopier la configuration par défaut pour la nouvelle configuration ssl
sudo cp default ssl
Q3. Assigner le port ssl (sudo sed -i '1,2s/\*:80/*:443/' ssl)
Q4. Ajouter les directives SSLEngine On et SSLCertificateFile
/etc/ssl/private/localhost.pem à votre fichier de configuration créé à la question 2
(attention, il vous faudra adapter la valeur de la second directive à votre cas)
Q5. Activer la configuration du site ssl : sudo a2ensite ssl

Q6. Testez l’accès à votre page d‘accueil depuis un terminal et un navigateur web en http et en
https et ce depuis votre hôte et depuis l’autre VM

Q7. Téléchargez le certificat et consultez-le

Q8. Faites en sorte que seul la partie https soit accessible

Q9. Supprimer les messages d''avertissement dû à un certificat auto-signé. En effet, lorsque vous
vous connectez à partir d'un poste distant sur le serveur web, vous rencontrez un message
d'avertissement précisant que le certificat du serveur est auto-signé, et qu'il n'est pas
conseillé de vous y connecter. Proposez une solution pour supprimer cet avertissement et
réalisez-là. Dans quelle mesure cette solution ne pose pas de problème de sécurité ?