Techno Doc sur le SSL
Content
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. 2. 3. 4. 5. La version de X.509 à laquelle le certificat correspond Le numéro de série du certificat L'algorithme de chiffrement utilisé pour signer le certificat Le nom (DN, pour Distinguished Name) de l'autorité de certification émettrice 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/[email protected] 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/[email protected] 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/[email protected] 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/[email protected] 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
o o o
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. The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by the server).[12] The server sends a ServerHelloDone message, indicating it is done with handshake negotiation. The client responds with a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.) 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] : Certificat ajouté au Keystore oui
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)
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. 2. 3. 4. 5. La version de X.509 à laquelle le certificat correspond Le numéro de série du certificat L'algorithme de chiffrement utilisé pour signer le certificat Le nom (DN, pour Distinguished Name) de l'autorité de certification émettrice 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/[email protected] 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/[email protected] 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/[email protected] 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/[email protected] 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
o o o
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. The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by the server).[12] The server sends a ServerHelloDone message, indicating it is done with handshake negotiation. The client responds with a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.) 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] : Certificat ajouté au Keystore oui
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)
