0. Openssl SYNOPSIS. TP Crypto / Certificats Openssl TLS

Transcription

1 0. Openssl SYNOPSIS TP Crypto / Certificats Openssl TLS openssl commande [ options_commande ] [ arguments_commande ] openssl [commandes-standard-liste commandes-signature-messages-liste commande-chiffrement-liste] openssl no-xxx [options arbitraires] DESCRIPTIO OpenSSL est un utilitaire cryptographique qui implémente les protocoles réseau Secure Sockets Layer (SSL v2/v3, Couche de sockets sécurisés) et Transport Layer Security (TLS v1, sécurité pour la couche de transport) ainsi que les standards cryptographiques liés dont ils ont besoin. Le programme openssl est un outil de ligne de commande pour utiliser les différentes fonctions cryptographiques de la librairie crypto d'openssl à partir du shell. Il peut être utilisé pour - Création de paramètres des clefs RSA, DH et DSA - Création de certificats X.509, CSRs et CRLs - Calcul de signature de messages - Chiffrement et Déchiffrement - Tests SSL/TLS client et server - Gestion de mail S/MIME signé ou chiffrés RÉSUMÉ DES COMMA DES Le programme openssl fournit une variété de commandes (commande dans la SYNOPSIS cidessus), dont chacune possède de nombreuses options et arguments. (options-commande and arguments-commande dans la SYNOPSIS). Les commandes-pseudo commandes-standard-liste, commandes-signature-message-liste, et commande-chiffrement-liste génèrent une liste (une entrée par ligne) des noms de toutes les commandes standards, commandes de signature de messages (NdT ex: MD5) ou commandes de chiffrement, respectivement, qui sont disponible dans le présent utilitaire openssl. La commande-pseudo no-xxx teste si une commande du nom donné existe. Si aucune commande nommée XXX n'existe, le retour vaut 0 (succès) et l'affichage no-xxx ; sinon le retour vaut 1 et l'affichage XXX. Dans les deux cas, la sortie est dirigée vers stdout (NdT : Sortie standard) et le flux stderr n'est pas utilisé. Les arguments de ligne de commande supplémentaires sont ignorés. Comme pour chaque chiffrement, il existe une commande portant le même nom, ceci fournit aux scripts shell une façon simple de tester la disponibilité des chiffrement dans le program openssl. (no-xxx n'est pas capable de détecter des commandes-pseudo tel que quit, list-...-commands, ou no-xxx lui-même.) COMMA DES STA DARDS asn1parse Traitement d'une séquence ASN.1. ca Ciphers Gestion Certificate Authority (CA). Détermination de la description de la suite de chiffrement. Crl crl2pkcs7 Dgst Dh Dsa Dsaparam Enc Errstr Dhparam Gendh Gendsa Genrsa Passwd pkcs7 Rand Req Rsa Rsautl Smime Speed Verify Version x509 md5 sha1 base64 des3 Gestion Certificate Revocation List (CRL). Conversion CRL vers PKCS#7. Calcul empreinte message (MD5). Gestion des paramètres Diffie-Hellman. Obsolète par dhparam. Gestion données DSA. Génération paramètres DSA. Chiffrement. Conversion numéro d'erreur vers descriptif texte (String). Génération et gestion de paramètres Diffie-Hellman. Génération de paramètres Diffie-Hellman. Obsolète par dhparam. Génération de paramètres DSA. Génération de paramètres RSA. Génération de mots de passe hashés. Gestion données PKCS#7. Génère octets pseudo-aléatoires. Gestion X.509 Certificate Signing Request (CSR). Gestion données RSA. Utilitaire RSA pour signature, vérification, chiffrement, et déchiffrement. Traitement mails S/MIME. Mesure la vitesse de l'algorithme. Vérification du certificat X.509. Information sur la version d'openssl. Gestion de données pour le certificat X.509. Signature MD5 Signature SHA-1 Chiffrement Base64 Chiffrement Triple-DES.. Utilisation basique de OpenSSL Tester et décrire le résultat des commandes suivantes : Openssl dgst /etc/passwd Echo n "aaa" openssl dgst sha1 Openssl passwd 1 salt Q/4YuT.T monpassword Dans ce dernier exemple, vous pouvez essayer le sel trouvé dans le fichier /etc/shadow (deuxième champ délimité par $) et votre mot de passe (entre ). Cet algo de hachage est identique à celui utilisé dans /etc/shadow. I. Elements de base du TP Le principale objectif du TP est la «mise en oeuvre de TLS/SSL». En particulier, nous verrons comment - Créer / Gérer des certificats / Tester /Vérifier des certificats - Réalisation d une chaîne de certification - Initialisation d une communication SSL entre Client/Serveur Nous allons créer trois certificats Certificats nécessaires Le premier certificat correspondra au certificat d'une autorité racine de certification (root CA). Il en faut une obligatoirement. Son certificat sera donc nécessairement auto-signé. Le nom du fichier contenant le certificat sera ca.pem. Le deuxième certificat correspondra à une autre autorité de certification (cette autorité sera par exemple l'autorité chargée de valider les certificats de serveurs LDAP) ; toutefois, cette autorité (ldap CA) ne sera pas racine. Son certificat sera donc signé par l'autorité racine root CA. Le nom du fichier contenant le certificat sera ldapca.pem. Un troisième certificat identifiera le serveur LDAP ; nous appellerons ce certificat serveur.pem. Il sera signé par l'autorité ldap CA. Une version allégée peut n utiliser que le certificat de l'autorité intermédiaire (ldap CA) et signerait le certificat serveur par celui de l'autorité racine de certification (root CA). I.2. Organisation des certificats Il faut organiser les différents certificats de façon à ce que les clients et serveurs puissent les trouver et les tester. Tout d abord, il est possible de profiter de l'organisation proposée dans le fichier de configuration de openssl. Autrement dit, dans le fichier openssl.conf. Celui ci utilise l'organisation suivante : - $dir = le répertoire de base où sont situés tous les différents certificats, clés privées, etc., par exemple ~/ssl ; /usr/local/ssl ; - $dir/certs = le répertoire où sont conservés les certificats (plus exactement, des noms de la forme hash.0) - $dir/crl = le répertoire où sont conservées les listes de révocation. - $dir/newcerts = le répertoire où sont stockés les certificats nouvellement créés. - $dir/private = le répertoire où sont stockées les clés privées - $dir/serial = le fichier qui contient le prochain numéro de série pour tout nouveau certificat qui sera créé. Il sert à initialiser le compteur de certificats. On peut le créer par la commande : «echo 01 > serial» - $dir/index.txt = le fichier d'index de la base de données des certificats. Pour le créer, on peut par exemple taper la commande «touch index.txt» - le répertoire $dir devra vous appartenir (e.g., sous-répertoire du répertoire de travail). - Le certificat racine est placé directement dans $dir. - La clé privée du certificat racine est dans $dir/private. - Pour tester la validité d'un certificat, il faut tester la validité de la chaîne complète des certificats jusqu'au certificat racine. Ainsi, si par exemple un client souhaite valider le certificat du serveur, il devra avoir accès aux certificats ldapca.pem et ca.pem. Il faut donc posséder localement les certificats permettant de tester la chaîne de certificats. I.3. Fichiers de configuration pour openssl. Bien qu'il soit théoriquement possible de créer et gérer des certificats en utilisant le fichier de configuration principal de openssl (i.e., openssl.cnf), il est plus judicieux d'utiliser divers fichiers de configuration pour les différents cas de figures que l'on va rencontrer (voir annexe). Ces fichiers de configuration doivent donc appartenir au répertoire «$dir» Bien évidemment, il conviendra d'adapter ces différents fichiers de configuration en annexeà votre propre utilisation/configuration. II. Création des certificats II.1. Création du certificat de l'autorité de certification root CA Voici la commande nécessaire : openssl req -x509 config root-ca-cert.cnf -newkey rsa out ca.pem keyout private/ca.key days 1826 Le paramètre x509 de la requête ci-dessus permet d'avoir un certificat auto-signé. La commande utilise le fichier de configuration root-ca-cert.cnf. Le certificat est crée pour une durée de 5 ans (soit 1826 jours). N'oubliez pas de spécifier une durée de validité pour ce certificat en particulier. Sinon, on obtiendrait une durée de validité de 0 seconde, ce qui est relativement assez peu!! Les fichiers résultants : - ca.pem qui contiendra le certificat proprement dit, et - ca.key qui contiendra la clé privée associée. La requête demande une «phrase pass» pour la clé privée, et un DN pour l'identification du certificat. Le DN 1 (Distinguish Name) choisi est par exemple : cn=ensib MRI root CA, ou=mri, o=ensib, l=bourges, st=cher, c=fr Mais vous avez bien sûr la possibilité de créer votre propre DN pour votre certificat racine. Création d'un fichier hash.0 Pour chaque certificat nouvellement créé, il est important de créer un fichier (symbolique) dont le nom est de la forme hash.0, dans laquelle hash est la valeur de hachage du DN. Si ceci n'était pas fait, il serait difficile de vérifier une chaîne de certificats. Les fichiers hash.0 sont à placer de préférence dans le répertoire Pour obtenir la valeur de hachage du fichier ca.pem par exemple, il suffit de taper la commande suivante : openssl x509 -hash -in ca.pem -noout 1 De manière générale, un DN représente le nom de l'entrée (certificat) sous la forme du chemin d'accès à celleci depuis le sommet de l'arbre. On peut comparer le DN au path d'un fichier Unix.

