MINISTERE DE L’INTERIEUR

PROVINCE DE SEFROU

PKI
Avec

Réalisé par : Encadré par :

Souha Hmamed Mr. Nasredine Boujmil

1|Page
Table des matières
Table des illustrations ............................................................................................................... 4
Introduction .............................................................................................................................. 5
Historique du chiffrement ........................................................................................................ 6
Transition du cryptage symétrique vers asymétrique ........................................................... 9
Algorithme de chiffrement symétrique .................................................................................11
Cryptage asymétrique ...........................................................................................................14
Fonctionnement .....................................................................................................................15
Génération de clé ...............................................................................................................15
Chiffrement du message ....................................................................................................15
Example de génération de clé avec OpenSSL ................................................................15
Avantage du chiffrement asymétrique ............................................................................17
Inconvénient de l’Algorithme de chiffrement asymétrique ............................................17
Signature numérique : ............................................................................................................18
MD5 : ....................................................................................................................................18
SHA : .....................................................................................................................................18
Les certificats électroniques ..................................................................................................20
Fonctionnement d’une CA : ..............................................................................................24
Risques et menaces que peut confrontée les certificats : ..............................................24
Infrastructure à clés publiques...............................................................................................26
Comment PKI fonctionne ...................................................................................................26
Composante de PKI ............................................................................................................28
Type de chiffrement utilisé par PKI .....................................................................................28
Applications de PKI : ...........................................................................................................29
Hiérarchie d’une PKI : .........................................................................................................31
Défis de PKI : ........................................................................................................................32
PKI open-source : ................................................................................................................34
Phase de test : ........................................................................................................................36
Installation des paquets......................................................................................................36
JAVA .................................................................................................................................36
ANT Apache.....................................................................................................................37

2|Page
 JBoss/Ejbca ......................................................................................................................38
Interface EJBCA ......................................................................................................................42
Conclusion ..............................................................................................................................72
Références : ............................................................................................................................73

3|Page
Table des illustrations

Figure 1: tableau de Vigenère ............................................................................................... 7

Figure 2: Tableau d'Uesugi ...................................................................................................... 8
Figure 3: différence entre DES et AES ....................................................................................12
Figure 4: une chaîne de confiance ......................................................................................23
Figure 5: concept du PKI ........................................................................................................27
Figure 6: hiérarchie de pki à 3 niveaux .................................................................................31

4|Page
Introduction

L'avènement de la technologie numérique a considérablement transformé la manière

dont les organisations gèrent l'authentification et la sécurité des données. Dans ce
contexte, les autorités de certification jouent un rôle vital en fournissant des certificats
numériques permettant d'établir l'identité, de sécuriser les communications et de garantir
l'intégrité des transactions en ligne. Le présent rapport explore en détail le processus
d'installation de l'infrastructure à clés publiques EJBCA (Enterprise JavaBeans Certificate
Authority) au sein de la distribution Ubuntu.

L'objectif de ce rapport est de présenter les étapes réalisées pour mettre en œuvre avec
succès EJBCA, une solution open-source réputée pour sa robustesse et sa flexibilité en
matière de gestion des certificats numériques. Au cours de ce stage, une exploration
approfondie des étapes d'installation, de configuration initiale et de déploiement de
l'autorité de certification sera entreprise, en mettant l'accent sur l'utilisation de la
distribution Ubuntu.

La première section de ce rapport examine les concepts fondamentaux du cryptage et

explique son histoire et son développement à travers les années. Ensuite, une vue
d'ensemble détaillée des types de cryptages et leur domaine d’utilisation sera
présentée, mettant en évidence leur mode de fonctionnement ainsi que leurs
avantages et inconvénients, enfin on parlera des signature numérique et certificats
électroniques ils s’agissent de quoi comment ils sont créés où et comment les intégrés.

La section consécutive se plonge dans les concepts essentiels de l'infrastructure à clés

publiques (PKI) et démontre l'importance vitale des autorités de certification au sein du
domaine de la sécurité numérique. Par la suite, une exploration approfondie d'EJBCA
sera proposée, mettant en lumière ses traits distinctifs ainsi que les bénéfices qu'offre
cette solution en tant qu'alternative open-source pour les infrastructures à clés publiques.

5|Page
Historique du chiffrement

De tous temps, les codes secrets ont été des outils indispensables dans les affaires
politiques, diplomatiques et militaires. Ils ont influencé le destin des peuples et des
armées.

Auparavant, envoyer un message n'était pas aussi simple qu'aujourd'hui, grâce au grand
développement des télécommunications. Les informations étaient échangées de
manière vulnérable d'une personne à une autre, ne garantissant aucune protection.
Cela mettait en danger les secrets, qu'ils soient militaires ou diplomatiques. C'est dans le
but de protéger ces informations que l'idée du chiffrement a vu le jour.

Les premiers chiffrements connus remontent à plus de 3000 ans avec les hiéroglyphes. Ils
étaient considérés comme indéchiffrables jusqu'à la découverte de la pierre de Rosette,
qui contenait le code pour décrypter les écritures des stèles. Elle présentait le même texte
écrit en trois langues : le grec, l'égyptien démotique et l'égyptien classique.

Ensuite, durant l'Antiquité, est apparue la première méthode de cryptage bien connue :
le chiffrement par transposition. L'idée consistait à utiliser un bâton autour duquel une
bande de parchemin était enroulée pour écrire le message. Seule cette bande était
envoyée au destinataire, qui devait posséder un bâton de même épaisseur pour
déchiffrer. Cette méthode consistait à changer l'ordre des lettres en fonction de la clé
partagée entre les entités.

Par la suite, le chiffrement de César est né. Son principe était de substituer chaque lettre
du message original par une autre située à une distance fixe dans l'alphabet. Cette
distance devait être connue par l'expéditeur et le destinataire. Ce chiffrement, appelé
chiffrement par décalage, permettait un maximum de 26 combinaisons.

Cette méthode de décalage fixe était facilement déchiffrable. C'est ainsi qu'a été
introduite une substitution aléatoire, associant chaque lettre de l'alphabet à une autre
lettre, regroupées généralement dans un tableau.

Ensuite, le chiffrement de Vigenère est apparu. Il se base sur un tableau rectangulaire,

connu sous le nom de tableau de Vigenère. Les lignes représentent les lettres de
l'alphabet, les colonnes les alphabets de substitution décalés. Une clé sous forme de
séquence de caractères, généralement des lettres, détermine les décalages pour le
chiffrement.

6|Page
Figure 1: tableau de Vigenère

Dans la même époque, le chiffrement d'Uesugi est créé, semblable à celui de Vigenère.
Il repose sur une table de conversion composée de sept lignes et colonnes, chacune
désignée par un numéro. À l'intérieur, l'alphabet japonais composé de 48 lettres.

7|Page
Figure 2: Tableau d'Uesugi

Durant la Première Guerre mondiale, de nouvelles méthodes ont émergé, comme le

célèbre télégramme Zimmermann, mélange de chiffrement par substitution et
transposition. Le texte était converti en chiffres ou lettres via un tableau de substitution,
puis chiffré par transposition.

C'est aussi l'époque de la naissance du chiffrement ADFGVX, similaire à Vigenère, et de

la machine Enigma, utilisant une méthode de substitution polyalphabétique. La machine
était équipée de rotors comportant les 26 lettres de l'alphabet, d'un "brouilleur" et d'un
pupitre de connexions pour les conversions monophonétiques. Chaque lettre tapée
changeait la position du brouilleur, modifiant la clé de chiffrement à chaque frappe.

