1.

Problématique 
Etant donné l’accroissement du nombre d’infiltrations et transgressions informatiques, le
niveau de sécurité reposant sur l’authentification par login et mot de passe s’avère être
dépassé, voire même primitif. C’est pour cette raison qu’il faut chercher un autre moyen de
sécurisation de données, notamment quand il s’agit de transactions bancaires ou d’échanges
de données secrètes. Le risque doit être maintenu à zéro.

Solution demandée

Le travail demandé consiste à mettre en place une solution PKI open source EJBCA pour la
génération de certificats en ligne avec un service de publication de ces certificats.

Cette solution portera sur l’étude des infrastructures cryptographiques pour pouvoir choisir
une implémentation qui nous aidera à générer des certificats électroniques puis de les publier
dans un annuaire électronique.

La famille des PKI renferme une multitude de modèles. Dans notre cas, on s’intéresse
particulièrement aux PKI open source EJBCA, celles dont le développement, l’amélioration et
l’acquisition sont ouvertes au grand public.

2. Présentation de EJBCA 
EJBCA est une PKI sous licence Open Source (LGPL) développée en Java/J2EE. Elle permet
d’implémenter et concevoir une solution PKI de plusieurs façons, allant du simple et du faible
coût au très complexe et coûteux. EJBCA permet de mettre en œuvre pratiquement n'importe
quel type d'architecture PKI. Chaque composant peut être déployé de manière autonome ou
intégrée dans EJBCA.

Architecture Fonctionnelle
La figure 8 nous servira d’appui pour l’énumération des composants de EJBCA [1].
 Figure 1 : Schéma de EJBCA

EJBCA propose quatre composants fonctionnels. Chaque ou l’ensemble des composants

fonctionnels peut être déployé de manière unitaire ou consolidée sur une même machine ou
dans une autre application.

 Les composants de base 

Les composants de base d’EJBCA sont :

 Entité publique ou autorité d’enregistrement locale (AEL) : Elle est composée
d’éléments permettant de réaliser des requêtes de certificats, de révocation ou pour
récupérer des éléments publics de la PKI, tels les certificats d’AC, CRL, certificat
utilisateur, etc.

Les méthodes d’appel fournies par EJBCA sont les suivantes :

- Au format Web (AEL), par le biais de page à intégrer dans un intranet ou de
manière autonome
 - Au format ligne de commande, permet en complément de réaliser des opérations
d’administrations
- Sous forme d’API Java WS (Jax-WS 2.0) à intégrer dans des composants métiers
- Avec le protocole XKMS (XML Key Management Specification)
- En utilisant CMP (Certificate Management Protocols)
- Par le biais du protocole SCEP pour les routeurs

 Entité administrative ou Autorité d’enregistrement (RA) : Elle englobe les

fonctions de gestion de la PKI, telles les fonctions d’authentification, de gestion de vie des
certificats, de journalisation, de publication et de paramétrages de la PKI. En complément,
elle permet de définir le format des entités publiques et le contenu des certificats. Les
fonctions principales incluses dans l’AE :
- Gestion des profils de certificat et d’entité
- Gestionnaire de clefs (séquestre et recouvrement)
- Définition du service de publication
- Gestion des administrateurs et des droits associés
- Gestion des profils pour les cartes à puce et Dongle USB
- Demande, rejet et Validation des requêtes de certificat et de révocation
- Processus de gestion du renouvellement
- Gestionnaire de journaux (paramétrage, consultation, export, etc.).
 Autorité de la PKI ou autorité de certification : Elles sont responsables de la
délivrance et de la révocation des certificats. Une même instance peut gérer plusieurs
AC racines et AC subordonnées.
Les clefs peuvent être conservées sur des boîtiers cryptographiques, sur carte à puce où dans
la base de données
 WebRA
Dernier né des entités d’EJBCA, il a été conçu pour renforcer la partie fonctionnelle d’EJBCA, il
comprend les éléments suivants :
▫ Modules de gestion de vie des certificats (pre-condition, demande de certificats, révocation,
renouvellement, etc.)
▫ Moteur de Worflow, permet de définir les cinématiques du cycle de vie des certificats
▫ Outils de reporting, statistiques, facturation
▫ Indépendance du gestionnaire d’authentification et d’habilitation
  Composants additionnels 