2 Le paramètre noout permet de ne pas afficher la totalité du certificat ; on n'obtiendra par conséquent que la valeur de hachage recherchée. Le fichier hash.0 doit ensuite pointer vers le vrai fichier cacert.pem. Exemple : ln -s../ca.pem 56ffeb3f.0 Ou bien, en supposant que l'on soit dans le répertoire certs et en fusionnant les deux commandes précédentes : ln -s../ca.pem `openssl x509 -hash -in../ca.pem -noout`.0 II.2. Création d'un certificat pour l'autorité ldap CA Tout d'abord, on crée un certificat temporaire et une clé privée normale : openssl req -config req-subca-cert.cnf -newkey rsa -out templdapcacert.pem -keyout private/ldapca.key Le fichier de configuration sélectionné est req-subca-cert.cnf. Les fichiers résultants sont templdapcacert.pem et ldapca.key. Il faut également une phrase de passe et un DN. Mon DN est : cn=ensib MRI LDAP CA, ou=mri, o=ensib, l=bourges, st=cher, c=fr Signature du certificat de ldap CA par l'autorité racine root CA A ce moment le certificat signé n'est plus temporaire et il est donc automatiquement placé (grâce à la commande ci-dessous) dans le répertoire newcerts sous le nom xy.pem dans lequel xy est la valeur contenue dans le fichier serial (par exemple, le fichier créé sera 01.pem) : openssl ca config ca-subca-cert.cnf in templdapcacert.pem -notext -out certs/ldapca.pem La commande ci-dessus crée également un fichier ldapca.pem dans le répertoire Pourquoi? Eh bien, si le fichier 01.pem est peut-être gentiment et automatiquement créé par openssl, son nom n'est pas très parlant à l'esprit. Il vaut mieux que le nom du fichier soit représentatif du certificat qu'il contient. La base de données des certificats sera bien évidemment mise à jour (modification des fichiers serial et index.txt) Le fichier templdapcacert.pem peut alors être détruit si vous le désirez. Il faut bien entendu également créer un fichier symbolique de la forme hash.0 comme dans le cas du certificat ca.pem. Par exemple : ln -s ldapca.pem c9ce0d54.0 ou bien : ln -s ldapca.pem `openssl x509 -hash -in ldapca.pem -noout`.0 II.3. Création du certificat pour le servuer Commande utilisée : Création d'une requête de certificat pour le serveur openssl req -config req-server-cert.cnf -out tempservercert.pem -keyout private/serveur.key -newkey rsa Cette commande génère un certificat temporaire (tempservercert.pem) qui devra être signé plus tard par une autorité de certification. La clé privée est définitive et est donc placée dans le répertoire des clés privées. Le fichier de configuration utilisée est req-server-cert.cnf. Exemple de DN : cn=xyz.ensi-bourges.fr, ou=mri, o=ensib, l=bourges, st=cher, c=fr Remarque : On notera que le véritable cn n'est pas n'importe quoi, mais doit être le nom de la machine sur laquelle tournera le serveur ldap remplacez xyz par un nom valide de machine. Signature du certificat du serveur par l'autorité de certification ldap CA openssl ca -in tempservercert.pem -cert certs/ldapca.pem -keyfile private/ldapca.key -notext -out certs/serveur.pem -notext -config ca-server-cert.cnf On notera ici qu'il faut préciser quelle CA doit servir à signer le certificat. D'où la présence des deux arguments supplémentaire -cert et -keyfile. La signature exigera de donner la passphrase du certificat LDAP CA. Ne pas oublier de créer un fichier hash.0 selon la méthode habituelle (déjà vue!!). III. Test local des certificats par openssl Openssl permet bien évidemment de vérifier la validité d un certificat. La commande est : ou bien : openssl verify certs/serveur.pem openssl verify -CApath certs certs/serveur.pem Ceci permet de vérifier la chaîne de certification du certificat du serveur. La deuxième version de la commande permet d'aider openssl à trouver où sont situés les fichiers de la forme hash.0. Pour plus de détails sur la vérification, tapez la commande : openssl verify -help Il est important de noter que la verification ne peut être faite que si on dispose des informations nécessaires pour vérifier toute la chaine de certification, jusqu au certificat de l autorité racine!! Le principe étant de disposer de l ensemble des certificats des CA dans un même dossier avec un jeu de liens symboliques pour permettre un accès rapide à ceux-ci. C est pour cette raison que nous avions (voir plus haut) utiliser des liens symboliques avec les «hash value» du type <haxh value>.0. - le mieux consiste à tester réellement les certificats. Autrement dit, dans notre cas, en faisant fonctionner un serveur LDAP au dessus de TLS (voir section VII). - Quand vous vouler utiliser un certificat, ne manquez pas de le regarder en détail avenc la commande Openssl x509 in ficheircertificat.pem/.cer/.der -noout -text Par ailleurs, la procédure de création des certificats utilisateurs se fait de la même manière que pour les certificats serveurs. IV. Formats et packaging des certificats et clés IV.1. Format de diffusion des certificats Les certificats des CA doivent être incorporés dans les browsers (pour vérifier les certificats serveurs) et dans les serveurs (pour vérifier les certificats utilisateurs). Le format usuel, permet une importation aisée de ces certificats X509 est le format «pem», utilisé de manière standard par openssl. L extension qui plait bien à windows est «.crt». Remarque :openssl est susceptible d ajouter une description texte dans les output si on ne fait pas attention (i.e., si on met une option text en trop). Les serveurs apache utiliseront le même système qu openssl pour la vérification des chaînes de certifications, à savoir un repertoire contenant les certificats de CA, indexés via une fonction de hachage. IV.2 Packaging des couples (certificat + clés privée) L archivage/importation se fait via un le format d archive pkcs12, que l on peut construire de la manière suivante : Openssl pkcs12 inkey Madamemichou.key in Madamemichou.crt export > Madamemichou.p12 En fait, le format pkcs12 (norme adoptée par Netscape et Microsoft IE) est un codage binaire incluant un certificat, sa clé privée associée et optionnellement d autres certificats. C est pour ça qu il est également appelé «une enveloppe pkcs12». Cette enveloppe peut être chiffreé à l aide d une passphrase. Ce format est utilisé par les infrastructures de gestion de clés (IGC ou PKI en angalis) pour distribuer les certificats et les clés privées à leurs clients. L extension utilisée est.p12 ou.pfx. - l extension «p12» est reconnue par windows!! - une structure pkcs12 peut également intégrer la chaîne de certification, laquelle sera intégrée avec un succès variable par les browsers. V. Configuration de ApacheSSL Voir VI. Signature et chiffrement de mails On suppose que vous disposez d une paire de clés publique/privée, et d un certificat qui les accompagne et qui atteste de votre adresse électronique. VI.1. Signature/vérification signature mails Vous disposer d un certificat moncert.pem, d une clé privée maclé.pem et vous voulez envoyer le mail contenu dans blabla.txt à haha@xx.fr. On suppose que tous les fichiers sont dans le repertoire courant : Openssl smime sign in blabla.txt text signer moncert.pem inkey macle.pem from moi@ensi-bourges.fr -to haha@xx.fr -subject "mail signé" mail haha@xx.fr Pour vérifier, il faut disposer du certificat utilisé pour la signature : Openssl smime verify in mail.signe signer soncert.pem VI.1chiffrement/déchiffrement mails Pour envoyer un mail chiffré, avec RC2 40 bits par exemple, à un destinataire dont on dispose d un certificat soncert.pem : Openssl smime encrypt in blabla.txt text from moi@ensibourges.fr -to haha@xx.fr -subject "mail chiffré" rc2-40 soncert.pem mail haha@xx.fr Pour déchiffrer Openssl smime decrypt in mail.msg recip moncert.pem inkey macle.pem. Remarque : on peut remplacer rc2-40 par des3 par exemple, mais tous les logiciels de mail ne permettent pas des chiffrements forts.