8|Page
Transition du cryptage symétrique vers asymétrique

Apres l’époque de la guerre mondiale vient l’ère de l’informatique ou les méthodes de

chiffrement actuelle ont vu le jour. Parmi les algorithmes de chiffrement symétrique les
plus utilisée on cite : DES, AES 3DES et RC4

Parlant du DES, ce dernier représenta pendant les années 70 la méthode de chiffrement

standardisé dans le monde entier vu l’utilisation de la cryptographie à des fins civiles

Le principe de cet algorithme (Data Encryption Standard) repose sur la génération d’une
clé de chiffrement de 64 bits, comprenant 8 bits de parité ajoutés pour obtenir une clé
complète. Ensuite, à partir de cette clé d'origine, 16 sous-clés de 48 bits chacune sont
générées, par des opérations de permutation et de rotation. Le processus de chiffrement
commence en divisant le texte clair de 64 bits en deux blocs de 32 bits : le bloc gauche
et le bloc droit, qui subissent ensuite une permutation initiale pour réorganiser les bits selon
une table de permutation spécifique.

Le chiffrement se poursuit avec 16 rondes identiques, où chaque ronde utilise une sous-
clé différente. Dans chaque ronde, le bloc droit est étendu à 48 bits, combiné avec la
sous-clé de la ronde, puis soumis à des tables de substitution (boîtes S) qui fournissent des
substitutions spécifiques. Le résultat est combiné avec le bloc gauche de la ronde
précédente, et ce processus de combinaison, substitution, et permutation se répète pour
chaque ronde. Après les 16 rondes, les blocs gauche et droit subissent une permutation
finale pour rétablir l'ordre des bits.

Le résultat final est un texte chiffré de 64 bits, obtenu après les étapes de chiffrement. Le
même processus est utilisé pour le déchiffrement, en utilisant les sous-clés dans l'ordre
inverse.

Or, malgré son fort algorithme il fait face à des vulnérabilités comme des attaques à
force brute vu sa clé de chiffrement qui est relativement court et aussi les problèmes de
distribution de clé.

Sachant que le chiffrement et déchiffrement nécessites le partage de la clé secrète

entre les entités communicantes, cependant la distribution de cette dernière de manière
sécurisé pose un problème, surtout si le nombre des parties augmentes, ce qui aura un
impact négatif sur la confidentialité lors des communications des clés, et la divulgation
de cette dernière engendre l’acquisition de l’information

En plus des problèmes d’authentification et d’intégrité, comme mentionné

précédemment ,les informations peuvent êtres interceptés lors de la compromise de la
clé, donc l’attaquant a tous les outils nécessaires pour changer le message le rechiffrer
et l’envoyer au destinataire sans que ce dernier se rend compte du changement

9|Page
C’est ici ou la cryptographie à clé publique dit aussi cryptage asymétrique offre enfin
une solution au problème de la distribution des clés

10 | P a g e
Algorithme de chiffrement symétrique

Il existe de nombreux algorithme de chiffrement symétrique autre que DES dont on peut
citez :

AES (Advanced Encryption Standard) : connu sous le nom de Rijndael est l'algorithme de
chiffrement symétrique le plus couramment utilisé de nos jours. Il a été choisi comme
norme de chiffrement par le gouvernement américain en 2001, et il est devenu un
standard mondial pour sécuriser les données.

Son fonctionnement repose sur une combinaison de quatre étapes essentielles :

La première étape, SubBytes, effectue une substitution non linéaire en remplaçant

chaque octet du bloc de données par un octet correspondant de la table de
substitution S-Box. Cette substitution introduit un degré de confusion dans les données.

La deuxième étape, ShiftRows, opère un décalage de lignes circulaire sur les octets du
bloc. Ce décalage renforce la diffusion des données en évitant la linéarité des structures
originales.

Dans la troisième étape, MixColumns, les colonnes du bloc sont mélangées par le biais
d'opérations mathématiques spécifiques à chaque octet. Cette opération complexe
contribue à la diffusion et à la confusion des données.

Enfin, l'étape AddRoundKey combine le bloc de données avec une clé de tour dérivée
de la clé principale. Ce processus d'ajout par XOR (ou exclusif) garantit que chaque tour
soit influencé par une clé différente, renforçant ainsi la sécurité.

L'ensemble de ces quatre étapes est répété plusieurs fois, en fonction de la longueur de
la clé utilisée - 128, 192 ou 256 bits. La combinaison de ces étapes non linéaires, de
substitutions, de décalages et d'ajouts de clés crée un processus de chiffrement solide
et efficace.

Il est utilisé pour des buts divers, y compris le chiffrement des communications sur Internet,
la protection des données sensibles dans les systèmes informatiques, et la sécurisation
des transactions en ligne.

3DES (Triple Data Encryption Standard) : Le Triple Data Encryption Standard (3DES) est une
version améliorée de DES qui utilise trois passes de chiffrement pour améliorer la sécurité.

1- Chiffrement DES 1 : Les données sont d'abord chiffrées à l'aide de la première clé
DES. Ce premier chiffrement ajoute une couche de sécurité en utilisant
l'algorithme DES classique.

11 | P a g e
 2- Déchiffrement DES 2 : Les données chiffrées de la première étape sont ensuite
déchiffrées en utilisant une deuxième clé DES, inversant ainsi le processus du
premier chiffrement. Ce déchiffrement renforce davantage la sécurité.

3- Chiffrement DES 3 : Les données déchiffrées de la deuxième étape sont finalement

chiffrées à nouveau en utilisant une troisième et dernière clé DES. Ce troisième
chiffrement ajoute une couche supplémentaire de sécurité.

Bien que 3DES soit plus robuste que DES, il est également devenu obsolète en raison de
sa complexité et de ses performances relativement faibles par rapport à AES. Il est donc
généralement déconseillé de l'utiliser dans de nouvelles applications.

Figure 3: différence entre DES et AES

12 | P a g e
Cas d’utilisation du chiffrement symétrique :
En raison de sa rapidité, le cryptage symétrique est largement utilisé pour protéger les
informations dans de nombreux systèmes informatiques modernes où la confidentialité
des données et leur intégrité sont essentielles. Il est utilisé pour sécuriser les
communications réseau entre deux entités qui partagent une clé secrète commune,
assurant ainsi que seuls les destinataires autorisés peuvent déchiffrer les messages. Il est
utilisé aussi pour protéger les données stockées sur des dispositifs de stockage tels que les
disques durs, les clés USB et les cartes mémoire, empêchant tout accès non autorisé aux
informations en cas de vol ou de perte du dispositif. Dans certains systèmes, le
chiffrement symétrique est utilisé pour chiffrer les e-mails afin d'assurer leur confidentialité
pendant leur transit. De plus, il joue un rôle essentiel dans l'authentification et la
protection d'accès, sécurisant les informations d'identification.

13 | P a g e
Cryptage asymétrique

Nommer également cryptage a clé publique, ce type de chiffrement vient pour fortifier
le chiffrement symétrique et résoudre les problèmes de gestion des clés, contrairement
au chiffrement symétrique ce type de chiffrement utilise une paire de clé : publique et
privée

Cette innovation (révolution ?) a été révélé en 1976 par Whitfield Diffie, Martin Hellman
et Ralph Merkle, elle repose sur l’idée de chiffrement par clé publique de l’expéditeur
qui est publiée dans des annuaire et déchiffrement par la clé privé unique à chaque