Ces composants sont proposés en compléments de la PKI EJBCA, l’ensemble de leurs

fonctionnalités n’est pas décrit dans cette présentation
 Serveur de signature, permet de réaliser des opérations de signatures sur des
documents électroniques.
 Serveur d’horodatage, garantir électroniquement la date et l’heure d’une opération
 Serveur OCSP(EJBCA), permet de fournir une réponse immédiate et à jour aux
questions sur le statut d’un certificat.

 Composants optionnels 

L’interface publique se compte pour un composant optionnel en EJBCA car l’utilisateur peut
consulter les fonctionnalités de son OS et trouver un moyen de récupérer son certificat

Architecture Applicative

EJBCA est découpée en trois couches

 Couche présentation

Elle fournit les interfaces aux clients et administrateurs pour les appels vers l’autorité de
Certification ou vers l’autorité d’enregistrement.
 Une couche applicative

Elle englobe les fonctions métiers de la PKI, elle comprend les éléments suivants :
Les fonctions d’authentification, de gestion de vie des certificats, de journalisation, de
publication
Et de paramétrages de la PKI En complément, elle fournit un gestionnaire de clefs (séquestre
et recouvrement)
 Une couche de données :

Qui permet de stocker l’ensemble des données de la PKI dans une base de données
Il possible de connecter un ou plusieurs un annuaire LDAP pour lui adresser les données
publiques de la PKI (utilisateurs, certificats, CRL, etc.)

Architecture Logique

 Les atouts et points forts d’EJBCA

EJBCA est une autorité de certification très populaire et l’une des plus privilégiées
actuellement [2]. Parmi ses caractéristiques de base on note la variété de choix de :
- L’algorithme qui s’étend de SHA-1 avec RSA jusqu’à SHA-256 avec RSA
- Le taille de la clé allant de 1024, 2048 jusqu’à 4096 bits.
- La langue lors de la configuration du système
- L’annuaire de publication (publisher) comme LDAP
- L’Active Directory (AD) et le choix du type du publisher connector (connecteur de
l’éditeur)
- La clef de signature qui peut être soft/hard
Outre ces traits saillants fournis ;
- EJBCA délivre des certificats conformes à la norme X.509 et offre la possibilité
d’intégrer le certificat dans les cartes à puce.
- EJBCA est indépendant des systèmes d’exploitation, des bases de données ou des
serveurs applicatifs
- EJBCA fonctionne sur la plupart des systèmes d’exploitation : Unix, GNU/Linux,
FreeBSD, Solaris, Windows.
- EJBCA utilise un serveur d’application et est compatible avec les grands produits du
marché tels que : Jboss, JonAS, GlassFish, OC4J, WebLogic, WebSphere 
- EJBCA est compatible avec les bases de données supportées par les serveurs
d’applications, c’est à dire : MySQL, PostgreSQL, Oracle, DB2, MS-SQL,
Hypersoniq, Derby, Sybase, Informix, Ingres 
 3. Implémentation de EJBCA et réalisation
On a déployé une PKI complète dans une seule instance. Étant donné que EJBCA a tout intégré, vous
pouvez avoir une seule instance fonctionnante à la fois en tant que CA et RA. Il s'agit d'une solution
très efficace, facile à gérer et économique qui convient à de nombreux déploiements des entreprises.

Fig. Standalone CA/RA/VA

1. Installation de EJBCA

Dans cette partie on va entamer la phase d’installations des paquetages et des modules
logiciels nécessaires au déploiement de notre PKI. Ensuite, on fera une série de configurations
afin d’adapter l’environnement logiciel à l’environnement matériel.

Environnement de développement du projet 

L’environnement de développement du projet se réparti comme suit :

 Environnement matériel
 Environnement logiciel
 Modules complémentaires

Environnement matériel 

