Technologie SSL/TLS

Table des matières

Technologie SSL/TLS.................................................................................................................1
Table des matières...................................................................................................................1
Présentation............................................................................................................................1
SSL Simple ou Double authentification..............................................................................2
Texte de Référence..................................................................................................................2
Principe de fonctionnement....................................................................................................2
Habilitation..........................................................................................................................3
Mise en œuvre chez P.F. 2009................................................................................................3
Gestion des certificats.............................................................................................................4
Certificats Wildcard (omnidomaine en français)....................................................................4
SSL - Les certificats....................................................................................................................4
Introduction.............................................................................................................................5
Structure..................................................................................................................................5
Validation................................................................................................................................6
Liste de révocation - CRL.......................................................................................................9
SSL - Handshake - Simple authentification................................................................................9
SSL - Handshake - Double authentification.............................................................................11
Processus de Génération d'un certificat SSL.............................................................................12
Présentation...........................................................................................................................12
Demande d'un certificat........................................................................................................12
Réception du certificat..........................................................................................................14
Outils.....................................................................................................................................17

Présentation
Transport Layer Security (TLS), anciennement nommé Secure Sockets Layer
(SSL), est un protocole de sécurisation des échanges sur Internet, développé à
l'origine par Netscape (SSL version 2 et SSL version 3). Il a été renommé en
Transport Layer Security (TLS) par l'IETF suite au rachat du brevet de Netscape par
l'IETF en 2001. Le groupe de travail correspondant à l'IETF a permis la création des
RFC 2246 pour le TLS et RFC 4347 pour son équivalent en mode datagramme, le
DTLS. Depuis son rapatriement par l'IETF, le protocole TLS a vécu deux révisions
subséquentes : TLSv1.1 décrite dans la RFC 4346 et publiée en 2006 et TLSv1.2,
décrite par la RFC 5246 et publiée en 2008.

Il y a très peu de différences entre SSL version 3 et TLS version 1 (qui correspond à
la version 3.1 du protocole SSL) rendant les deux protocoles non interopérables,
mais TLS a mis en place un mécanisme de compatibilité ascendante avec SSL. En
outre, TLS diffère de SSL pour la génération des clés symétriques. Cette génération
est plus sécurisée dans TLS que dans SSLv3 dans la mesure où aucune étape de
l'algorithme ne repose uniquement sur MD5 pour lequel sont apparues des
faiblesses en cryptanalyse.
Par abus de langage, on parle de SSL pour désigner indifféremment SSL ou TLS.

TLS fonctionne suivant un mode client-serveur. Il fournit les objectifs de sécurité

suivants :

• l'authentification du serveur
• la confidentialité des données échangées (ou session chiffrée)
• l'intégrité des données échangées
• de manière optionnelle, l'authentification ou l'authentification forte du client
avec l'utilisation d'un certificat numérique
• la spontanéité, c.-à-d. qu'un client peut se connecter de façon transparente à
un serveur auquel il se connecte pour la première fois
• la transparence, qui a contribué certainement à sa popularité. Du fait que les
protocoles de la couche d'application n'aient pas à être modifiés pour utiliser
une connexion sécurisée par TLS. Par exemple, le protocole HTTP est
identique, que l'on se connecte à un schème http ou https.

SSL Simple ou Double authentification

Dans la majorité des cas, l'utilisateur authentifie le serveur TLS sur lequel il se
connecte. Cette authentification est réalisée par l'utilisation d'un certificat numérique
X.509 délivré par une autorité de certification (AC). Mais de plus en plus
d'applications web utilisent maintenant l'authentification du poste client en exploitant
TLS. Il est alors possible d'offrir une authentification mutuelle entre le client et le
serveur. Le certificat client peut être stocké au format logiciel sur le poste client ou au
format matériel (carte à puce, token USB) pour augmenter la sécurité du lien TLS.
Cette solution permet d'offrir des mécanismes d'authentification forte.

Texte de Référence
• Transport Layer Security version française simplifié
• Transport Layer Security version anglaise plus complète
• Certificat numérique
• Certificat SSL Howto
• Les certificats
• X.509 : La norme régissant les certificats (version française simplifié)
• X.509 (version anglaise plus complète)

