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://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.

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 ?
  • Non ; lui donner l'extension .crt pour que le navigateur propose automatiquement l'installation, on enverra le lien par mail.
• Utilisation pour IMAP ??
• Les durées de validité, possibilités de prolonger un certificat

Quels services ont besoin de certificats ?

Il faut générer des certificats pour:

• Mail
  • IMAP
  • POP
  • SMTP
• News
• Apache
  • wiki
  • mailman
  • www.crans.org
  • perso.crans.org

Liens

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