L’environnement matériel de notre projet comprend :

 Ordinateur personnel : Intel Core ™ i7, RAM 4 Go
 2 machines virtuels: UBUNTU 20.04 (EJBCA), CentOS 7 (Serveur Web)
 Navigateurs : Mozilla Firefox

Environnement logiciel 

L’environnement logiciel de notre projet comprend :

 Le serveur d’application JBoss : Version 7.2
  La base de données MYSQL
 Java : Le package OpenJDK 8 de Java SE Specification
 JCE : Java Cryptographic Extension
 MYSQL Connector
 ANT (Another Neat Tool)
 EJBCA : Version 7.4.3.2

Configuration des variables d’environnement 

Après avoir affecté à chaque variable le chemin correct qui lui convient en configurant le
fichier « profile » se situant sous /etc, on vérifie si ces variables sont bel et bien correctes.

En tapant la commande de vérification sur la console, on obtient comme sortie la

configuration qu’on a introduite.

 APPSRV_HOME= /opt/jboss

 JAVA_HOME =/opt/java

 JAVA_OPTS= « -Xmx512M –Xms512M »

 EJBCA_HOME= /opt/ejbca

 ANT_HOME=/opt/ant

 ANT_OPTS= « -Xmx512M –Xms512M »

 PATH=${APPSRV_HOME}/bin : ${ JAVA_HOME  }/bin: ${ EJBCA_HOME }/

bin : ${ ANT _HOME  }/bin : $ PATH

 Export PATH APPSRV_HOME JAVA_HOME  JAVA_OPTS EJBCA_HOME

ANT_HOME ANT_OPTS

Création de la base de données 

Afin de permettre à EJBCA d’enregistrer ses données nous créerons une base de données
MYSQL. Cette base de données permettra à l’utilisateur d’EJBCA de bénéficier des
permissions nécessaires pour l’ajout la suppression et la mise à jour des données de la base.

Pour ce faire, nous suivrons ces étapes là en introduisant pour chacune la/les commandes
adéquates :
  Tout d’abord, nous créons la base de données et nous l’appelons ejbca, nous créons
avec un administrateur adminmysql et nous lui affectons un mot de passe.

 Nous créons ensuite un utilisateur pour la base de données et nous lui accordons tous
les privilèges sur ejbca

 Nous informons le serveur de la base de données de nouveautés survenues sur la base

 Nous faisons une série de tests en ligne de commandes pour nous assurer que la
création de l’utilisateur a réussi.

 Nous nous déconnectons de la base de données et nous nous reconnectons pour

revérifier que nous pouvons accéder à la base avec l’utilisateur créé.

Si la série de tests se termine avec succès, alors la base de données est fonctionnelle et
l’utilisateur créé dispose de tous ses droits légitimes. En effet l’installation via des
commandes linux est très délicate, c’est pour cette raison qu’il faut entamer des tests.

Configurations sur EJBCA

EJBCA maintient ses configurations statiques sous le répertoire conf. Le répertoire comprend
divers fichiers de configuration (enregistrés sous *.properties.sample), qui doivent être
renommés en *.properties pour devenir actifs. Ces fichiers sont nécessaires pour effectuer les
initialisations et les personnalisations désirées lors du processus d’installation.

Nous allons donc effectuer une série de configuration sur quelques fichiers dont notamment :
ejbca.properties, database.properties, web.properties, install.properties et le fichier ayant pour
emplacement /etc/profile contenant les variables d’environnement.

Configuration du fichier ejbca.properties 

A ce stage de l’implémentation, nous installons le package EJBCA et nous accordons tous les
droits de propriétés à l’utilisateur système de EJBCA qui s’intitule ejbca lui également.
Ensuite nous nous plaçons sous le répertoire /opt/ejbca/conf, là où se situe le fichier de
configuration ejbca.properties.

Le fichier ejbca.properties est celui qui nous permettra de fixer quelques paramètres
nécessaires pour l’installation de EJBCA server.
 Configuration du fichier database.properties 

De même que pour le fichier ejbca.properties , database.properties sera sujet à un ensemble de

configurations liées à la base de données qu’utilise EJBCA.

Sur ce fichier, nous fixerons le type de la base de données ainsi que le mapping effectué, son
url, son driver et l’administrateur qui lui sera affecté comme suit :

