TableOfContents

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.

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 à 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

• Utilisation pour IMAP ??
• Les durées de validité, possibilités de prolonger un certificat

Certificats présents sur les machines du crans

Pour toutes nos machines les certificats sont rangés dans /etc/ssl.

Le CA (clef publique) est stoquée dans /etc/ssl/certs/CAcrans.pem, la partie privée est stoquée sur sila dans /etc/ssl/demoCA.

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.

Les certificats générés (ou encore à générer) sont :

• Apache (apache-zamok.pem)

• slapd (zamok.pem, sila.pem)

• Dovecot
• Posfix
• Inn

Commande utile pour avoir les propriétés d'un certificat :

openssl x509 -text -in <le certificat>

Liens

• http://www.tldp.org/HOWTO/SSL-Certificates-HOWTO/

• http://www.hsc.fr/ressources/breves/ssl_virtualhosts.html.fr