En pratique, pour utiliser ces algorithmes, il faut générer un couple de clés (l’une pour
chiffrer, l’autre pour déchiffrer) pour chaque utilisateur. La personne le fera elle-même à
l'aide d'algorithmes de cryptographie qui reposent sur des problèmes mathématiques
difficiles à résoudre ou quelqu’un de confiance le fera pour elle.
Ainsi la clé privée est généralement stockée de manière sécurisée sur le système
informatique où elle est utilisée. Elle peut être conservée dans des fichiers locaux avec
des permissions d'accès appropriées, garantissant ainsi que seuls les utilisateurs autorisés
peuvent la consulter. De plus, elle peut être protégée par un mot de passe. Dans certains
cas, les clés asymétriques peuvent être stockées dans des modules de sécurité matériels
(HSM1).

A l’inverse, la clé de chiffrement publique va être diffuser le plus largement possible. On

la trouvera dans des annuaires2

Toutefois, ce n’est qu’avec l’apparition de l’algorithme RSA que l’on put passer de la
théorie à la pratique.
L’appellation RSA correspond aux initiales des noms de famille des trois chercheurs
Ronald L. Rivest, Adi Shamir et Leonard M. Adleman, ce dernier peut être utiliser soit pour
le chiffrement où la signature numérique

Lorsqu’on parle du chiffrement on désigne deux partie fondamental génération de clés

et cryptage du message

1 HSM : Hardware Security Module est un dispositif matériel spécialisé qui sécurise et gère les clés
de chiffrement, offrant une protection renforcée pour les opérations cryptographiques sensibles
2 Annuaire : une base de données centralisée qui agit comme un référentiel de données

permettant de rechercher, d'accéder et de gérer ces informations de manière efficace.

14 | P a g e
Fonctionnement
Génération de clé

Tout d'abord, on sélectionne deux grands nombres premiers, p et q. Ces nombres doivent
être soigneusement choisis pour un meilleur niveau de sécurité. Ensuite, on multiplie ces
nombres pour obtenir n, qui est utilisé comme le modulo pour le chiffrement et le
déchiffrement.

Ensuite, on choisit un nombre e inférieur à n, tel que n soit relativement premier à (p - 1)

x (q - 1). Cela signifie que e et (p - 1) x (q - 1) n'ont aucun facteur commun autre que 1.
On choisit e de manière à ce qu'il soit premier avec φ (n), où φ (n) représente la fonction
d'Euler de n.

Chiffrement du message

Maintenant, nous avons notre clé publique, qui est représentée par la paire <e, n>. Cette
clé publique est distribuée largement et est utilisée par n'importe qui pour chiffrer des
messages destinés au détenteur de la clé privée correspondante.

Pour chiffrer un message en clair m avec la clé publique <e, n>, on applique l'opération
m^e mod n. Cela produit le texte chiffré C, qui peut être envoyé en toute sécurité sans
révéler le contenu du message d'origine.

Pour déchiffrer le texte chiffré C et retrouver le message en clair m, le détenteur de la clé

privée <d, n> utilise l'opération c^d mod n. La clé privée d est soigneusement calculée
de manière à inverser l'opération de chiffrement, permettant ainsi de récupérer le
message d'origine.

Example de génération de clé avec OpenSSL

- Génération de clé privé protéger avec mot de passe

15 | P a g e
- Extraction de clé publique à partir de la clé privée

- chiffrement d’un fichier à l’aide de openSSL :

16 | P a g e
Avantage du chiffrement asymétrique :

- Signature numérique : assure l’authenticité et l’intégrité des messages. Le

destinataire peut alors utiliser la clé publique de l’expéditeur pour vérifier la signature
et s’assurer de l’origine légitime du message.
- Gestion d’identité et d’accès : Le chiffrement asymétrique joue un rôle crucial dans
la gestion d’identité et d’accès. Les certificats numériques, qui contiennent des clés
publiques associées à des identités, permettent de vérifier l’authenticité d’une
personne ou d’un service. Cela est essentiel pour garantir que les utilisateurs autorisés
accèdent aux ressources appropriées et pour prévenir les attaques d’usurpation
d’identité.
- Sécurisation des transactions en ligne : Dans le domaine du commerce électronique
et des transactions en ligne, le chiffrement asymétrique est utilisé pour sécuriser les
informations sensibles telles que les données de paiement. Les protocoles SSL/TLS,
basés sur des clés publiques et privées, chiffrent les communications entre les
utilisateurs et les sites web, garantissant la confidentialité et empêchant les
interceptions malveillantes.

Malgré ses avantages, le chiffrement asymétrique est plus lent que le chiffrement
symétrique en raison de la complexité mathématique impliquée. C’est pourquoi il est
souvent utilisé en combinaison avec le chiffrement symétrique dans des méthodes de
chiffrement hybrides, pour bénéficier à la fois de la sécurité du chiffrement asymétrique
et de la rapidité du chiffrement symétrique.

Inconvénient de l’Algorithme de chiffrement asymétrique :

- Taille des clés : Les clés asymétriques sont généralement plus longues que les clés
symétriques pour offrir un niveau équivalent de sécurité. Cela peut augmenter les
exigences en matière de stockage et de bande passante, en particulier lors de
l’échange de clés publiques.

- Vulnérabilité aux attaques par force brute : Contrairement au chiffrement

symétrique, où une clé unique est utilisée, le chiffrement asymétrique repose sur une
paire de clés. Si la clé privée est compromise, l’attaquant peut tenter des attaques
par force brute pour retrouver la clé correspondante, ce qui rend essentiel de
protéger la clé privée avec soin.

- Nécessité d’une infrastructure de clés publiques (PKI) : Pour garantir l’authenticité

des clés publiques et l’intégrité des communications, il est recommandé d’utiliser une
infrastructure de clés publiques (PKI).

17 | P a g e
Signature numérique :

Une signature numérique est une forme électronique équivalente à une signature
manuscrite. C'est un code unique ou une séquence de caractères qui est associé à un
document ou à un autre message électronique dans le but de garantir son authenticité
et son intégrité. Les signatures numériques reposent sur des techniques de cryptographie
pour assurer que la signature ne peut pas être altérée ou falsifiée. Le processus de
création d'une signature numérique implique l'utilisation d'une clé privée, qui est un code
secret uniquement connu du signataire, ainsi que d'une clé publique, qui est un code
largement accessible et utilisé pour vérifier la validité de la signature, et une fonction de
hachage.

La fonction de hachage est un processus à sens unique qui produit une empreinte
distinctive pour un ensemble de données. Si un seul bit du texte original est modifié, la
sortie de la fonction de hachage sera complètement différente. Cette fonction prend
en entrée des données de taille variable et génère une sortie de taille fixe, le résultat est
ensuite chiffré à l’aide de la clé privé du signataire pour créer la signature numérique

Les fonctions les plus connues sont MD5 qui crée une empreinte de 128bits et le SHA

MD5 :
Le MD5(Message Digest Algorithme 5), ou algorithme de hachage MD5, est utilisé pour
traiter l'intégralité des fichiers à travers une procédure mathématique spécifique afin de
créer une signature unique qui peut être comparée avec le fichier original. Cette
comparaison permet de vérifier que le fichier reçu n’a pas subi des changements lors de
sa transmission, garantissant ainsi que les fichiers sont correctement acheminés vers leur
destination prévue.

L'algorithme MD5 transforme les données en une chaîne de 32 caractères. De manière