Database.name=mysql
Datasource.mapping=mySQL
Database.url=jdbc  :mysql: //127.0.0.1:3306/ejbca
Database.driver=com.mysql.jdbc.Driver
Database.username=ejbca
Database.password=*****

Configuration du fichier web.properties 

Lors de l’installation de JBoss, EJBCA crée un fichier appelé trust-store ou magasin de

confiance. L’utilité de ce fichier se voit lors de l’authentification du client auprès de JBoss.

Dans ce contexte, nous configurerons ce fichier dans la mesure de spécifier des mots de passe
pour le super administrateur de EJBCA qui sera utilisé ultérieurement lorsque le super
administrateur devra importer son accréditation auprès de son navigateur web, du Key-store
(CryptoToken) contenant les certificats p12 de l’administrateur, un mot de passe pour
sécuriser l’accès depuis http server et un DNS hostname. La configuration est la suivante :

Superadmin.password=********
Httpserver.password=********
Httpserver.hostname=localhost

Configuration du fichier install.properties 

Le fichier de configuration install.properties spécifie les propriétés de l'autorité de

Management CA. Cette installation créera une première autorité Management CA. Cette
autorité de certification sera utilisée pour le super-administrateur et pour le certificat de
serveur SSL du site Web administratif. Lorsque le serveur Web administratif sera configuré,
on va créer une autre autorité de certification. Ceci n'est utilisé qu'à des fins administratives.
 Fig. Configuration fichier install.propertis

Finalisation de l’installation

Après avoir configuré tous les fichiers nécessaires, nous faisons appel à ANT avec la
commande appropriée qui finalisera le boostrap (installation) de EJBCA. Si cette étape est
franchie avec succès, nous lançons alors notre serveur d’application JBoss puis nous vérifions
le peuplement de notre base de données avec les tables systèmes nécessaires, se comptant au
nombre de 3 6qui assurerons à l’utilisateur une supervision totale de la base.
 Fig. Les tables de la base de données

Maintenant que nous nous sommes assurés du bon fonctionnement de JBoss et la création des
tables de la base de données, nous pouvons enfin créer concrètement notre première CA
(Management CA) et notre super administrateur.

Pour ce faire, nous avons recours à ‘ant install’, qui lancera sur la console le déploiement du
fichier server.log . Nous nous assurons de la non existence d’erreurs et enfin nous déployons
EJBCA avec ‘ant deploy’ tout en revérifiant au fur et à mesure le bon fonctionnement de
JBoss et de mysql.
Cette étape de finalisation est très délicate car elle renferme une kyrielle de tests successifs et
répétitifs pour s’assurer qu’aucune erreur n’advienne.

