|
Taille: 4324
Commentaire:
|
Taille: 5830
Commentaire:
|
| Texte supprimé. | Texte ajouté. |
| Ligne 1: | Ligne 1: |
| = Gérer les certificats d'authentification SSL du CRANS = | [[TableOfContents]] |
| Ligne 6: | Ligne 6: |
| Dans le cadre du crans, il nous faut définir un grand nombre de certificats de sécurités (https://www.crans.org, https://wiki.crans.org, ...). Afin d'éviter à l'utilisateur lambda de devoir trop souvent accepter les certificats présentés par les différents services, on définit un Certificat d'Autorité (CA) qui, une fois connu du navigateur, acceptera automatiquement les certificats SSL présentés signés par la clé privée associée à ce Certificat d'Autorité. | Dans le cadre du crans, il nous faut définir un grand nombre de certificats de sécurités (https, mail, certificat de la base LDAP,...). Pour simplifier la gestion et l'utilisation on créé tout d'abord un Certificat d'Autorité (CA) qui servira à signer tous les certificats générés. La connaissance du CA nous permet alors de faire confiance au certificat présenté. Cela est indispensable pour des aplliquation telles que le LDAP. |
| Ligne 8: | Ligne 8: |
| == Le Certificat d'Autorité == | De plus pour les utilisateurs lambda (une fois le CA accepté) cela leur permet de plus avoir de warnings lors de l'utilisation des services de crans demandant du SSL. |
| Ligne 10: | Ligne 10: |
| === Génération de la paire de clés === | == Génération du certificat d'Autorité == |
| Ligne 13: | Ligne 13: |
| Pour commencer, on génère une paire de clés publique/privé qui sera attribuée au Certificat d'Autorité: | |
| Ligne 15: | Ligne 14: |
| {{{openssl req -config /etc/ssl/openssl.cnf -new -x509 -keyout /etc/ssl/certificats/private/cakey.pem -out /etc/ssl/certificats/cacert.pem -days 1095 -nodes | Préliminairement éditer /etc/openssl.cnf pour mettre les options souhaitées (les valeur par défaut des certificats). Ensuite la génération du CA se fait très simplement grace au script CA.pl : {{{ CA.pl -newca |
| Ligne 18: | Ligne 20: |
| Dans ce cas, on crée deux fichiers nommés cakey.pem (qui contient la clé privée) et cacert.pem (qui contient la clé publique) qui seront valables pour une durée de 1095 jours (~3 ans).[[BR]] /!\ L'option -nodes désactive la saisie d'une passphrase pour l'utilisation du certificat. |
La commande permet de générer le CA ainsi qu'un répertoire demoCA dans lequel on trouvera toute une arboressence destinée à nous simplier la vie pour la gestion des certificats associés au CA généré. Le mot de passe est necessaire car il garanti l'inutilisabilité en cas de vol de la clef privée. |
| Ligne 21: | Ligne 22: |
| === Génération du certificat à diffuser === | La durée de validité par défaut est de 365 jours. Pour le CA actuel cette durée est augnetée à 20 ans (modification du script CA.pl à la ligne 40 : $DAYS="-days xxxx";) |
| Ligne 23: | Ligne 24: |
| Afin d'être reconnu par les navigateurs, il faut leur faire connaître notre clé publique associée au Certificat d'Autorité à travers un certificat à télécharger. On génère le certificat adéquat de la manière suivante : {{{openssl x509 -in /etc/ssl/certificats/cacert.pem -out /var/www/crans-certificat.crt }}} Où /var/www/crans-certificat.crt est le certificat à intégrer dans les navigateurs pour reconnaître l'Autorité CRANS en manière de signature de certificats SSL. |
Le certificat à distribuer sera ''demoCA/cacert.pem''. Il sera placé sur chaque serveur, il est de plus disponible sur http://www.crans.org/cert_crans.crt |
| Ligne 32: | Ligne 28: |
| === Pour un serveur web sécurisé === | === Création d'un certificat === |
| Ligne 34: | Ligne 30: |
| On procède de la même manière, en commençant par créer une paire de clés (/!\ rassemblées dans le même fichier) associée à un service (exemple de egon) : {{{openssl req -config /etc/ssl/openssl.cnf -new -keyout /etc/ssl/certificats/egon.pem -out /etc/ssl/certificats/egon.pem -days 365 -nodes |
Elle se fait en deux temps : ==== Etape 1 : génération d'une demande de certificat ==== On génère une demande de certificat avec la commande : {{{ CA.pl -newreq-nodes |
| Ligne 37: | Ligne 37: |
| Au moment de définir le Common Name associé à cette paire de clés, il faut penser à spécifier la bonne valeur. À savoir le nom du serveur web, dans notre cas : {{{egon.crans.org}}}. (le fichier openssl.cnf contient une valeur par défaut {{{www.crans.org}}} qui est utilisée pour définir le Certificat d'Autorité ) | Celle-ci génère le fichier ''newreq.pem'' (celui-ci comporte deux parties : la clef privée du certificat et la demande de certificat proprement dite) |
| Ligne 39: | Ligne 39: |
| Afin que ce certificat soit reconnu est accepté par le Certificat d'Autorité précédemment créé, on signe cette paire de clés avec la clé privée associée au Certificat d'Autorité : {{{openssl ca -config /etc/ssl/openssl.cnf -policy policy_anything -out /etc/ssl/certificats/egon_cert.pem -infiles /etc/ssl/certificats/egon.pem |
{i} Note : le certificat créé ne sera pas protégé par mot de passe, enlever le ''-nodes'' si on veut un certificat avec mot de passe. /!\ '''TRES IMPORTANT''' : Le Common Name associé à cette paire de clés doit être le nom complet du serveur ou du virtual host (www.crans.org par exemple) ou a défaut son IP. {i} Certains services peuvent avoir plusieurs noms associés à une même IP (virtualhost dans apache par exemple), pour ceux ci il faut générer un certificat avec un cn égal à la regexp qui va bien. Ce certificat devra également contenir un champ subjectAltName avec les enregistrements DNS correspondants. Exemple pour www.crans.org et perso.crans.org : cn = (www|perso).crans.org et il faut ajouter dans openssl.cnf les lignes suivantes : {{{ subjectAltName = @ALIASES [ALIASES] DNS.1 = www.crans.org DNS.2 = perso.crans.org |
| Ligne 43: | Ligne 55: |
| Puis on crée le certificat associé : {{{openssl x509 -in /etc/ssl/certificats/egon_cert.pem -out /etc/ssl/certificats/egon_cert.crt |
==== Etape 2 : signature du certificat ==== Pour que le certificat soit reconnu par un client possédant le CA il est necessaire de le signer à l'aide du CA : {{{ CA.pl -sign }}} Le certificat à signer est celui de ''newreq.pem'' et le certificat signé sera alors dans ''newcert.pem'' Il sera proposé de commiter ce certificat à dans la base. En cas d'acceptation le certificat signé sera également stoqué dans ''demoCA/newcerts/xx.pem'' xx étant le numéro du certificat. Le commit permet ainsi de ranger nos certificats au même endroit. === Utilisation du certificat === /!\ Dans tous les cas les clefs privées ne doivent '''jamais''' être lisible par tous, penser à donner les bon droits lors de la configuration. ==== Apache ==== Ajouter les directives de configuration suivantes à ''httpd.conf'' : {{{SSLCACertificateFile <le CA public (cacert.pem)> SSLCertificateFile <le certificat (newcert.pem) SSLCertificateKeyFile <clef privée du certificat (newreq.pem)>}}} ==== LDAP ==== Il faut mettre les directives de configuration suivantes dans ''/etc/ldap/slapd.conf'' {{{TLSCertificateFile <le certificat (newcert.pem)> TLSCertificateKeyFile <clef privée du certificat (newreq.pem)> TLSCACertificateFile <le CA public (cacert.pem)>}}} Sur le client il faut mettre dans ''/etc/ldap/lapd.conf'' : {{{ TLS_CACERT <le CA public (cacert.pem)> |
| Ligne 47: | Ligne 87: |
| Reste à modifier le httpd.conf de apache-ssl de la manière suivante : {{{<VirtualHost 138.231.136.7:443> Port 443 SSLEnable DocumentRoot /var/www ServerName egon.crans.org SSLCertificateFile /etc/ssl/certificats/egon_cert.crt SSLCertificateKeyFile /etc/ssl/certificats/egon.pem SSLCacheServerPath /usr/lib/apache-ssl/gcache SSLCacheServerPort /var/run/gcache_port SSLSessionCacheTimeout 60 SSLVerifyClient 0 SSLVerifyDepth 10 SSLFakeBasicAuth </VirtualHost>}}} === Pour le wifi === |
==== Pour le wifi ==== |
| Ligne 68: | Ligne 90: |
| == À voir == * Utilisation pour IMAP ?? |
== Certificats présents sur les machines du crans == Pour toutes nos machines les certificats sont rangés dans ''/etc/ssl''. Le répertoire ''certs'' contient le certificat proprement dit et le répertoire ''private'' les clefs. Le fichier du certificat et celui de sa clef ont le même nom. Le CA (clef publique) est stoquée dans ''/etc/ssl/certs/CAcrans.pem'', la partie privée est stoquée sur vert dans ''/etc/ssl/demoCA''. (!) Commande utile pour avoir les propriétés d'un certificat : {{{ openssl x509 -text -in <le certificat> }}} |
| Ligne 73: | Ligne 105: |
| * http://www.hsc.fr/ressources/breves/ssl_virtualhosts.html.fr ---- ["CatégorieCrans/PageNonTerminée"] : on exécute les commandes sur quel serveur ? lesquelles doivent être exécutées en root ? où se trouve le mot de passe du certificat d'autorité ? -- WikiSgnb |
Afin de s'assurer la sécurité d'une communication sécurités, l'un ou l'autre des participants doivent pouvoir communiquer avec l'autre de façon sécurisée (cryptée).BR Le principe d'une connexion SSL repose sur la communication avec un système de paires de clés publique/privé FootNote(Voir aussi WikiInformatique/ClésPgp).BR
Dans le cadre du crans, il nous faut définir un grand nombre de certificats de sécurités (https, mail, certificat de la base LDAP,...). Pour simplifier la gestion et l'utilisation on créé tout d'abord un Certificat d'Autorité (CA) qui servira à signer tous les certificats générés. La connaissance du CA nous permet alors de faire confiance au certificat présenté. Cela est indispensable pour des aplliquation telles que le LDAP.
De plus pour les utilisateurs lambda (une fois le CA accepté) cela leur permet de plus avoir de warnings lors de l'utilisation des services de crans demandant du SSL.
Génération du certificat d'Autorité
La paire de clés associées à ce certificat particulier est utilisé pour certifier tous les autres certificats que les services du crans sont amenés à générer.BR
Préliminairement éditer /etc/openssl.cnf pour mettre les options souhaitées (les valeur par défaut des certificats). Ensuite la génération du CA se fait très simplement grace au script CA.pl :
CA.pl -newca
La commande permet de générer le CA ainsi qu'un répertoire demoCA dans lequel on trouvera toute une arboressence destinée à nous simplier la vie pour la gestion des certificats associés au CA généré. Le mot de passe est necessaire car il garanti l'inutilisabilité en cas de vol de la clef privée.
La durée de validité par défaut est de 365 jours. Pour le CA actuel cette durée est augnetée à 20 ans (modification du script CA.pl à la ligne 40 : $DAYS="-days xxxx";)
Le certificat à distribuer sera demoCA/cacert.pem. Il sera placé sur chaque serveur, il est de plus disponible sur http://www.crans.org/cert_crans.crt
Certificats de sécurité SSL
Création d'un certificat
Elle se fait en deux temps :
Etape 1 : génération d'une demande de certificat
On génère une demande de certificat avec la commande :
CA.pl -newreq-nodes
Celle-ci génère le fichier newreq.pem (celui-ci comporte deux parties : la clef privée du certificat et la demande de certificat proprement dite)
Note : le certificat créé ne sera pas protégé par mot de passe, enlever le -nodes si on veut un certificat avec mot de passe.
![/!\](/wiki/memodump/img/alert.png "/!\"){kind=small}
TRES IMPORTANT : Le Common Name associé à cette paire de clés doit être le nom complet du serveur ou du virtual host (www.crans.org par exemple) ou a défaut son IP.
Certains services peuvent avoir plusieurs noms associés à une même IP (virtualhost dans apache par exemple), pour ceux ci il faut générer un certificat avec un cn égal à la regexp qui va bien. Ce certificat devra également contenir un champ subjectAltName avec les enregistrements DNS correspondants.
Exemple pour www.crans.org et perso.crans.org : cn = (www|perso).crans.org et il faut ajouter dans openssl.cnf les lignes suivantes :
subjectAltName = @ALIASES [ALIASES] DNS.1 = www.crans.org DNS.2 = perso.crans.org
Etape 2 : signature du certificat
Pour que le certificat soit reconnu par un client possédant le CA il est necessaire de le signer à l'aide du CA :
CA.pl -sign
Le certificat à signer est celui de newreq.pem et le certificat signé sera alors dans newcert.pem Il sera proposé de commiter ce certificat à dans la base. En cas d'acceptation le certificat signé sera également stoqué dans demoCA/newcerts/xx.pem xx étant le numéro du certificat. Le commit permet ainsi de ranger nos certificats au même endroit.
Utilisation du certificat
Dans tous les cas les clefs privées ne doivent jamais être lisible par tous, penser à donner les bon droits lors de la configuration.
Apache
Ajouter les directives de configuration suivantes à httpd.conf : {{{SSLCACertificateFile <le CA public (cacert.pem)> SSLCertificateFile <le certificat (newcert.pem) SSLCertificateKeyFile <clef privée du certificat (newreq.pem)>}}}
LDAP
Il faut mettre les directives de configuration suivantes dans /etc/ldap/slapd.conf {{{TLSCertificateFile <le certificat (newcert.pem)> TLSCertificateKeyFile <clef privée du certificat (newreq.pem)> TLSCACertificateFile <le CA public (cacert.pem)>}}}
Sur le client il faut mettre dans /etc/ldap/lapd.conf :
TLS_CACERT <le CA public (cacert.pem)>
Pour le wifi
À lire pour commencer : http://www.tldp.org/HOWTO/SSL-Certificates-HOWTO/x341.html
Certificats présents sur les machines du crans
Pour toutes nos machines les certificats sont rangés dans /etc/ssl.
Le répertoire certs contient le certificat proprement dit et le répertoire private les clefs. Le fichier du certificat et celui de sa clef ont le même nom.
Le CA (clef publique) est stoquée dans /etc/ssl/certs/CAcrans.pem, la partie privée est stoquée sur vert dans /etc/ssl/demoCA.
Commande utile pour avoir les propriétés d'un certificat :
openssl x509 -text -in <le certificat>
Liens
["CatégorieCrans/PageNonTerminée"] : on exécute les commandes sur quel serveur ? lesquelles doivent être exécutées en root ? où se trouve le mot de passe du certificat d'autorité ? -- WikiSgnb