|
Taille: 4437
Commentaire:
|
Taille: 4285
Commentaire: Refonte totale de la page
|
| 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://www.crans.org, https://wiki.crans.org, certificat de la base LDAP,...). 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é. |
| Ligne 8: | Ligne 8: |
| == Le Certificat d'Autorité == === Génération de la paire de clés === |
== Génération du certificat d'Autorité == |
| Ligne 13: | Ligne 11: |
| Pour commencer, on génère une paire de clés publique/privé auto-signée qui sera attribuée au Certificat d'Autorité: | |
| Ligne 15: | Ligne 12: |
| {{{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 (notmement la durée du CA et 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 18: |
| 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 20: |
| === Génération du certificat à diffuser === 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'' |
| Ligne 32: | Ligne 24: |
| === Pour un serveur web sécurisé === | === Création d'un certificat === |
| Ligne 34: | Ligne 26: |
| 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 33: |
| 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 35: |
| 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. ==== 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 à signé 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/slapd.conf'' : {{{ TLS_CACERT <le CA public (cacert.pem)> |
| Ligne 43: | Ligne 72: |
| Puis on crée le certificat associé : {{{openssl x509 -in /etc/ssl/certificats/egon_cert.pem -out /etc/ssl/certificats/egon_cert.crt }}} 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>}}} |
|
| Ligne 71: | Ligne 78: |
| * Les durées de validité, possibilités de prolonger un certificat |
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://www.crans.org, https://wiki.crans.org, certificat de la base LDAP,...). 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é.
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 (notmement la durée du CA et 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.
Le certificat à distribuer sera demoCA/cacert.pem
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.
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 à signé 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/slapd.conf :
TLS_CACERT <le CA public (cacert.pem)>
Pour le wifi
À lire pour commencer : http://www.tldp.org/HOWTO/SSL-Certificates-HOWTO/x341.html
À voir
- Comment on fait connaître le CA autrement que par une page web indiquant de le télécharger ?
- Utilisation pour IMAP ??
- Les durées de validité, possibilités de prolonger un certificat