3 VII. Tests LDAP IV.1. Configuration du fichier slapd.conf Trois clauses sont nécessaires pour un bon fonctionnement du serveur. Voici un exemple : TLSCACertificatePath /Users/eleve/einstein/ssl/certs TLSCertificateFile /Users/eleve/einstein/ssl/certs/serveur.pem TLSCertificateKeyFile /Users/eleve/einstein/ssl/private/serveur.key La première clause (TLSCACertificatePath) permet de spécifier où sont situés les différents certificats, et en particulier les certificats des CA. Nécessaire si le serveur doit valider le certificat du client. Les deux autres clauses (TLSCertificate et TLSCertificateKeyFile) permettent de spécifier le certificat du serveur et sa clé privée. Une fois le fichier de configuration du serveur mis à jour, il convient de lancer correctement le serveur. Celui-ci doit pouvoir accepter aussi bien des demandes de connexions non sécurisées que mettant en oeuvre la couche TLS. Ceci signifie que le serveur doit écouter 2 ports différents. Un port supportera les connexions normales, et l'autre les connexions de type TLS. La commande slapd permet ceci. Par exemple : TLS_KEY /Users/estelle3/tpe10/einstein/ssl/certs/albert-einstein.key Lorsque vous lancerez une commande ldapsearch, la passphrase du certificat client sera alors demandée, si celle-ci existe bien entendu. IV.3. Tests Un certain nombre de tests sont envisageables. Nous vous donnons simplement une liste de ceux-ci. Nous vous laissons trouver comme des grands le moyen de les mettre en oeuvre. Test du serveur par un client openssl Test du serveur par ldapsearch Test du serveur par ldapbrowser slapd -d 5 -h "ldap://:9009/ ldaps://:9008" -f slapd.conf Cette commande ordonne au serveur d'écouter les connexions normales sur le port 9009 et les connexions TLS sur le port Le paramètre d 5 permet au serveur d'afficher ce qu'il fait, ce qui est très utile lors des tests. Notons que lors du démarrage du serveur, il vous demande la passphrase du certificat serveur. IV.2. Configuration du client ldapsearch Le client ldapsearch doit pouvoir accéder aux certificats de CA pour être en mesure de valider le certificat du serveur. Ceci se fait grâce à un fichier (ldaprc) dans lequel 2 clauses sont importantes : TLS_CACERT /Users/eleve/einstein/ssl/ca.pem TLS_CACERTDIR /Users/eleve/einstein/ssl/certs La première clause indique quel est le fichier contenant le root CA. La deuxième clause donne le répertoire où sont stockés les différents certificats nécessaires à la validation. La première clause n'est pas fondamentalement nécessaire si dans le répertoire des certificats existe un lien symbolique vers le certificat du root CA. Deux autres clauses sont envisageables : TLS_CERT et TLS_KEY Elles permettent de spécifier le nom d'un fichier contenant un certificat client et la clé privée associée. Exemple : TLS_CERT /Users/estelle3/tpe10/einstein/ssl/certs/albert-einstein.pem Annexes Fichier root-ca-cert.cnf # pour generer un certificat root CA default_keyfile = private/ca.key = rootca_cert default_keyfile = private/subca.key = subca_req _default _min = 2 _max = 2 _default _min = 2 _max = 2 _default _default _default _default = ENSIB _default _default = ENSIB _default = ENSIB MRI Root CA _max = 64 _max = 64 [ rootca_cert ] # section ci-dessous decrit extensions a inclure dans un certificat rootca authoritykeyidentifier= keyid:always,issuer:always = sslca, ca, objca = "Certificat Racine. Genere par OpenSSL" Fichier req-subca-cert.cnf # pour generer une requete de certificat CA intermediaire _default = ENSIB MRI LDAP CA _max = 64 _max = 64 [ subca_req ] authoritykeyidentifier= keyid, issuer:always # = sslca, ca, objca # = "Requete de signature de certificat" Fichier req-server-cert.cnf # pour generer une requete de certificat serveur default_keyfile = private/server.key