similaire, un fichier de 1,2 Go donnera lieu à un hachage comportant le même nombre
de caractères. Lorsque vous transmettez un fichier à votre destinataire, son ordinateur
vérifie l'authenticité du hachage pour s'assurer qu'il correspond à celui que vous avez
envoyé.

SHA :
SHA (Secure Hash Algorithme) est une famille d'algorithmes de hachage
cryptographique utilisés pour transformer des données en une valeur de hachage
unique. Ces valeurs de hachage servent à vérifier l'intégrité et l'authenticité des données,
garantissant qu'aucune altération n'a eu lieu. Les différentes versions de SHA, telles que
SHA-1, SHA-256 et SHA-512, offrent des tailles de hachage et des niveaux de sécurité
variables. Les versions plus récentes, comme SHA-256 et SHA-512, sont préférées pour leur

18 | P a g e
résistance aux attaques cryptographiques et sont largement utilisées dans diverses
applications de sécurité informatique.

--Pour crée une signature numérique le signataire doit initialement créer une paire de
clés. La clé privée, gardée confidentielle, demeure exclusive à l'utilisateur, tandis que la
clé publique est partagée avec ceux qui souhaitent vérifier les signatures. Cette création
de clés est souvent réalisée au moyen d'algorithmes tels que RSA ou DSA.

Une fois que les clés ont été établies, ce dernier est prêt à concevoir une signature
numérique. Il commence par générer un hachage du message qu'il a l'intention de
signer, à partir du contenu du document ou du message.

Ensuite, le signataire chiffre ce hachage avec sa clé privée pour créer la signature
numérique. Cette étape garantit que la signature est unique pour ce message
spécifique. La signature numérique ainsi créée est ensuite attachée au document ou au
message d'origine.

Lorsque le destinataire reçoit le document avec la signature numérique, il peut effectuer

le processus inverse pour vérifier l'authenticité de la signature. Le destinataire utilise la clé
publique du signataire pour déchiffrer la signature numérique, ce qui lui donne le
hachage original du message. Il peut ensuite générer un hachage du message reçu et
comparer les deux hachages. Si les hachages correspondent, cela signifie que le
document n'a pas été altéré et que la signature est valide. Cela prouve également que
le document provient du signataire dont la clé publique a été utilisée pour la vérification.

19 | P a g e
Les certificats électroniques :
Comme mentionné précédemment le destinataire déchiffre l’empreinte avec la clé
publique de l’émetteur, or cette clé comme elle est publique, elle peut être trouver de
manière très facile dans les annuaires ou site web. Donc on ne devient plus sur si cette
dernière appartient vraiment à l’émetteur ou non.
C’est pour cela qu’il fallait crée une entité trier pour s’assurer de la validité de cette clé,
à ce moment-là les certificats numériques ressoudent se problème en associons à
chaque clé publique une identité vérifiée par une autorité de certification de confiance.
La même chose en ce qui concerne l’identité de la personne avec laquelle on veut
établir notre connexion est-elle vraiment celle qui assume être ou on a une usurpation
d'identité, dans ce cas les certifs numériques fournissent un mécanisme
d’authentification en liant la clé publique avec une entité vérifiée
• Donc de manière générale un certificat est l’équivalent d’une carte d’identité
comme il est infalsifiable (il est crypté pour empêcher toute modification)
• Nominatif : il est délivré à une entité (comme la carte d’identité est délivrée à une
personne et une seule)
• Certifié : il y a le tampon de l’autorité qui l’a délivré.

Et fournit de nombreuse information dans on peut citez :

• Le nom de l’autorité de certification qui a créé le certif
• Nom de l’entreprise a qui est délivrée le service
• Nom du service
• L’adresse électronique
• Date de validité
• Signature électronique
• Date de validité
• Système cryptographique associé
• Clé publique associée
• Signature de l’autorité de certification

20 | P a g e
1 - quelle sont les rôles du certificats
2 - a qui le certificat est réalisée
3 - par qui le certificat est réalisée
5 - période de validité
21 | P a g e
Les details sur le certifats, cette partie peut
comporter le nom de l’entité a laquelle ce
dernier est attribué, l’emetteur, le numéro de
serie, ca periode de validité, l’mpreinte digital,
la version, la clé publique, les politiques de
certifications(régles qui décrivent comment le
certificats peut être utilisé).
Ici une représentation plus claire de la clé Et enfin l’empreinte du certificat qui permet
publique qui va permettre de chiffrer les au client de s’assurer que le certicats est n’a
informations entre le client et le serveur pas été falsifié

Cependant, pour établir cette confiance, il est nécessaire de passer par des Autorités de
Certification (CA), des entités de confiance responsables de l'émission et de la gestion
de ces certificats. Les CA jouent le rôle de tiers de confiance, elles sont médiatrices entre
les utilisateurs, les serveurs et les systèmes informatiques. Leur mission consiste à vérifier
l’identité des entités demandant un certificat, établir des communications sécurisées et
authentiques en attribuant des certificats numériques aux entités légitimes et attestant
de la validité des informations contenues dans ces certificats. Grâce à ce processus, les
CA créent une chaîne de confiance qui permet aux utilisateurs de vérifier l'authenticité
des certificats et de sécuriser leurs communications en ligne

22 | P a g e
La chaine de confiance repressente une hiérarchie de certificats qui assure la vérification
de l'émetteur d'un certificat en se basant sur une structure de certificats imbriqués. Au
sein de cette chaîne de confiance, les certificats sont émis et signés par des autorités de
certification (AC) qui occupent des positions hiérarchiques différentes.

Elle est composée de :

- L'autorité de certification d'origine (CA) : Cette entité occupe le sommet de la

hiérarchie et émet des certificats racines. Ces certificats racines servent de point de
départ pour la validation des certificats d'autres entités, établissant ainsi la base de
la chaîne de confiance.
- Certificats intermédiaires : Entre la CA racine et les certificats d'entité finale, il existe
au moins un niveau de certificats intermédiaires. Ces certificats agissent comme une
couche d'isolation entre la CA racine et les certificats d'entité finale. Ils permettent
de réduire les risques en cas de compromission d'une clé privée, car seule une partie
de la chaîne serait affectée.
- Certificat d'entité finale : En bas de la chaîne de confiance se trouve le certificat
d'entité finale. Ce certificat est utilisé pour valider l'identité d'une entité spécifique,
qu'il s'agisse d'un site Web, d'une entreprise ou d'une personne. La signature
numérique de ce certificat est basée sur la clé privée de l'autorité émettrice,
confirmant ainsi l'authenticité du certificat et de l'entité qu'il représente.

Figure 4: une chaîne de confiance

23 | P a g e
Fonctionnement d’une CA :

Cela commence généralement par un demandeur qui génère une paire de clés. Le
demandeur envoie ensuite sa demande de signature de certificat, le CSR3, (Certificate
Signing Request) à une autorité de certification de confiance. Le CSR contient toutes les
informations utiles sur le demandeur qui s’afficheront sur le certificat généré, si la
demande est approuvée.

Une fois la demande reçue, l'autorité de certification vérifie l'authenticité des

informations contenues dans le CSR. Lorsque la demande est jugée crédible, l'autorité
de certification émet et attribue un certificat en utilisant sa clé privée, qu’elle transmet
alors au demandeur pour utilisation.

Certaines autorités peuvent également soumettre le demandeur à plusieurs épreuves

