Sommaire
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.
![/!\](/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 à 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.pemOn 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
CatégoriePagePérimée : à mettre à jour avec les certificats CAcert