Principe de fonctionnement
Pour faire simple, le protocole SSL (et maintenant TLS) repose essentiellement sur 2
mécanismes :

• un cryptage asymétrique : un couple de clef publique/clef privée

• un(des) certificat(s) de sécurité permettant d'associer une identité à la clef
publique.
Le couple clef publique/clef privée permet de crypter/décrypter un message (ou
inversement). Le serveur conservant sa clef privée, et publiant sa clef publique à
toutes parties voulant dialoguer avec lui.

La validité du certificat de sécurité est assuré par d'autres certificat de sécurité(ou

autorité de certification) que sont jugés sure, et qui sont installés sur le système.
C'est ce mécanisme que nous appelons une chaine de certification.

• Par défaut, les certificats des principales autorités de certification (Verisign,

Keynectis, etc...) sont installés sur les navigateurs.
• Tout les postes BNP contiennent un certificat BNP faisant office d'autorité de
certification sur toutes les applications de type intranet, certificat installé sur le
navigateur d'entreprise (Internet Explorer).
• Dans la JVM de Sun, le keystore ${JAVA_HOME}/jre/lib/security/cacerts
(password : 'changeit') contient les principales autorités de certification.

Dans le détail, l'emploi de SSL repose sur les processus suivants :

• L'identification est portée par le certificat de sécurité lui même.

o Introduction
o Structure
• L'authentification se fait lors de la validation des certificats de sécurité dans la
phase TLS Handshake.
o Handshake TLS
 Simple authentification
 Double authentification
o Validation du certificat
• l'Habilitation, ou comment donner le droit à un client d'utiliser un service
• La révocation des certificats
• Le renouvellement des certificats

Habilitation

D'un point de vue serveur, la double authentification SSL v3 permet d'identifier et

d'authentifier les clients d'un service. Maintenant il faut trouver le moyen de
sélectionner les clients qui ont le droit d'utiliser un service (principe d'habilitation).

SSL nous donne comme moyen la hiérarchie des certificats. Les certificats clients
sont tous issue d'un certificat de niveau intermédiaire, permettant de filtrer par
rapport à ce certificat.

Mise en œuvre chez P.F. 2009

Dans notre infrastructure classique, le SSL est décrypter par les load-balancer F5,
puis nous sommes en HTTP des RPF jusqu'aux WebLogic. Si nous avons besoin
d'information en provenance des certificats clients utilisés, les load-balancer sont
capable de rajouter dans un header HTTP l'information dont nous avons besoin.
 Le problème de l'habilitation telle que possible via SSLv3 réside dans sa
complexité de gestion sur le long terme, et le fait que ce ne soit pas très souple
(habilitation de l'ensemble des certificats issue de la chaine de certificat du serveur,
et pas seulement le certificat de niveau intermédiaire).

Une solution est actuellement à l'étude chez ITPS/BP2I pour

• soit faire l'habilitation au niveau d'un RPF blacklist

• soit au niveau applicatif
• par liste blanche de certificats clients sur le load-balancer, complexifiant
la phase de renouvellement

Pour le moment, nous ne disposons pas de CRL, solution à l'étude chez

ITPS/BP2I.

Gestion des certificats

Un certificat numérique n'est valable que par rapport à une autorité de certification.
L'autorité de certification peut-être privée ou publique. Les critères de choix sont
nombreux, mais il ne faut pas oublier que les clients doivent toujours avoir un accès
HTTP vers l'autorité de certification pour récupérer la liste des certificats révoqués.
Raison pour laquelle il est déconseillé d'installer en intranet des certificats d'une
autorité de certification publique, vu que par défaut en intranet nous n'avons pas
accès à internet.

1. Processus de génération d'un certificat SSL : basé sur RefWeb ?

2. Processus de renouvellement de certificat
1. Simple Authentification
1. Certificat Serveur
2. Autorité de certification
2. Double Authentification
1. Certificat Client
2. Certificat Serveur
3. Autorité de certification