visant à s’assurer que ce dernier contrôle effectivement le domaine concerné par la
demande de signature de certificat. Parfois, le demandeur doit signer avec sa clé privée
pour prouver que c’est bien lui qui contrôle la paire de clés. À l’issue de ces épreuves et
une fois la signature confirmée, le demandeur est autorisé à commander, renouveler et
révoquer des certificats pour son site.

À la fin de la procédure, le demandeur peut utiliser le certificat signé pour activer le

protocole approprié

Risques et menaces que peut confrontée les certificats :

Les certificats numériques, bien que jouant un rôle crucial dans la sécurité des
communications en ligne, sont également sujets à certains risques et menaces qui
peuvent compromettre leur intégrité et leur fiabilité.

Parmi ces risques figurent :

- Falsification de Certificats : Les certificats peuvent être falsifiés par des individus
malveillants qui parviennent à générer des certificats frauduleux en se faisant passer
pour une autorité de certification légitime. Cela peut conduire à des attaques de
type man-in-the-middle, où les communications sont interceptées et lues sans que
les parties concernées en soient conscientes.
- Compromission des Clés Privées : Les clés privées associées aux certificats sont
sensibles et doivent être soigneusement protégées. Si une clé privée est volée ou
compromise, un attaquant peut déchiffrer les communications sécurisées ou falsifier
des certificats en utilisant cette clé.
- Autorités de Certification Non Fiables : Les autorités de certification elles-mêmes
peuvent être vulnérables aux attaques. Si une autorité de certification est

3CSR : est une requête générée par une entité ou un individu pour demander à une autorité de
certification (CA) de signer numériquement un certificat

24 | P a g e
 compromise, elle pourrait émettre des certificats non valides ou malveillants, ce qui
peut entraîner la confiance indue envers des entités non dignes de confiance.
- Attaques par Force Brute : Les clés privées utilisées dans les certificats sont générées
avec une certaine longueur de bits pour résister aux attaques par force brute.
Cependant, des avancées dans la puissance de calcul peuvent rendre ces attaques
plus réalisables, surtout si des clés plus faibles sont utilisées.
- Expiration et Révocation de Certificats : Si les certificats ne sont pas correctement
gérés et renouvelés, leur expiration peut entraîner des interruptions dans les
communications sécurisées. De plus, si un certificat doit être révoqué en raison d'une
compromission, il peut être difficile de diffuser cette information efficacement.
- Attaques sur les Infrastructures de Clés Publiques (PKI) : Les infrastructures de clés
publiques centralisent les processus de certification et de gestion des certificats. Si
l'infrastructure est compromise, cela peut avoir un impact majeur sur la sécurité
globale des communications sécurisées.

Ces vulnérabilités soulignent la nécessité de mettre en place des mesures robustes pour
garantir l'authenticité et la sécurité des certificats numériques. C'est ici qu'intervient la
création d'une infrastructure à clés publiques (PKI). La PKI offre une approche systémique
et sécurisée pour relever ces défis.

25 | P a g e
Infrastructure à clés publiques

La PKI (public key infrastructure) est un cadre fondamental qui permet aux utilisateurs et
aux serveurs d'échanger des informations de manière sécurisée au moyen de certificats
numériques. Elle implique un ensemble de composants, comprenant le matériel, le
logiciel, les politiques et les procédures, nécessaires pour crypter les données et
authentifier les certificats. Cette infrastructure repose sur un système de cryptographie
asymétrique à deux clés, comprenant une clé publique et une clé privée. La clé
publique est utilisée pour chiffrer les données et permettre leur vérification par d'autres
entités, tandis que la clé privée est conservée en toute sécurité par l'utilisateur et sert à
déchiffrer les données et à les signer numériquement. La PKI joue un rôle crucial dans des
activités telles que le commerce électronique, les services bancaires en ligne et les
communications confidentielles en fournissant un moyen fiable d'assurer la
confidentialité, l'intégrité et l'authenticité des données échangées sur les réseaux.

Comment PKI fonctionne

La mise en place d'une infrastructure à clés publiques (PKI) repose sur une série d'étapes
clés. Tout d'abord, chaque entité génère sa propre paire de clés asymétriques,
composée d'une clé publique et d'une clé privée. Cette dernière est gardée secrète
tandis que la clé publique est partagée. Une fois prête, l'entité soumet une demande de
certificat en créant un CSR qui contient des informations sur elle-même et sa clé
publique. Cette demande est alors transmise à une autorité de certification (CA).

La CA procède ensuite à la validation et à l'authentification de l'entité. Ce processus

peut impliquer des étapes telles que la vérification d'identité et la collecte de documents
nécessaires. Si l'authentification est réussie, la CA émet un certificat numérique,
contenant les détails de l'entité ainsi que sa clé publique, le tout étant signé
numériquement par la CA elle-même.

Le certificat signé est ensuite publié sur un répertoire ou un serveur de certificats,

accessible aux utilisateurs qui souhaitent vérifier l'authenticité de l'entité. Lorsqu'une
communication sécurisée est nécessaire entre deux entités, elles échangent leurs
certificats et vérifient l'authenticité de chaque certificat en utilisant la clé publique de la
CA émettrice.

Pour sécuriser la communication, les parties utilisent leurs clés privées pour échanger des
clés de session temporaires, utilisées pour chiffrer et déchiffrer les données échangées
pendant la session. Les certificats ont une période de validité et doivent être renouvelés
avant leur expiration. En cas de perte de la clé privée ou d'autres raisons, un certificat

26 | P a g e
peut être révoqué et cette information est enregistrée dans des listes de révocation ou
des bases de données OCSP4.

Figure 5: concept du PKI

4OCSP : Online Certificate Status Protocol, est un protocole de vérification en ligne de l'état des
certificats numériques. Il offre une méthode pour vérifier si un certificat numérique spécifique est
toujours valide et n'a pas été révoqué avant son expiration prévue.

27 | P a g e
Composante de PKI

Les éléments clés d'une infrastructure à clé publique (PKI) typique sont les suivants :

- Autorité de certification (CA) : Une entité de confiance qui fournit la racine de

confiance pour tous les certificats PKI et offre des services pour authentifier l'identité des
individus, des ordinateurs et d'autres entités. Souvent appelées autorités de certification
(AC), ces entités fournissent des garanties concernant les parties identifiées dans un
certificat PKI. Chaque AC possède sa propre AC racine, utilisée uniquement par l'AC.

- Autorité d'enregistrement (RA) : Également appelée AC subordonnée, elle émet des

certificats PKI. L'autorité d'enregistrement (AE) est certifiée par une AC racine et est
autorisée à émettre des certificats pour des utilisations spécifiques autorisées par la
racine.

- Stockage des Certificats : Stocké de manière permanente sur un ordinateur, ou en

mémoire pour les applications ne nécessitant pas de stockage permanent. Le stockage
des certificats permet aux programmes en cours d'exécution sur le système d'accéder
aux certificats stockés, aux listes de révocation de certificats (CRL) et aux listes de
confiance de certificats (CTL).

- Base de données de Certificats : Cette base de données stocke des informations sur les
certificats émis. En plus du certificat lui-même, la base de données inclut la période de
validité et le statut de chaque certificat PKI. La révocation des certificats est effectuée
en mettant à jour cette base de données, qui doit être consultée pour authentifier les
données signées numériquement ou chiffrées avec la clé secrète du détenteur du
certificat.

- Serveur d'Archivage de Clés : Ce serveur enregistre les clés privées chiffrées dans une
base de données de certificats. Il est généralement utilisé à des fins de récupération en
cas de sinistre, en tant que sauvegarde en cas de perte ou endommagement de la base
de données de certificats d'origine.