4 = server_req _min = 2 _max = 2 _default _min = 2 _max = 2 _default _default _default = ENSIB _max = 64 _max = 64 (ex: nom de la root CA) _max = 64 _max = 64 [ user_req ] extendedkeyusage = clientauth, protection = client, # = "Requete de signature de certificat" [ server_req ] subjectaltname =issuer:copy = digitalsignature, keyencipherment extendedkeyusage = serverauth, clientauth = server # = "Requete de signature de certificat" #nscarevocationurl = nsrevocationurl= ldap://mesange.ensi-bourges.fr:9009/ou=pki,o=ensib,c=fr? certificaterevocationlist?sub?(cn=crl) Fichier req-user-cert.cnf # poour generer une requete de certificat utilisateur Fichier ca-subca-cert.cnf # pour signer un certificat CA intermediaire default_keyfile = private/user.key = user_req dir = /usr/local/ssl # Where everything is default_days = 4383 # how long to certify for # which md to use. = subca_cert = _match default_days = 730 # how long to certify for # which md to use. = server_cert = _anything [ server_cert ] [ subca_cert ] authoritykeyidentifier = keyid:always, issuer:always # = sslca, ca, objca = "Genere par OpenSSL" authoritykeyidentifier = keyid:always extendedkeyusage = serverauth, clientauth = server, objsign = "Certificat serveur genere par OpenSSL pour ENSIB/MRI" [ _match ] = match organizationalunitname #subjectaltname #nscarevocationurl #nsrevocationurl = issuer:copy = Fichier ca-server-cert.cnf # pour signer un certificat serveur dir = /usr/local/ssl # Where everything is [ _anything ] organizationalunitname

5 ca-user-cert.cnf # pour signer un certificat utilsateur dir = /usr/local/ssl # Where everything is [ _anything ] organizationalunitname Exercice : «RSA» Un assistant envoie votre note au professeur concerné par mail chiffré avec RSA. La clé publique (e,n) du professeur est (7, 55) et le message envoyé (chiffré) est 25. Quelle est votre note? default_days = 365 # how long to certify for # which md to use. = user_cert = _anything [ user_cert ] authoritykeyidentifier = keyid:always extendedkeyusage = clientauth, protection = client, , objsign = "Certificat utilisateur genere par OpenSSL pour ENSIB/MRI" subjectaltname = issuer:copy #nscarevocationurl = nsrevocationurl= ldap://mesange.ensi-bourges.fr:9009/ou=pki,o=ensib,c=fr? certificaterevocationlist?sub?(cn=crl)