Certificats Wildcard (omnidomaine en français)

Technologie inutilisée a priori chez BNPP à ce jour (4/2010).

cf info TBS : prix, compatibilité navigateurs, faq

Resource externe

• Oracle : Mutual Authentication

SSL - Les certificats

Introduction
X.509 est une norme de cryptographie de l'Union internationale des
télécommunications pour les infrastructures à clés publiques (PKI). X.509 établit
entre autres les formats standard de certificats électroniques et un algorithme pour la
validation de chemin de certification.

X.509 a été créé en 1988 dans le cadre de la norme X.500. Il repose sur un système
hiérarchique d'autorités de certification, à l'inverse des réseaux de confiance (comme
PGP), où n'importe qui peut signer (et donc valider) les certificats des autres.

Dans le système X.509, une autorité de certification attribue un certificat liant une clé
publique à un nom distinctif (Distinguished Name), à une adresse électronique ou un
enregistrement DNS.

Les certificats racines sont des clés publiques non signées, ou auto-signées, dans
lesquels repose la confiance. Des autorités de certification commerciales détiennent
des certificats racines présents dans de nombreux logiciels, par exemple les
navigateurs Web. Quand le navigateur ouvre une connexion sécurisée (SSL) vers un
site ayant acheté une certification auprès d'une autorité connue, il considère le site
comme sûr dans la mesure où le chemin de certification est validé. Le passage en
mode sécurisé est alors transparent.

Si le certificat est auto-signé (autorité de certification et créateur de la clé publique ne

font qu'un), le navigateur propose de l'examiner, puis de l'accepter ou de le refuser
selon la confiance qu'on lui accorde.

La durée de validité des certifications commerciales n'est pas infinie, elles expirent
souvent au bout d'un an et doivent être renouvelées.

Structure
Les certificats sont des petits fichiers divisés en deux parties :

• La partie contenant les informations

• La partie contenant la signature de l'autorité de certification

La structure des certificats est normalisée par le standard X.509 de l'UIT (plus
exactement X.509v3), qui définit les informations contenues dans le certificat :

1. La version de X.509 à laquelle le certificat correspond

2. Le numéro de série du certificat
3. L'algorithme de chiffrement utilisé pour signer le certificat
4. Le nom (DN, pour Distinguished Name) de l'autorité de certification émettrice
5. Validité
1. La date de début de validité du certificat
2. La date de fin de validité du certificat
6. Détenteur du certificat
7. Information sur la clé publique
 1. Algorithme de la clé publique
2. Clé publique proprement dite
8. Identifiant unique du signataire (optionnel, à partir de X.509 version 2)
9. Identifiant unique du détenteur du certificat (optionnel, à partir de X.509
version 2)
10. Extensions (optionnel, à partir de X.509 version 3)

o Liste des extensions

2. La signature de l'émetteur du certificat (thumbprint)

Rien parmi les champs obligatoires ne permet de distinguer une autorité de

certification (une organisation émettrice de certificats) d'un simple titulaire.
L'extension basicConstraints définie dans X.509 version 3 comble cette limitation.
Une autre imperfection du même type est que seul le nom permet de lier un certificat
à celui de son émetteur alors que l'on ne peut pas garantir l'unicité des noms.

L'ensemble de ces informations (informations + clé publique du demandeur) est

signé par l'autorité de certification, cela signifie :

1. Une fonction de hachage crée une empreinte de ces informations

2. Ce condensé est chiffré à l'aide de la clé privée de l'autorité de certification; la
clé publique ayant été préalablement largement diffusée afin de permettre aux
utilisateurs de vérifier la signature avec la clé publique de l'autorité de certification.

Validation
Pour valider un certificat, il faut récupérer la chaine de certification complète. Un
certificat est valide par rapport à un autre certificat, le certificat de plus haut niveau
référençant l'autorité de certification auquel vous avez accordé votre confiance, et qui
est installé sur votre système, ou application.