Type de chiffrement utilisé par PKI

La PKI combine les avantages du chiffrement asymétrique et symétrique. Elle répond à
ces forces et défis en utilisant le chiffrement asymétrique pour l'échange sécurisé de clés,
l'authentification et les signatures numériques, tandis que le chiffrement symétrique est
utilisé pour le cryptage effectif des données afin d'assurer l'efficacité. Cette approche
hybride améliore à la fois la sécurité et les performances dans divers cas d'utilisation, tels
que les communications sécurisées, les transactions numériques et la protection des
données.

28 | P a g e
 Applications de PKI :

La technologie de la PKI a de nombreuses applications dont on peut citer :

Sécurité des Serveurs Web

La cryptographie à clé publique est à la base des protocoles SSL (Secure Sockets
Layer) et TLS (Transport Layer Security) qui sont les fondements des connexions sécurisées
des navigateurs Web en HTTPS. Les certificats SSL/TLS cryptent les communications
Internet et garantissent une connexion client-serveur de confiance.

Signatures Numériques et Signature de Documents

En plus d'être utilisées pour chiffrer des messages, les paires de clés peuvent être
utilisées pour les signatures numériques et la signature de documents. La PKI utilise la clé
privée de l'expéditeur pour vérifier son identité numérique. Cette vérification
cryptographique lie mathématiquement la signature au message original pour garantir
qu'il n'a pas été altéré.

Signature de Code

La signature de code permet aux développeurs d'applications d'ajouter une

couche d'assurance en signant numériquement des applications, des pilotes et des
programmes logiciels, de sorte que les utilisateurs finaux puissent vérifier qu'un tiers n'a
pas modifié ni compromis le code qu'ils reçoivent. Pour vérifier que le code est sûr et
fiable, ces certificats numériques assurent l'intégrité des conteneurs, du code qu'ils
exécutent et des applications de production qui les utilisent.

Certificats Email (S/MIME)

Les certificats S/MIME valident les expéditeurs d'e-mails et chiffrent le contenu des
e-mails pour se protéger contre des attaques d'ingénierie sociale et de spear-phishing.
En chiffrant/déchiffrant les messages et les pièces jointes d'e-mails et en vérifiant
l'identité, les certificats S/MIME assurent aux utilisateurs que les e-mails sont authentiques
et non modifiés.

Clés SSH

Les clés SSH sont une forme de certificat X.509 qui fournit une référence d'accès
sécurisée utilisée dans le protocole Secure Shell (SSH). Le protocole SSH est largement
utilisé pour la communication dans les services cloud, les environnements réseau, les
outils de transfert de fichiers et les outils de gestion de la configuration.

29 | P a g e
 Les clés SSH authentifient l'identité et protègent ces services contre une utilisation
non intentionnelle ou des attaques malveillantes.

Identités Numériques

L'authentification de l'identité numérique est un élément crucial d'une stratégie

Zero Trust 5pour authentifier les personnes, les données ou les applications. Sécuriser les
identités avec des certificats numériques X.509 est plus important que jamais, car les
données et les applications s'étendent au-delà des réseaux traditionnels vers les
appareils mobiles, les clouds publics, les clouds privés et les appareils IoT.

5 Zero trust: La stratégie Zero Trust est une approche de sécurité qui suppose qu'aucun utilisateur
ou appareil, qu'il soit interne ou externe, ne doit être automatiquement considéré comme digne
de confiance. Elle exige des vérifications constantes de l'identité et de l'accès, renforçant ainsi
la sécurité des réseaux et des données.

30 | P a g e
 Hiérarchie d’une PKI :

La hiérarchie d'une PKI ressemble à une similaire à une pyramide inversée. Au sommet se
trouve l'Autorité de Certification Racine (Root CA), qui agit comme la source de
confiance ultime. Cette autorité génère un certificat racine auto-signé, dont la clé
privée est hautement sécurisée. Ce certificat est ensuite utilisé pour signer les certificats
des Autorités de Certification Intermédiaires (Intermediate CAs).

Les Autorités de Certification Intermédiaires, situées dans la couche intermédiaire,

reçoivent leur propre certificat signé par l'Autorité de Certification Racine. Elles
fonctionnent comme des autorités de confiance pour différents domaines ou
départements au sein de l'organisation. Ces AC intermédiaires peuvent ensuite émettre
des certificats pour les utilisateurs, les serveurs et d'autres entités.

Dans la couche la plus basse de la hiérarchie se trouvent les certificats d'entité finale, tels
que les certificats de serveurs, d'utilisateurs et de dispositifs. Ces certificats sont émis et
signés par les Autorités de Certification Intermédiaires. Chaque certificat d'entité finale
contient une clé publique, des informations d'identité et une signature numérique qui
garantit son authenticité.

Figure 6: hiérarchie de PKI à 3 niveaux

La hiérarchie PKI est construite de manière à établir une chaîne de confiance. Lorsqu'un
utilisateur ou une application souhaite vérifier un certificat, il peut remonter la chaîne en

31 | P a g e
vérifiant les signatures numériques à chaque niveau. Cette vérification permet de
s'assurer que chaque certificat est valide et a été émis par une autorité de confiance.

Défis de PKI :
Parmi les vulnérabilités et défis associés à l'infrastructure à clé publique on trouve :

- Mauvaise Compréhension de la Confiance : Le concept de confiance dans la PKI est

souvent imprécis. Être une Autorité de Certification de confiance signifie gérer
correctement les clés privées, mais cela ne signifie pas nécessairement que les certificats
délivrés par cette CA peuvent être considérés comme fiables pour des usages
spécifiques.

- Assurance de l'Utilisation des Clés : Il n'existe pas de moyen infaillible pour garantir que
l'entité utilisant une clé privée est effectivement le titulaire légitime du certificat, suscitant
des préoccupations concernant l'usurpation d'identité.

- Protection de la Clé Privée : La sécurité de la clé privée est une préoccupation majeure,
car elle est souvent stockée sur des ordinateurs classiques vulnérables aux attaques, telles
que les logiciels malveillants ou le vol physique.

- Vérification de la Sécurité Informatique : L'ordinateur vérifiant un certificat doit être

sécurisé, mais il n'y a aucune garantie en ce sens, suscitant des doutes quant à l'intégrité
de la vérification des certificats.

- Identité du Titulaire du Certificat : Les certificats associent des clés publiques à des noms,
mais la vérification de ces identités peut être délicate en raison des noms communs et
des différences dans les bases de données des CA.

- Autorité et Autorisation de la CA : Les CA peuvent ne pas avoir l'autorité nécessaire

pour accorder des autorisations spécifiques, ce qui crée de l'incertitude quant à qui peut
délivrer certains certificats.

- Sécurité Axée sur l'Utilisateur : De nombreuses applications PKI ne tiennent pas

suffisamment compte du comportement et des besoins des utilisateurs, créant des failles
de sécurité.

- Modèle de CA et d'Autorité d'Enregistrement (RA) : L'utilisation des RA en plus des CA

introduit des vulnérabilités supplémentaires, rendant le système global moins sûr.

- Pratiques de Certificats et Sécurité : Les pratiques de la PKI reposent souvent sur

l'imitation plutôt que sur des raisons de sécurité solides, compromettant potentiellement
la sécurité globale du système.

32 | P a g e
- Objectif du Processus de la CA : Les motifs de l'utilisation de la PKI sont parfois peu clairs.
La PKI peut être adoptée sans une compréhension approfondie de ses implications et
de ses limites en matière de sécurité.

