|
Taille: 4324
Commentaire:
|
Taille: 9671
Commentaire:
|
| Texte supprimé. | Texte ajouté. |
| Ligne 1: | Ligne 1: |
| = Gérer les certificats d'authentification SSL du CRANS = 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]] |
[[TableOfContents]] Afin de s'assurer la sécurité d'une communication sécurités, les participants d'une communication doivent pouvoir communiquer de façon sécurisée (chiffrée).[[BR]] |
| Ligne 6: | Ligne 7: |
| 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é. == Le Certificat d'Autorité == === Génération de la paire de clés === |
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é pas le CA. {i} 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é = |
| Ligne 13: | Ligne 17: |
| Pour commencer, on génère une paire de clés publique/privé qui sera attribuée au Certificat d'Autorité: {{{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 }}} 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. === 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. == Certificats de sécurité SSL == === Pour un serveur web sécurisé === 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 }}} 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é ) 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 }}} 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>}}} === Pour le wifi === * À lire pour commencer : http://www.tldp.org/HOWTO/SSL-Certificates-HOWTO/x341.html == À voir == * Utilisation pour IMAP ?? == Liens == |
On commence par creer une architecture de dossier : {{{ export $CA=/etc/ssl/CA_crans mkdir $CA $CA/certs $CA/crl $CA/newcerts $CA/private touch $CA/index.txt }}} On écrit le fichier de configuration /etc/ssl/CA_crans/openssl.cnf : {{{ ### Configuration du CA pour les signatures HOME = /etc/ssl RANDFILE = $ENV::HOME/.rnd #################################################################### [ ca ] default_ca = CA_crans #################################################################### [ 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 }}} Puis on demande à openssl de générer une paire de clés : {{{ openssl req -new -x509 -keyout $CA/private/cakey.pem -out $CA/cacert.pem -days 7300 }}} {i} 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érent à la mettre à jou à chaque fois. 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] = Création d'une demande de certificats de sécurité SSL = == openssl == C'était la methode utilisée avant, les fichiers *.cnf se trouvent sur vert dans le dossier /etc/ssl/oldconfs Une fois qu'on a écrit les fichier de configuration service.cnf, on demande à openssl de créer une demande de certificat : {{{ openssl req -config service.cnf -new -nodes -keyout service.key -out service.req }}} Le premier fichier corespond à la clé privée pour du certificat, le deuxième corespond à le demande de certificat. {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. {i} 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 }}} == 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 == Apache == = Signature d'une demande de certificat = openssl ca -config /etc/ssl/CA_crans/openssl.cnf -out service.pem -in service.req Le certificat à signer est celui de ''service.req'' et le certificat signé sera alors dans ''service.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. = 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. == JedDirect (l'imprimante) == La première étape à faire est de mettre à jour le firware (même s'il est déja à jour). Sans cette opération elle ne veut pas du certificat. * télécharger le firmware [http://www.hp.com/go/wja_firmware] pour le modèle ''J7934A'' * sur l'interface web, aller dans ''Réseau'' ''Autres paramètres'' ''Mise à niv. du microlog'' * donner le fichier dld télécharger et attendre la mise à jour Après cette formalitée remplie, on peut aller dans ''Réseau'' / ''Autorisation'' / ''Certificats'' / ''Configurer'' / ''Installer le certificat'' et installer le fichier .pem donnée par le CA. == 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> }}} = Liens = |
| Ligne 73: | Ligne 240: |
| * http://www.hsc.fr/ressources/breves/ssl_virtualhosts.html.fr ---- ["CatégorieCrans/PageNonTerminée"] |
Afin de s'assurer la sécurité d'une communication sécurités, les participants d'une communication doivent pouvoir communiquer de façon sécurisée (chiffré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, 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é pas le CA.
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
On commence par creer une architecture de dossier :
export $CA=/etc/ssl/CA_crans mkdir $CA $CA/certs $CA/crl $CA/newcerts $CA/private touch $CA/index.txt
On écrit le fichier de configuration /etc/ssl/CA_crans/openssl.cnf :
### Configuration du CA pour les signatures
HOME = /etc/ssl
RANDFILE = $ENV::HOME/.rnd
####################################################################
[ ca ]
default_ca = CA_crans
####################################################################
[ 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.pemPuis on demande à openssl de générer une paire de clés :
openssl req -new -x509 -keyout $CA/private/cakey.pem -out $CA/cacert.pem -days 7300
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érent à la mettre à jou à chaque fois.
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]
Création d'une demande de certificats de sécurité SSL
openssl
C'était la methode utilisée avant, les fichiers *.cnf se trouvent sur vert dans le dossier /etc/ssl/oldconfs
Une fois qu'on a écrit les fichier de configuration service.cnf, on demande à openssl de créer une demande de certificat :
openssl req -config service.cnf -new -nodes -keyout service.key -out service.req
Le premier fichier corespond à la clé privée pour du certificat, le deuxième corespond à le 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 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
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
Apache
Signature d'une demande de certificat
openssl ca -config /etc/ssl/CA_crans/openssl.cnf -out service.pem -in service.req
Le certificat à signer est celui de service.req et le certificat signé sera alors dans service.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.
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.
JedDirect (l'imprimante)
La première étape à faire est de mettre à jour le firware (même s'il est déja à jour). Sans cette opération elle ne veut pas du certificat.
télécharger le firmware [http://www.hp.com/go/wja_firmware] pour le modèle J7934A
sur l'interface web, aller dans Réseau Autres paramètres Mise à niv. du microlog
- donner le fichier dld télécharger et attendre la mise à jour
Après cette formalitée remplie, on peut aller dans Réseau / Autorisation / Certificats / Configurer / Installer le certificat et installer le fichier .pem donnée par le CA.
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>