Certificate:
Data:
Version: 1 (0x0)
Serial Number: 7829 (0x1e95)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
OU=Certification Services Division,
CN=Thawte Server CA/emailAddress=server-certs@thawte.com
Validity
Not Before: Jul 9 16:04:02 1998 GMT
Not After : Jul 9 16:04:02 1999 GMT
Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,
OU=FreeSoft, CN=www.freesoft.org/emailAddress=baccala@freesoft.org
Subject Public Key Info:
 Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:b4:31:98:0a:c4:bc:62:c1:88:aa:dc:b0:c8:bb:
33:35:19:d5:0c:64:b9:3d:41:b2:96:fc:f3:31:e1:
66:36:d0:8e:56:12:44:ba:75:eb:e8:1c:9c:5b:66:
70:33:52:14:c9:ec:4f:91:51:70:39:de:53:85:17:
16:94:6e:ee:f4:d5:6f:d5:ca:b3:47:5e:1b:0c:7b:
c5:cc:2b:6b:c1:90:c3:16:31:0d:bf:7a:c7:47:77:
8f:a0:21:c7:4c:d0:16:65:00:c1:0f:d7:b8:80:e3:
d2:75:6b:c1:ea:9e:5c:5c:ea:7d:c1:a1:10:bc:b8:
e8:35:1c:9e:27:52:7e:41:8f
Exponent: 65537 (0x10001)
Signature Algorithm: md5WithRSAEncryption
93:5f:8f:5f:c5:af:bf:0a:ab:a5:6d:fb:24:5f:b6:59:5d:9d:
92:2e:4a:1b:8b:ac:7d:99:17:5d:cd:19:f6:ad:ef:63:2f:92:
ab:2f:4b:cf:0a:13:90:ee:2c:0e:43:03:be:f6:ea:8e:9c:67:
d0:a2:40:03:f7:ef:6a:15:09:79:a9:46:ed:b7:16:1b:41:72:
0d:19:aa:ad:dd:9a:df:ab:97:50:65:f5:5e:85:a6:ef:19:d1:
5a:de:9d:ea:63:cd:cb:cc:6d:5d:01:85:b5:6d:c8:f3:d9:f7:
8f:0e:fc:ba:1f:34:e9:96:6e:6c:cf:f2:ef:9b:bf:de:b5:22:
68:9f

Voici un exemple de certificat X.509 pour www.freesoft.org, généré par

OpenSSL.Ce certificat fait a peu prés 1ko. Il est issue de Thawte(récemment acquis
par Verisign) comme précisé dans le champs 'Issuer'.

Il contient plusieurs informations personnel, dont le plus important est

habituellement le nom usuel (ou common name, CN), c'est la partie qui doit
correspondre à l'hôte où nous avons récupéré ce certificat.

Est également inclus une clef publique de type RSA, suivi de la signature, calculé
à partir d'un algorithme de hachage (ici MD5, mais nous rencontrons fréquemment
du SHA-1 depuis que MD5 est jugé peu sure) et signé en utilisant la clé privé RSA
de Thawte.

Pour valider ce certificat, il faut un deuxième certificat qui correspond à l'émetteur

(Thawte Server CA) de la première attestation.

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
 Signature Algorithm: md5WithRSAEncryption
Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
OU=Certification Services Division,
CN=Thawte Server CA/emailAddress=server-certs@thawte.com
Validity
Not Before: Aug 1 00:00:00 1996 GMT
Not After : Dec 31 23:59:59 2020 GMT
Subject: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
OU=Certification Services Division,
CN=Thawte Server CA/emailAddress=server-certs@thawte.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:d3:a4:50:6e:c8:ff:56:6b:e6:cf:5d:b6:ea:0c:
68:75:47:a2:aa:c2:da:84:25:fc:a8:f4:47:51:da:
85:b5:20:74:94:86:1e:0f:75:c9:e9:08:61:f5:06:
6d:30:6e:15:19:02:e9:52:c0:62:db:4d:99:9e:e2:
6a:0c:44:38:cd:fe:be:e3:64:09:70:c5:fe:b1:6b:
29:b6:2f:49:c8:3b:d4:27:04:25:10:97:2f:e7:90:
6d:c0:28:42:99:d7:4c:43:de:c3:f5:21:6d:54:9f:
5d:c3:58:e1:c0:e4:d9:5b:b0:b8:dc:b4:7b:df:36:
3a:c2:b5:66:22:12:d6:87:0d
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
Signature Algorithm: md5WithRSAEncryption
07:fa:4c:69:5c:fb:95:cc:46:ee:85:83:4d:21:30:8e:ca:d9:
a8:6f:49:1a:e6:da:51:e3:60:70:6c:84:61:11:a1:1a:c8:48:
3e:59:43:7d:4f:95:3d:a1:8b:b7:0b:62:98:7a:75:8a:dd:88:
4e:4e:9e:40:db:a8:cc:32:74:b9:6f:0d:c6:e3:b3:44:0b:d9:
8a:6f:9a:29:9b:99:18:28:3b:d1:e3:40:28:9a:5a:3c:d5:b5:
e7:20:1b:8b:ca:a4:ab:8d:e9:51:d9:e2:4c:2c:59:a9:da:b9:
b2:75:1b:f6:42:f2:ef:c7:f2:18:f9:89:bc:a3:ff:8a:23:2e:
70:47