33 | P a g e
 PKI open-source :

Les solutions PKI open source offrent une alternative flexible aux solutions commerciales,
permettant aux organisations de déployer des systèmes de gestion de certificats sans
dépendre de solutions propriétaires coûteuses.

Dans ce tableau comparatif, nous passons en revue quelques exemples notables de PKI
open source et examinons leurs points forts et faibles du point de vue technique. Chaque
solution présente des caractéristiques uniques qui peuvent répondre à divers besoins

PKI open source Points forts Points faibles

EJBCA Entreprise - Basé sur Java, adapté aux
déploiements de niveau
entreprise
- Peut être utilisé en tant
que service ou pour une
utilisation interne
- Mise en œuvre complète
d'une CA
OpenSSL - Adopté à grande échelle,
inclus dans les principales
distributions Linux
- Boîte à outils polyvalente
pour l'activation de PKI et
la mise en place simple
d'une CA
- De qualité commerciale
CFSSL - Développé par
Cloudflare, spécialisé dans
la gestion des certificats TLS ne pas couvrir les besoins
- Prend en charge la
signature, la vérification et
le regroupement des
certificats TLS
- Adapté aux outils PKI TLS
personnalisés
XiPKI - CA et répondeur OCSP -
basés sur Java, développement basé sur
performants et évolutifs
- Exige des ressources
importantes, nécessite des
ressources système
conséquentes
- La configuration initiale
peut être complexe
-Ne constitue pas une
solution PKI complète,
nécessite un
développement
supplémentaire pour une
mise en œuvre complète
- Le développement en
langage C peut être
complexe
- Focalisation spécialisée
sur les certificats TLS, peut
PKI plus larges
- Peut nécessiter une
intégration supplémentaire
pour un déploiement PKI
complet
Environnement de
Java peut nécessiter une

34 | P a g e
 - Prend en charge courbe d'apprentissage
l'algorithme SHA-3 plus raide
- Moins connu que
certaines autres solutions
PKI
Dogtag Certificates System - Solution de classe - Forte association avec les
entreprise prenant en systèmes Red Hat,
charge la gestion potentiellement moins
complète du cycle de vie adaptable aux
des certificats environnements non-Red
- Adapté aux besoins Hat
complets en CA - La documentation peut
être limitée en dehors de
l'écosystème Red Hat

35 | P a g e
Phase de test :
Lors de cette phase on va exploiter VMware pour installer une PKI open source, dans
notre cas on va installer EJBCA dans un environnement linux basé sur Ubuntu.

Comme première étape on commence par l’installation des paquet nécessaires et

mettre à jour notre VM, vu la compatibilité des versions EJBCA, JBoss, JDK et apache, on
va travailler avec les versions Ejbca 6.5.0.5, JDK 1.7.0_76, JBoss 7.1.0. Final, et Apache Ant
1.9.16

Installation des paquets

JAVA
On commence par l’installation de java dépendances

Tous d’abord on a téléchargé le fichier jre-7u67-linux-x64.tar.gz du site officiel oracle et

on l’a extrait vers le chemin ubuntu/opt

On change les privilèges du fichier pour qu’il soit exécutable

36 | P a g e
On rajout le chemin de notre paquet dans JAVA-HOME Path pourque Ubuntu
reconnaître et utiliser cette version particulière du JDK

On sauvegarde les modifications puis on exécute la commande source/etc/profile pour

appliquer les changements

Et voici notre version java

ANT Apache
Ensuite on installe la version de Ant compatible qui est apache-ant- 1.9.16-bin

Depuis le site officiel d’Apache on télécharge la version d’Ant qu’on entracte, puis on
rajout le chemin de notre paquet à celui de java

37 | P a g e
On vérifie la version de Ant

JBoss/Ejbca
Après le téléchargement et extraction des paquets dans répertoire Downloads

On copie le chemin de Ejbca du ficher sample (modèle) vers le fichier properties qui
représente le fichier de configuration que Ubuntu va utiliser pour l’installation de cette
dernier

Puis on indique a Ejbca ou se trouve le serveur d’application JBoss pour pouvoir accéder
au ressources

Dans un autre terminal on lance le serveur JBoss