Il ne reste plus qu’à vérifier la disponibilité des ports 8080, 8442 et 8443 pour pouvoir lancer
l’URL de ejbca [ https://127.0.0.1 :8443/ejbca/index.jsp ] sur le navigateur et d’y ajouter le
certificat SuperAdmin.p12.

Tout ceci nous mène à avoir enfin notre interface publique de EJBCA là où les certificats
peuvent être récupérés, qui est illustrée par la figure 10. Et bien évidement, une interface
administration illustrée par la figure 11
Figure 1 : Page publique de EJBCA

Fig 11. Page Administration de EJBCA

 2. Réalisation 

EJBCA est maintenant installée et correctement configurée. Elle est gérée par un super
administrateur qui détient tous les supers pouvoir sur cette PKI. Il ne manque plus que
l’élaboration du squelette de la PKI en définissant le AC racine et les AC subordonnées
descendantes de l’AC racine. Dès lors, la procédure de certification se clarifiera et le scénario
du se fera moins flou.

Cette dernière étape qu’est la réalisation, suit plusieurs étapes enchaînées et

chronologiquement ordonnées pour parvenir au produit final qui est le certificat, prêt à être
délivré.

Acteurs de la PKI 

La PKI peut être utilisée par deux types d’acteurs : ceux qui voient la médaille et ceux qui
voient le revers de la médaille.

La médaille réfère à la partie visible de la PKI, celle qui peut être consultée publiquement et
elle est modélisée par des pages web publiques que les utilisateurs peuvent consulter.

Le revers de la médaille quant à lui, réfère à la partie secrète et cachée de la PKI et qui n’est
visible que par les utilisateurs à droits administratifs. Cette partie est modélisée par des pages
web administratives comportant les tâches d’administrateurs.

Les tâches sont réparties comme suit :

 Le super administrateur : C’est à lui et à lui seul que revient le pouvoir et le choix de
tout faire au sujet de la PKI

 L’administrateur (optionnel): Il est créé par le super administrateur et il agit selon les

droits qui lui ont été affectés et les tâches qui lui ont été déléguées.

 Le groupe d’administrateurs (optionnel): Si la PKI est confrontée à un trafic soutenu,

le super administrateur peut rassembler les administrateurs selon leurs droits d’accès
dans un groupe d’administrateurs. Chaque groupe accèdera à la PKI avec le certificat
convenant à celui du groupe afin de départager les services de la PKI et ne rendre
visible à l’administrateur que la tâche qui lui est associée.

 Le client final : Consulte les pages web pour pouvoir récupérer son certificat ou
bénéficier d’autres services destinés aux utilisateurs.

Dans notre cas de PKI, nous n’avons que deux acteurs :

  Le super administrateur : C’est celui qui a créé la CA racine ainsi que les CA
subordonnées et effectué tout le travail de certification

 L’utilisateur final : Il accède aux pages publiques et récupère son certificat après s’être
authentifié, qu’il soit une personne ou un serveur.

Choix et élaboration de l’architecture logique 

Etant donné que notre EJBCA visera particulièrement les personnes et les serveurs, nos
certificats finaux seront paramétrés de la sorte, ainsi que notre stratégie d’hiérarchisation des
CA.

Sur ce, nous avons opté pour une stratégie de partage qui vise à créer deux CA subordonnées
directement liées à notre CA racine qu’on va la créer par la suite. Ces deux CA seront
logiquement signés par la CA racine qui est “SupCom Root CA” et hérite par suite ces
certificats.

Étant donné que les conséquences d'une autorité de certification racine compromise sont si
grandes (jusqu'à et y compris la nécessité de réémettre chaque certificat de la PKI), toutes les
autorités de certification racine doivent être protégées contre tout accès non autorisé. Une
méthode courante pour garantir la sécurité et l'intégrité d'une autorité de certification racine
consiste à la maintenir hors ligne. Une autorité de certification racine hors ligne est une
autorité de certification qui a été isolée de l'accès au réseau et est souvent maintenue dans un
état hors tension. Il n'est mis en ligne que lorsque cela est nécessaire pour des tâches
spécifiques et peu fréquentes, généralement limitées à l'émission ou à la réémission de
certificats autorisant les autorités de certification intermédiaires ou subordonnées.

EJBCA nous permet de mettre le CA racine en mode hors ligne une fois qu’on a terminé la
création et la signature des deux CA subordonnées.

La première est une CA destinée pour générer des certificats personnels d’où son nom
significatif « SupPersonnel Issuing CA » et la deuxième, naturellement, sera dédiée à la
génération de certificats serveurs et elle est nommée « SupServer Issuing CA».

Après avoir élaboré le croquis de notre PKI et défini les paliers de notre architecture, plus
aucune contrainte ne se présente. On procède donc à la définition de nos entités finales qui
réfèrent aux utilisateurs finaux de notre PKI. Si l’utilisateur est une personne, elle sera liée à
« SupPersonnel Issuing CA » sinon elle sera liée à « SupServer Issuing CA» dans le cas où
c’est un serveur.

Scénario de certification coté client 

L’obtention d’un certificat électronique est le résultat de toute une procédure et un

enchaînement de phases.

Pour pouvoir disposer d’un certificat valide et fonctionnel, l’utilisateur devra suivre cet
itinéraire de certification

 Dépôt de demande certificat : Le client dépose une demande auprès de l’organisme de

certification en se dotant de sa carte d’identité nationale afin de récupérer les
informations personnelles nécessaires à l’élaboration du certificat électronique.

Il est à noter que notre PKI est à fortiori présenté au marché tunisien. C’est pour cette
raison que la demande d’obtention de certificat doit être manuelle car il en faut des
 connaissances et de la conscience techniques pour pouvoir en premier lieu assimiler
l’utilité de la signature et de la certification électroniques, et en deuxième lieu le
moyen d’y parvenir. Une demande manuscrite, s’avère être donc le moyen le plus
simple et facile à comprendre en l’occurrence ; surtout que certaines entreprises
désirant bénéficier d’un certificat, envoi leurs agents commerciaux qui dans la plupart
des cas ne comprennent pas la notion intrinsèque de certification.

 Validation de la demande et signature : L’administrateur du système reçoit la

demande, la valide et procède à la génération du certificat. Il crée un certificat d’entité
finale basé sur le profil de certificat prêt au préalable.

 Obtention du certificat : Le client accède à la page publique d’EJBCA à l’adresse :

https// :8442/ejbca/publicweb/ et consulte le service de création de certificat sous la
rubrique enroll (enregistrement). Il entre son login et mot de passe pour s’authentifier
puis il spécifie la taille de la clef désirée, enfin, il télécharge son certificat.

Un client comme étant serveur :

Dans le cas où le client est un serveur, la procédure d’obtention de certificat reste la

même, sauf que la CA qui délivre le certificat n’est pas la même. Comme nous avons
expliqué plus haut, nous avons posé une architecture assez ordonnée et hiérarchique qui
préconise que chaque type de certificat final est délivré par l’autorité de certification
subordonnée SubCA) correspondante.
 Scenario de certification coté administrateur 

Dans notre PKI, l’administrateur joue le rôle du super administrateur, du groupe

d’administrateur et fait le tout à la fois. En effet, le super administrateur, celui qui a installé
EJBCA (celui que nous représentons dans ce projet), crée l’autorité de certification racine au
fur et à mesure de l’installation de la PKI. Ensuite, il crée un profil de certificat
(PersonelCertifcateProfile et ServerCertificateProfile) pour chacune des autorités de
certification subordonnées ( SubCA) qui sont directement ascendantes à la RootCA. Puis,
chaque SubCA utilise le profil de certificat créé au préalable comme modèle fixe pour en
créer une entité finale du modèle ( EndEntityPersonnelCertificateProfile). Une fois créés, le
profil de certificat et l’entité finale de ce profil ne sont plus objets à la modification, ils
représentent dorénavant le certificat officiel et final de la SubCA , celui qui va signer les
certificats des utilisateurs finaux.

Finalement, juste avant la création d’utilisateurs finaux, l’administrateur crée un profil de

certificat d’utilisateur final (EndEntityPersonnelProfile) qui servira de modèle final pour les
certificats finaux.
 Création des profils de certificats 

La création des profils de certificats est l’étape sans laquelle nous ne pouvons pas créer des
CA subordonnées. Ce profil est une référence irrévocable dans l’identité de la SubCA.

Ce qui fait l’importance et tout le poids du profil de certificat est le taux d’informations
basiques et très importantes qu’il renferme.

En effet, il spécifie :

 La validité du certificat de la SubCA : La validité temporelle du certificat des deux

SubCA est fixée à 10 ans. Ceci revient à la robustesse et véracité de ces autorités
intermédiaires qui délivrent des certificats fiables. Il n’est donc pas nécessaire de
renouveler et mettre à jour les certificats, une validité de 10 suffit amplement.

 L’id du certificat : La création du profil de certificat attribut automatiquement un id

au certificat ce qui signifie l’unicité et l’authenticité de ce profil. Cet identificateur
unique est le timbre du certificat car ce dernier peut être renouvelé. En cas de
renouvellement, le certificat garde le même id du départ. Toutefois, les clefs peuvent
changer mais pas l’id.

 La définition de l’algorithme de signature et de la fonction de hachage : Les choix

de l’algorithme de signature, la fonction de hachage et de la taille de la clef sont d’une
importance extrême. Ces champs-là valorisent énormément le niveau de sécurité du
certificat. Toujours est-il que nous désirons aboutir à un produit final de haute garantie
de sécurité, le choix de l’algorithme de chiffrement est là où réside tout le génie des
mesures draconiennes de sécurité. Partant de ce principe, nous avons choisi SHA 256
avec RSA comme algorithme de signature et fonction de hachage. Ce choix tient de
tout sauf du hasard.

 Justification du choix de l’algorithme : L’algorithme de signature choisi pour

notre certificat est le RSA. Partant de notre choix de début qui préconise l’open
source, RSA s’avère être un algorithme open source, libre de tout brevet et à la
fois normalisé. En effet RSA est celui qui convienne le mieux à nos objectifs.
Comparé à son rival DSA, RSA s’avère être plus approprié pour la signature
des certificats car il est plus rapide à être vérifié. De plus RSA dispose d’une
large communauté d’usage notamment les sites web utilisant le protocole
HTTPS utilisent des algorithmes à longueur de clef de l’ordre de 1024 bits.
  Justification du choix de la fonction de hachage : La fonction SHA 256 opère
sur des mots de 32 bits et des messages de  264 bits. C’est une fonction de
hachage qui génère un condensat (hash) de 256 bits à un niveau de sécurité de
2128 bits ce qui veut dire que la probabilité de collisions est infiniment faible et
que la tolérance à l’erreur et aux infractions est à un ordre si réduit et quasi
impossible. Avec un condensat d’une telle longueur de taille, SHA 256 ne peut
qu’être résistant aux attaques. Ces raisons-là sont des faits et des arguments
assez solides pour nous convaincre de privilégier SHA 256 comme fonction de
hachage pour le chiffrement et par suite la signature de nos certificats. Ce
choix-là ne peut que renforcer et consolider notre stratégie de vulgariser les
mesures drastiques de sécurité en vue de réduire au maximum toute éventualité
d’usurpation des enceintes préservées.

 La définition de la taille de la clef privée : La taille de la clef a été choisie à 4096

bits car jusqu’à présent, c’est la taille de clef la plus volumineuse et par suite la plus
hautement conseillée pour plus de sécurité.

 L’autorité de certification racine qui a signé ce certificat : le profil de certificat de

la CA subordonnée est signé par l’autorité racine et cette information doit être
mentionnée dans le certificat.

Création des AC  

La création des SubCA est une étape ultérieure à la création du profil de certificat de chacune.

Le certificat de SubCA généré renferme donc toutes les données saisies lors de la création du
profil de certificat mais toutes ces données apparaissent en des champs statiques qui ne sont
plus aptes à être modifiés ainsi que le profil de certificat que nous avons eu à l’appui (voir
annexe 4).

Outre ces informations-là, le certificat contient aussi 3 champs concernant la CRL. Le premier
détermine la périodicité de publication de la CRL qui est d’une CRL par jour, le deuxième
détermine la date butoir de validité de la CRL qui est de 1 jour et le troisième fixe le temps de
chevauchement entre la CRL émise et la CRL en cours d’expiration qui est de 30 minutes.
Ceci dit, 30 minutes avant que la CRL expire, une autre est republiée le même jour. Du coup,
nous gardons une continuité des mises à jour et nous ne risquons pas l’indisponibilité de la
CRL. Sans oublier le champ Subject DN de la SubCA.
La figure 13 représente le certificat de la Sub CA SupPersonnel Issuing CA.

Création des end entity certificate profile

La génération de end entity certificate profile qui correspond au certificate profile associé côté
personne ou serveur. Cette étape nous permet de désigner la vocation des certificats finaux qui
seront issus en définissant ce qu’on appelle le « key usage » et le « Extended Key usage » ou
bien l’usage de la clef et l’usage avancé de la clef car chaque certificat émis est destiné à un
usage spécifique.

La déclaration de la taille de bi clef RSA et de la validité qu’aura le certificat final se définit

dans le end entity certificate profile et elle est définie comme ceci :

Taille de la ci clef = 2048 bits ( elle est estimée largement suffisante pour un certificat final)

Validité= 730 jours (le certificat utilisateur est généralement valide pour 2 ans)

Le tableau 3 illustre nos choix d’usage pour les certificats Personne et Serveur :

Tableau 3: L'usage de la clef et l'usage avancé de la clef pour les Personnes et Serveurs

Client Serveur
Signature électronique Signature électronique

Key Usage Non répudiation Non répudiation

 Chiffrement de la clef Chiffrement de la clef

Extended Key Usage Authentification du client Authentification du serveur

Carte à puce Carte à puce

Création des end entity profile :

Nous avons dans notre politique hiérarchique bien structurée de génération de certificat selon
des règles bien étudiées. Nous en sommes à la génération de end entity profile qui sont une
sorte de modèle qui précède la génération des certificats finaux. Ce modèle est en revanche
optionnel mais nous avons choisi de l’adopter car il nous donne le choix d’ajouter tous les
champs dont nous avons besoins dans la phase finale de génération de certificats finaux. Il
suffira juste de remplir le formulaire là où les champs sont vides.

La figure nous montre la structure d’un end entity user profile

 Création des entités finales 

La phase de génération des entités finales n’est que la phase de génération de certificats pour
des utilisateurs finaux. Cette étape se réduit à l’insertion des données personnelles du
demandeur de certificat et au choix du format du certificat à savoir, PEM ou P12. Nous avons
choisi l’extension .p12 car le format PKCS#12 est une sorte de format texte qui stocke les
clefs privées et les certificats dans un seul fichier chiffré.

Le format PEM quant à lui, il contient deux fichiers distincts, l’un pour stocker la clef privée
et l’autre pour la clef publique.

La figure nous montre un exemple de certificat serveur final :

Renouvellement de certificat

Le certificat émis peut être sujet au renouvellement si pour quelconque cause il expire. Bien
que le client dispose du droit de s’offrir un nouveau certificat, il peut néanmoins demander le
renouvellement de son certificat. Notre PKI respecte ce choix éventuel de la clientèle et va
jusqu’au bout de leurs caprices. En effet EJBCA a prévu une solution de renouvellement de
certificat qui respecte les auspices de sécurité fomentés au préalable.

La solution de renouvellement que nous avons prévue, contrairement à d’autres PKI, ne

préconise pas le changement de la clef privée et la conservation du certificat. Plus
performante et efficace, notre solution consiste à refaire un nouveau profil de certificat pour le
certificat à renouveler puis de régénérer l’ancien certificat après obtention de la réponse
positive du serveur.

Révocation et génération des CRL 

La validité temporelle d’un certificat représente la date au-delà de laquelle le certificat n’est
plus valide. Ceci n’empêche pas le fait que certains certificats peuvent devenir non valides
sous certaines circonstances. Dans ce cas, la CA doit révoquer le certificat dans une liste
horodatée dite CRL et la publier sur LDAP.

La figure nous montre comment récupérer une CRL à partir des pages d’administration sous
la rubrique CA Structure & CRRs for CA :

De ce fait, lorsque nous voulons utiliser un certificat, notre système vérifie sa signature et sa
validité en allant chercher l’existence de son numéro de série dans la CRL la plus récente. Si
le numéro de série existe dans la CRL, le certificat est alors révoqué sinon, il est valide.

Les CRL sont régulièrement mises à jour en vue de garantir une meilleure précision des
résultats de recherches et d’actualiser les modifications survenues.
 Déploiement de EJBCA

Nous revenons aux étapes de déploiement de EJBCA de la part du client.

Accès au pages publiques et authentification :

Le choix de la taille de la clef

Le téléchargement du certificat puis son importation au magasin de certificat du navigateur de

l’utilisateur
 Conclusion
Le but de ce projet est de mettre en place un système de sécurité infaillible et intransgressible
qui assure la confidentialité et impose un niveau de sécurité très élevé suite aux mesures
drastiques prises lors des choix de nos moyens cryptographiques. Après avoir mis en place
une architecture et politique de certification, cette PKI nous a délivré des certificats
électroniques finaux pour deux sortes de clients qui sont des personnes morales et des
serveurs.