Tout d'abord, on vérifie que le deuxième certificat est d'un genre CA, signifiant qu'il
peut être utilisé pour émettre des certificats. Cela se fait par l'inspection d'une valeur
de l'attribut CA dans la section extension X509v3.
 Une fois les certificats parents vérifié, et validé, il faut désormais validé le certificat
courant. Comme vu précédemment, ce certificat contient le nom du destinataire,
ainsi que sa clé publique et est signé par l'autorité de certification.

Il est donc possible de vérifier la validité du message en :

1. appliquant la fonction de hachage aux informations contenues dans le

certificat
2. déchiffrant la signature du certificat avec la clé publique de l'autorité de
certification.
3. Comparant les deux résultats qui doivent être absolument identique.

Liste de révocation - CRL

Un certificat peut devenir invalide pour de nombreuses raisons autres que l'expiration
naturelle, telles que la perte ou la compromission de la clé privée associée au
certificat ou le changement d'au moins un champ inclus dans le nom du titulaire /
détenteur du certificat.

C'est pourquoi la norme définit le format d'une liste indiquant les certificats devenus
invalides pour une autorité de certification donnée. Cette liste est signée par l'autorité
de certification pour en empêcher toute modification par une personne non autorisée.

Elle comprend une date d'émission, une date de mise à jour (toutes deux
optionnelles) et la liste proprement dite sous la forme de paires (numéro de série du
certificat révoqué ; motif éventuel de révocation). Le motif ne peut être présent que
dans les CRL au format version 2.

Une limitation parfois gênante des CRL est le délai de propagation des informations
de révocation. Pour le réduire, le protocole OCSP de validation de certificat a été
développé. Défini dans la RFC 2560, il lui donne à peu près les mêmes informations
que les CRL, mais potentiellement plus à jour.

SSL - Handshake - Simple

authentification
A simple connection example, illustrating a handshake where the server is
authenticated by its certificate (but not the client), follows:

1. Negotiation phase:
o A client sends a ClientHello message specifying the highest TLS
protocol version it supports, a random number, a list of suggested
CipherSuites, and suggested compression methods.
 o The server responds with a ServerHello message, containing the
chosen protocol version, a random number, CipherSuite, and
compression method from the choices offered by the client. The server
may also send a session id as part of the message to perform a
resumed handshake.
o The server sends its Certificate message (depending on the selected
cipher suite, this may be omitted by the server).[12]
o The server sends a ServerHelloDone message, indicating it is done
with handshake negotiation.
o The client responds with a ClientKeyExchange message, which may
contain a PreMasterSecret, public key, or nothing. (Again, this depends
on the selected cipher.)
o The client and server then use the random numbers and
PreMasterSecret to compute a common secret, called the "master
secret". All other key data for this connection is derived from this master
secret (and the client- and server-generated random values), which is
passed through a carefully designed "pseudorandom function".

2. The client now sends a ChangeCipherSpec record, essentially telling the