38 | P a g e
On se rend au terminal de Ejbca et on execute ant bootstrap qui a comme objectif est
de préparer l'environnement de construction de manière à ce que les autres
commandes de construction (comme "ant deploy”) puissent être exécutées avec
succès

Puis on exécute ant install pour effectuer l'installation initiale de l'autorité de certification,
ce qui engendre la génération des certificats, clés nécessaires, la configuration du TLS
dans le conteneur de servlet, ainsi que la création d'éléments dans la base de données
tels que l'autorité de certification, les profils de certificat et les utilisateurs.

39 | P a g e
Puis ant deploy, cela compilera et construira EJBCA, le déploiera sur JBoss, tout en créant
automatiquement des sources de données

40 | P a g e
41 | P a g e
Interface EJBCA

Une fois l’installation est terminée et JBoss est démarré on arrière-plan on peut accéder
à notre interface EJBCA

On import le fichier superadmin.p12 qui est un fichier de certificat de la forme PKCS#126

utilisé pour l’authentification et l’autorisation du superadmin qui est la 1er entité crée lors
de l’installation d’EJBCA

6 PKCS#12 :

42 | P a g e
On saisit ensuite la clé établie pour le superAdmin lors de l’installation

43 | P a g e
Notre certificat est importé dans notre navigateur

44 | P a g e
Une fois le certificat est accepté par notre site on a accès a notre interface

Notre 1ére manœuvre consiste dans la création d’une hiérarchie de PKI a trois niveaux :
ROOT, SUB et END ENTITY

On procède à la création du root on se rendant à certificate profiles et clonant le profile

existant du rootCA

Notre profile est crée

45 | P a g e
On spécifie que se profile correspond à une root CA dont les clés de ce certificat de
l'autorité vont être générées avec l’algorithme DSA dont la longueur de la clé est de 256
bits, sa durée de validité est de 30 ans qu’on peut incrémenter avec l’option allow valifity
override qui peut être demandée à partir de la demande de certificat.

Dans la section x.509v3 extansions qui a comme but d’ajouter des fonctionnalités
supplémentaires au certificat on a activé basic constraints qui définit si le certificat est
un CA ou un certificat de fin d’entité et s’il peut être utilisé pour la signature des CRL

- key usage : cette extension spécifie les utilisations de clés autorisée pour le certificat
dans notre cas on a spécifiée digital signature, key certificate sign et CRL sign
- Subject alternative Name : on a permis d’ajouter des noms alternatifs au certificat,
comme une adresse IP ou des noms de domaine supplémentaire
- CRL Distribution Points : spécifie les emplacements ou les listes de révocation des
certificats peuvent être obtenues dans notre cas on peut les trouver dans :
http://localhost:8080/ejbca/publicweb/webdist/certdist?cmd=crl&issuer=CN=Root
CA,C=SProvince

Après on garde les autres cases dans leur état de défaut et on sauvegarde notre ROOT
CA

46 | P a g e
47 | P a g e
 De même pour la création du profile SUB CA, on spécifie premièrement son type et
l’algorithme utilisé avec la longueur de clé spécifié, on a fixé sa validité sur 25 ans,
comme il s’agit d’une sub ca l’algorithme de signature va être hérité depuis le certificat
root.

Pour les fonctionnalités supplémentaires du certificat elles restent identiques à celle du

root, on sauvegarde ensuite notre profile.

48 | P a g e
49 | P a g e
50 | P a g e
51 | P a g e
Puis pour gérer et stocker les paires de clés de nos certificats on se rend à CryptoToken.

Note 1er token est dédiée pour Root CA ou on a généré trois clés : encryptKey, signKey,
testKey basé sur l’algorithme DSA et 1024bits de longueur

52 | P a g e
Le 2éme est pour le SUB CA :

53 | P a g e
Puis on crée nos autorités de certificats

54 | P a g e
On spécifie le crypto token a utilisée dans chaque cas, vu qu’il s’agit de l’autorité de
certification racine nous utiliserons le ROOToken.

On affecte les clés crées à chaque type de clé :

- defaultkey : Cette clé est utilisée quand on ne choisit pas de clé spécifique. On en a
besoin dans différents cas où on n'a pas de but précis

- CertSignKey : c’est une clé de signature pour les certificats quand on les crée, elle signe
les informations importantes dans les certificats tel que la clé publique.

- crlSignKey : Cette clé sert à signer les listes de révocation de certificat.

- keyEncryptKey : Elle est utilisée pour déchiffrer des clés spéciale si quelqu’un a perdu
sa clé privée

55 | P a g e
- hardTokenEncryp : Elle fait référence à des fonctionnalités liées au chiffrement de
données sur des jetons matériels.

- testkey : Elle est utilisée pour des vérifications rapides pour être sûr que le système
marche comme il faut.

- Enforce unique public keys : garantit que deux personnes différentes ne peuvent pas
utiliser la même clé publique pour obtenir des certificats. Cela empêche toute
confusion et assure que chaque personne a une clé qui lui est propre
- Enforce unique DN : utilisateur peut avoir plusieurs certificats avec le même DN tant
que le même 'nom d'utilisateur' est utilisé

On a spécifié que la date de validité du CA est de 5 ans

56 | P a g e
- Default CRL Dist. Point : indiquent où trouver les listes de révocation de certificats
associées aux certificats numériques, ce qui permet aux utilisateurs de vérifier la
validité des certificats en vérifiant s'ils ont été révoqués par l'autorité de certification.

On spécifie sa valeur de validité a 5 ans

Après enregistrement voici un aperçu du certificat :

57 | P a g e
On crée ensuite le certificat du SUB CA

58 | P a g e
De même on utilise le token adéquat qui est SUBtoken

59 | P a g e
La période de validité est de 2 ans

60 | P a g e
Notre certificat est comme suit :

61 | P a g e
Pour finalisée notre hiérarchie a trois niveaux on crée noter End Entity certificat

Commençant par la création du profile, on clone enduser profile

62 | P a g e
63 | P a g e
On a spécifié que notre clé va être utiliser pour authentification du client et code signing
qu’on a présenté son principe précédemment

64 | P a g e
Le certificat de notre profile est crée

65 | P a g e
Dans end entity profile on crée notre entité finale

66 | P a g e
67 | P a g e
On spécifie le nom de l’entité et le mot de passe qui va utiliser lors de la demande des
certificats

68 | P a g e
Comme application on réalise un code signe sur mycode.sh qui contient un code
exécutable

Voici un aperçu sur le code

Premièrement on se rend vers Ejbca pour exporter le Keystore de l’autorité de

certification qui va signer notre code

69 | P a g e
Puis a l’aide de l’outil openSSL on signe notre document

La commande nous permet de calculer le hache du fichier avec l’algorithme sha256

puis le signer par la clé privé private_key.pem, le résultat est stocker dans
mycodeSign.sig, et mycode.sh représente le fichier a signer

On vérifie notre signature

Pour mettre on ouvre l’objectif des signatures numériques on effectue des changements
sur le fichier

70 | P a g e
Et on revérifie notre signature

On remarque qu’on a reçu un message d’erreur donc le fichier original a été altéré.

71 | P a g e
Conclusion

En conclusion, l'installation de EJBCA au sein de la distribution Ubuntu a été une

exploration enrichissante dans le domaine de la gestion de certificats et de la sécurité
numérique. À travers cette expérience, nous avons pu découvrir les différentes étapes
nécessaires pour mettre en place une Autorité de Certification sécurisée, capable de
générer, de signer et de gérer des certificats numériques

Au fil de ce stage, nous avons exploré les aspects fondamentaux de la cryptographie et

de la sécurité informatique, comprenant les concepts clés tels que les clés privées, les
clés publiques, les certificats et les infrastructures de clés publiques (PKI). Nous avons vu
comment EJBCA offre une solution complète pour la création et la gestion de certificats,
tout en se concentrant sur des éléments essentiels tels que la sécurité, la vérification et
l'authentification.

L'installation de EJBCA sur la distribution Ubuntu a été une tâche bien guidée par notre
encadrant. Nous avons abordé des sujets tels que la configuration des profils de
certificats, la création de hiérarchies PKI, la gestion des clés privées et publiques, ainsi
que la génération et la vérification de signatures numériques. Nous avons également
exploré les multiples fonctionnalités de EJBCA, telles que la gestion des certificats de bout
en bout, la personnalisation des profils de certificat et l'exploitation des Crypto Tokens
pour sécuriser les clés.

En mettant en œuvre cette solution de sécurité robuste, nous avons pu approfondir notre
compréhension des pratiques de sécurité dans le monde numérique moderne. La mise
en place d'une Autorité de Certification bien configurée dans un environnement Ubuntu
a permis de démontrer l'importance de la gestion des certificats et de la cryptographie
pour garantir la confidentialité, l'intégrité et l'authenticité des communications en ligne.

Je souhaite exprimer ma sincère reconnaissance envers tous les membres du service

informatique qui ont accepté de m’accueillir et m’ont guidé tout au long de mon stage.

Un remerciement particulier va à mon encadrant, Mr. Nasredine Benjmil pour avoir

proposé et diriger ce travail, et pour son soutien, sa disponibilité et ses précieux conseils
tout au long de cette recherche.

Je tiens également à adresser ma profonde gratitude à son Excellence Mr. le

Gouverneur de la Province de Sefrou, Mr. le Secrétaire Général ainsi que Mr. Le Président
du Conseil Provincial de Sefrou pour m’avoir offert cette opportunité de stage
d'observation enrichissante.

72 | P a g e
Références :

https://www.schneier.com/wp-content/uploads/2016/02/paper-pki.pdf

https://www.sectigo.com/resource-library/what-is-pki-public-key-infrastructure

https://www.keyfactor.com/education-center/what-is-pki/

https://www.securiteinfo.com/cryptographie/pki.shtml

https://www.techtarget.com/searchsecurity/definition/PKI

https://www.okta.com/identity-101/public-key-infrastructure/

https://venafi.com/machine-identity-basics/what-is-pki-and-how-does-it-work/#item-17

https://www.tevora.com/blog/3-steps-implementing-public-key-infrastructure-pki-
architecture/

https://www.oracle.com/java/technologies/javase/javase7-archive-downloads.html

https://www.youtube.com/watch?v=X_gRJs1aTdY&t=311s

https://ant.apache.org/srcdownload.cgi?Preferred=https%3A%2F%2Fdlcdn.apache.org
%2F

https://www.youtube.com/watch?v=oapua8OCtjQ&t=10s

https://jbossas.jboss.org/downloads

https://sourceforge.net/projects/ejbca/files/ejbca6/ejbca_6_5_0/

73 | P a g e