Afin d'assurer la sécurité d'une communication, les participants doivent pouvoir communiquer de façon sécurisée (chiffrée).

Le principe d'une connexion SSL repose sur la communication avec un système de paires de clés publique/privé.

Dans le cadre du crans, il nous faut définir un grand nombre de certificats de sécurités (https, mail, 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é s'il a été signé par le CA.

Cela est indispensable pour des applications telles que LDAP.

De plus pour les utilisateurs lambda, une fois le CA accepté, cela leur permet de ne plus avoir de warnings lors de l'utilisation des services du crans demandant du SSL.

Génération du certificat d'Autorité

La paire de clés associée à ce certificat particulier est utilisé pour certifier tous les autres certificats que les services du crans peuvent nécessiter.

On commence par créer une architecture de dossier : {{{export CA=/etc/ssl/CA_crans mkdir $CA $CA/certs $CA/crl $CA/newcerts $CA/private touch $CA/index.txt }}}

Puis on demande à openssl de générer le certificat : {{{openssl req -config openssl.cnf -new -x509 -keyout $CA/private/cakey.pem -out $CA/cacert.pem -days 7300 }}}

On entre alors comme information :

• Country Name (2 letter code) [AU]:FR
• State or Province Name (full name) [Some-State]:France
• Locality Name (eg, city) []:Cachan
• Organization Name (eg, company) [Internet Widgits Pty Ltd]:CRANS
• Organizational Unit Name (eg, section) []:
• Common Name (eg, YOUR name) []:Association Cachan Reseaux @ Normale Sup

• Email Address []:roots@crans.org

Notre CA a une durée de validité de 20 ans. On évite ainsi d'avoir à recopier la clé publique sur tous les serveurs chaque année, et à obliger les adhérents à le mettre à jour à chaque fois.

On peut aussi générer le CA avec un fichier de configuration tel que demande-ca.cnf

Le certificat à distribuer sera $CA/cacert.pem. Il sera placé sur chaque serveur, il est de plus disponible sur http://www.crans.org/cert_crans.crt

Un CA est un certificat SSL auto-signé, cela est spécifié par l'option -x509

Création d'une demande de certificats de sécurité SSL

openssl

C'est la méthode utilisée pour apache, les fichiers *.cnf se trouvent sur vert dans le dossier /etc/ssl/confs.

Une fois qu'on a écrit le fichier de configuration confs/pegase.cnf, on demande à openssl de créer une demande de certificat :

cd /etc/ssl
openssl req -config confs/pegase.cnf -new -nodes -keyout pegase.key -out pegase.req

Le premier fichier contient la clé privée du certificat, le deuxième correspond à la demande de certificat.

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 à 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 service.cnf les lignes suivantes :

subjectAltName                  = @ALIASES
[ALIASES]
DNS.1 = www.crans.org
DNS.2 = perso.crans.org

JetDirect (l'imprimante)

Sur l'interface Web de l'imprimante, aller dans : Réseau / Autorisation / Certificats / Configurer / Créer la demande de certificat

Rentrer les paramètres suivants :

• nom commun : (138.231.144.17|laserjet.adm.crans.org)
• organisation : CRANS
• Unité d'organisation :
• Ville / localité : Cachan
• Département : France
• Pays : FR

Télécharger la demande de certificat, et copiez la sur vert dans /etc/ssl/laserjet.req

Signature d'une demande de certificat

Il faut tout d'abord écrire un petit fichier contenant l'emplacement des certificats du CA, les dossiers de dépot du CA...

Il s'agit sur vert de : /etc/ssl/CA_crans/openssl.cnf

### Configuration du CA pour les signatures

HOME                    = /etc/ssl
RANDFILE                = $ENV::HOME/.rnd

####################################################################
[ ca ]
default_ca      = CA_crans

####################################################################
# Les paramètres du CA
[ CA_crans ]

dir             = /etc/ssl/CA_crans     # Where everything is kept
certs           = $dir/certs            # Where the issued certs are kept
crl_dir         = $dir/crl              # Where the issued crl are kept
database        = $dir/index.txt        # database index file.
#unique_subject = no                    # Set to 'no' to allow creation of
                                        # several ctificates with same subject.
new_certs_dir   = $dir/newcerts         # default place for new certs.
certificate     = $dir/cacert.pem       # The CA certificate
serial          = $dir/serial           # The current serial number
#crlnumber      = $dir/crlnumber        # the current crl number
                                        # must be commented out to leave a V1 CRL
crl             = $dir/crl/crl.pem      # The current CRL
private_key     = $dir/private/cakey.pem# The private key
RANDFILE        = $dir/private/.rand    # private random number file

x509_extensions = extensions            # The extentions to add to the cert

# Comment out the following two lines for the "traditional"
# (and highly broken) format.
name_opt        = ca_default            # Subject Name options
cert_opt        = ca_default            # Certificate field options

# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs
# so this is commented out by default to leave a V1 CRL.
# crlnumber must also be commented out to leave a V1 CRL.
# crl_extensions        = crl_ext

default_days    = 365                   # how long to certify for
default_crl_days= 30                    # how long before next CRL
default_md      = md5                   # which md to use.
preserve        = no                    # keep passed DN ordering

policy          = policy

####################################################################
# Contraintes pour permettre la signature
[ policy ]
countryName             = match
stateOrProvinceName     = match
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

####################################################################
# Extensions à ajouter
[ extensions ]
basicConstraints=CA:FALSE

# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid,issuer:always

nsCaRevocationUrl       = http://www.crans.org/ca-crl.pem

On tappe ensuite la commande :

openssl ca -config /etc/ssl/CA_crans/openssl.cnf -in pegase.req -out pegase.pem

Le certificat à signer est celui de pegase.req et le certificat signé sera alors dans pegase.pem

Dans le cas de certificats pour apache avec des virtual hosts, il ne faut pas prendre les extensions par défaut du CA (du fichier /etc/ssl/CA_crans/openssl.cnf) mais il faut prendre les extensions du fichier cnf du service (qui inclut la directive subjectAltName)

openssl ca -config /etc/ssl/CA_crans/openssl.cnf -extfile confs/apache-rouge.cnf -extensions extentions  -in apache-rouge.req -out apache-rouge.pem

Il sera proposé de commiter ce certificat à dans la base. En cas d'acceptation le certificat signé sera également stoqué dans /etc/ssl/CA_crans/newcerts/xx.pem xx étant le numéro du certificat. Le commit permet ainsi de ranger nos certificats au même endroit.

Une fois le certificat signé, on copie les fichiers où il faut :

cd /etc/ssl
mv pegase.pem certs/pegase.pem
mv pegase.key private/pegase.pem
rm pegase.req

Utilisation des certificats

Dans tous les cas les clefs privées ne doivent jamais être lisible par tous, penser à donner les bon droits lors de la configuration.

JetDirect (l'imprimante)

Il faut tout d'abord convertir le certificat dans le format PKCS#12 avec la commande :

openssl pkcs12 -export -in laserjet_server.pem -inkey laserjet_privatekey.pem -out laserjet.pfx

Choisir un mot de passe non vide. Après cette formalité, on peut aller dans Réseau / Autorisation / Certificats / Configurer / Importer le certificat et la clé privée et installer le fichier .pfx en donnant le même mot de passe.

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

Cette section est peut être obsolète

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>

Résumé/outils pour le crans

Sur vert, dans /etc/ssl, il y a un Makefile qui prend le fichier de conf dans /etc/ssl/confs, génère une demande de certificat et la signe (il faut néanmoins le secret du CA).

Exemple :

cd /etc/ssl
sudo make apache-rouge

Ce Makefile copie aussi les certificats utiles dans cfengine. Pour les services configurés, il suffit donc de lancer un cfrun pour qu'ils prennent en compte les nouveaux certificats.

Exemple :

sudo cfrun rouge

Liens

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

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

• CatégoriePagePublique

• CatégoriePagePérimée : à mettre à jour avec les certificats CAcert