server, "Everything I tell you from now on will be authenticated (and encrypted
if encryption parameters were present in the server certificate)." The
ChangeCipherSpec is itself a record-level protocol with content type of 20.
o Finally, the client sends an authenticated and encrypted Finished
message, containing a hash and MAC over the previous handshake
messages.
o The server will attempt to decrypt the client's Finished message, and
verify the hash and MAC. If the decryption or verification fails, the
handshake is considered to have failed and the connection should be
torn down.

3. Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I

tell you from now on will be authenticated (and encrypted with the server
private key associated to the public key in the server certificate, if encryption
was negotiated)."
o The server sends its authenticated and encrypted Finished message.
o The client performs the same decryption and verification.

4. Application phase: at this point, the "handshake" is complete and the

application protocol is enabled, with content type of 23. Application messages
exchanged between client and server will also be authenticated and optionally
encrypted exactly like in their Finished message.
 SSL - Handshake - Double
authentification
1. Negotiation phase:
o A client sends a ClientHello message specifying the highest TLS
protocol version it supports, a random number, a list of suggested
cipher suites and compression methods.
o The server responds with a ServerHello message, containing the
chosen protocol version, a random number, cipher suite, and
compression method from the choices offered by the client. The server
may also send a session id as part of the message to perform a
resumed handshake.
o The server sends its Certificate message (depending on the selected
cipher suite, this may be omitted by the server).[12]
o The server requests a certificate from the client, so that the connection
can be mutually authenticated, using a CertificateRequest message.
o The server sends a ServerHelloDone message, indicating it is done
with handshake negotiation.
o The client responds with a Certificate message, which contains the
client's certificate.
o The client sends a ClientKeyExchange message, which may contain a
PreMasterSecret, public key, or nothing. (Again, this depends on the
selected cipher.) This PreMasterSecret is encrypted using the public
key of the server certificate.
o The client sends a CertificateVerify message, which is a signature over
the previous handshake messages using the client's certificate's private
key. This signature can be verified by using the client's certificate's
public key. This lets the server know that the client has access to the
private key of the certificate and thus owns the certificate.
o The client and server then use the random numbers and
PreMasterSecret to compute a common secret, called the "master
secret". All other key data for this connection is derived from this master
secret (and the client- and server-generated random values), which is
passed through a carefully designed "pseudorandom function".

2. The client now sends a ChangeCipherSpec record, essentially telling the

server, "Everything I tell you from now on will be authenticated (and encrypted
if encryption was negotiated)." The ChangeCipherSpec is itself a record-level
protocol, and has type 20, and not 22.
o Finally, the client sends an encrypted Finished message, containing a
hash and MAC over the previous handshake messages.
o The server will attempt to decrypt the client's Finished message, and
verify the hash and MAC. If the decryption or verification fails, the
handshake is considered to have failed and the connection should be
torn down.
 3. Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I
tell you from now on will be authenticated (and encrypted if encryption was
negotiated)."
o The server sends its own encrypted Finished message.
o The client performs the same decryption and verification.

4. Application phase: at this point, the "handshake" is complete and the

application protocol is enabled, with content type of 23. Application messages
exchanged between client and server will also be encrypted exactly like in
their Finished message.

Processus de Génération d'un

certificat SSL
Présentation
En Java, les certificats sont stockes dans des fichiers binaires, appelé des KeyStore.
Un keystore est une base de données des clés. Il existe différents types de magasins
de clés disponibles, les principaux etant " PKCS12" et "Sun JKS".

• SUN JKS : C'est le format par défaut des magasins de certificats Java.
• PKCS12 : Le PKCS # 12 (Personal Information Exchange Syntax Standard)
spécifie un format portable pour le stockage et/ou le transport des clés privées
d'un utilisateur, les certificats, les secrets divers, et d'autres articles. La JVM
offre une mise en œuvre complète du format PKCS12. Ce format est
également soutenue par d'autres toolkits, et les demandes d'importation et
d'exportation clés et des certificats, tel que Netscape / Mozilla, Internet
Explorer de Microsoft, et OpenSSL. Ces implémentations peuvent exporter
des certificats clients et les clés dans un fichier en utilisant l'extension ". P12"

Pour eviter à l'utilisateur d'avoir à accepter à chaque fois le certificat de l'applet, ou

de l'installer sur son poste, nous allons faire une demande de certificat à la sécurité
groupe. Le certificat fournit sera un certificat interne, valable uniquement sur les
navigateurs internets du Groupe (disposant du certificat Groupe).

Pour ce faire, il faut remplir la demande de certificat en fournissant un CSR (Certificat

Request) => Application / TXT pour le type de certificat.

Demande d'un certificat

Ceci est le processus officiel de génération de certificat. Cette méthode permet de
garantir la confidentialité de la clef privée.
1. Génération d'un couple de clef assymétrique et stockage dans un Keystore

Exemple de commande : keytool -genkey -alias keytarif -keystore <nom

du fichier>.jks -keysize 1024 -keyalg RSA

Enter keystore password: toto89

What is your first and last name?
[Unknown]: David N'DIAYE
What is the name of your organizational unit?
[Unknown]: AST / TAM /JEE
What is the name of your organization?
[Unknown]: BNP Paribas Personal Finance
What is the name of your City or Locality?
[Unknown]: Saint Ouen
What is the name of your State or Province?
[Unknown]: Ile de France
What is the two-letter country code for this unit?
[Unknown]: FR
Is <CN=David N'DIAYE, OU=AST / TAM / JEE, O=BNP Paribas
Personal Finance, L=Saint Ouen, ST=Ile de France, C=FR>
correct?
[no]: yes

Enter key password for <keytarif>

(RETURN if same as keystore password): keyTarifpwd

2. Vérification du contenu du keystore

Commande : keytool -list -keystore tarif.keystore -storepass

toto89

Type Keystore : JKS

Fournisseur Keystore : SUN

Votre Keystore contient 1 entrée(s)

keytarif, 7 mai 2010, PrivateKeyEntry,

Empreinte du certificat (MD5) :
6E:C6:5C:18:BE:06:65:F6:FD:CB:47:46:0D:42:A5:B2

3. Génération d'un CSR

 CSR : Certificate Signing Request
Le CSR va nous permettre d'envoyer à l'autorité de certification notre demade de certificat associé à
notre clef publique.
keytool -certreq -alias keytarif -keypass keyTarifpwd -keystore
tarif.keystore -storepass toto89 -file tarif.csr
Contenu du fichier tarif.csr :

-----BEGIN NEW CERTIFICATE REQUEST-----

MIIChTCCAkMCAQAwgYAxCzAJBgNVBAYTAmZyMQ8wDQYDVQQIEwZGcmFuY2UxEz
ARBgNVBAcTClNh
aW50IE91ZW4xJTAjBgNVBAoTHEJOUCBQYXJpYmFzIFBlcnNvbmFsIEZpbmFuY2
UxDDAKBgNVBAsT
A1RFTzEWMBQGA1UEAxMNRGF2aWQgTidESUFZRTCCAbcwggEsBgcqhkjOOAQBMI
IBHwKBgQD9f1OB
HXUSKVLfSpwu7OTn9hG3UjzvRADDHj+AtlEmaUVdQCJR+1k9jVj6v8X1ujD2y5
tVbNeBO4AdNG/y
ZmC3a5lQpaSfn+gEexAiwk+7qdf+t8Yb+DtX58aophUPBPuD9tPFHsMCNVQTWh
aRMvZ1864rYdcq
7/IiAxmd0UgBxwIVAJdgUI8VIwvMspK5gqLrhAvwWBz1AoGBAPfhoIXWmz3ey7
yrXDa4V7l5lK+7
+jrqgvlXTAs9B4JnUVlXjrrUWU/mcQcQgYC0SRZxI+hMKBYTt88JMozIpuE8Fn
qLVHyNKOCjrh4r
s6Z1kW6jfwv6ITVi8ftiegEkO8yk8b6oUZCJqIPf4VrlnwaSi2ZegHtVJWQBTD
v+z0kqA4GEAAKB
gDCzcEAv5mZiaSNqPIQmdJn9FePh6UyToc3j4s46vp7TGl6YSiECqqMU07CN/v
fovTmnFdDeiplC
wS+V7LW7nBgZF180E5tVGVE7Uk+3/xtDFXOiWsBjst0sqUlRpZzqkaqEWZK6Af
JR2G/iPjhCQg8t
g+TvO7wrmf/nRBOta3pGoAAwCwYHKoZIzjgEAwUAAy8AMCwCFBx4gzze6RVJ5L
2P6SY9cFkFQhOA
AhRXFKPRxL+h0biUe+e9Zdexn9WQyw==
-----END NEW CERTIFICATE REQUEST-----

4. Envoi du CSR à l'autorité de certification.

Réception du certificat
Le certificat récupéré est un certificat Chainé, logiquement nous avons récupéré un
ensemble de ficheir *.cer, représentant le certificat demandé, et sa chaine de
certification jusqu'au certificat racine.
Il faut ajouter les certificats dans le magasin de certificat dans l'ordre, en
commençant par le certificat racine.

1. Import du certificat racine, dans notre cas le certificat Group

keytool -importcert -alias group -file <fichier .cer>

-trustcacerts -keystore <nom du fichier>.jks -storepass
<password>

Propriétaire : OU=applications, O=Group

Émetteur : O=Group
Numéro de série : 3c5ffe3b
Valide du : Wed Feb 06 11:29:07 MET 2002 au : Sun Feb 05
16:45:40 MET 2017
Empreintes du certificat :
MD5 : AB:84:B2:AA:DA:19:75:02:11:10:F1:AF:49:3E:EA:CC
SHA1 :
99:AA:BC:F3:53:9A:C2:B7:8E:66:2A:D3:07:BE:98:E8:49:1F:8D:18
Nom de lalgorithme de signature : {7}
Version : {8}

Extensions :
...
...
Faire confiance à ce certificat ? [non] : oui
Certificat ajouté au Keystore

2. Import des certificats intermédiaire

keytool -importcert -alias application -file <fichier .cer>

-keystore <nom du fichier>.jks -storepass <password>

Certificat ajouté au Keystore

3. Vérification du contenu du keystore

Commande : keytool -list -keystore <nom du fichier>.jks -storepass

<password>

Type Keystore : JKS

Fournisseur Keystore : SUN
 Votre Keystore contient 3 entrée(s)

keytarif, 7 mai 2010, PrivateKeyEntry,

Empreinte du certificat (MD5) :
6E:C6:5C:18:BE:06:65:F6:FD:CB:47:46:0D:42:A5:B2
application, 7 mai 2010, trustedCertEntry,
Empreinte du certificat (MD5) :
AB:84:B2:AA:DA:19:75:02:11:10:F1:AF:49:3E:EA:CC
group, 7 mai 2010, trustedCertEntry,
Empreinte du certificat (MD5) :
FD:7E:6E:A6:13:C5:A8:FC:41:40:0C:CD:71:13:B8:F3

4. Import du certificat de l'application IntTarif

keytool -importcert -alias keytarif -file <fichier .cer>

-keystore tarif.keystore -storepass <password> -keypass
<password de la clef>

Certificate reply was installed in keystore

5. Check des certificats

keytool -list -keystore <nom du fichier>.jks -storepass

<password>

Type Keystore : JKS

Fournisseur Keystore : SUN

Votre Keystore contient 3 entrée(s)

keytarif, 7 mai 2010, keyEntry,

Empreinte du certificat (MD5) :
6E:C6:5C:18:BE:06:65:F6:FD:CB:47:46:0D:42:A5:B2
application, 7 mai 2010, trustedCertEntry,
Empreinte du certificat (MD5) :
AB:84:B2:AA:DA:19:75:02:11:10:F1:AF:49:3E:EA:CC
group, 7 mai 2010, trustedCertEntry,
Empreinte du certificat (MD5) :
FD:7E:6E:A6:13:C5:A8:FC:41:40:0C:CD:71:13:B8:F3
Outils
Un chouette outil pour manipuler les magasins de certificats : le portecle (Projet
SourceForge)