Mise en oeuvre d’un serveur Apache utilisant les certificats issus de l’IGC du CNRS
Cette page WWW résume les
opérations nécessaires pour la configuration d'un serveur
Apache 1 ou 2 utilisant des certificats issus de l'Infrastructure de
gestion de clés (IGC) du CNRS.
Les exemples qui illustrent cette présentation
sont tirés de configurations d'Apache 2.0 sur Linux CentOS 5.2.
Sur ces plateformes, ils sont
réutilisables par copier/coller. Sur d'autres plateformes, il
peuvent nécessiter des adaptations.
Dans la suite, nous utiliserons les termes de "serveur HTTP" pour
désigner les sevices WWW rendus via le protocole HTTP (Hypertext Transfer Protocol)
sur le port 80 et le terme "serveur HTTPS", pour ceux rendus via le
protocole HTTP sur SSL (Secure Socket Layer)
et/ou TLS (Transport Layer
Security) sur le port 443.
|
Sommaire
La demande de
certificat pour le serveur
La demande de certificat pour le serveur HTTPS s'effectue via un
formulaire WWW de l'IGC du CNRS.
La procédure pour obtenir le certificat est la suivante
:
- Cliquez sur ce lien pour accéder au
formulaire de demande de certificats de l'Autorité de
certification CNRS-Standard
- Cliquez sur le lien "Demande"
situé dans le pavé "Certificats serveurs" situé
dans le bandeau de gauche de la page qui s'affiche.
- Saisir les informations concernant le serveur WWW pour
lequel est effectuée la demande.
- Le nom
à saisir est en fait le nom du site WWW accessible via le
serveur
pour lequel on demande le certificat. C'est donc le nom qui apparait
dans l'URL utilisée pour accéder au site. Il peut
être différent du nom du serveur lui même.
Par exemple, dans la Délégation, le serveur WWW est kafka.dr15.cnrs.fr. Ce serveur
héberge le site https://www.dr15.cnrs.fr.
Le certificat a donc été demandé pour www.dr15.cnrs.fr et non pas pour kafka.dr15.cnrs.fr.
- L'adresse mél
indiquée apparaitra dans le certificat du serveur. Elle sera
donc
visible depuis les navigateurs des clients (par exemple par le menu
Afficher -> Informations sur la page) accédant au
serveur via le protocole HTTPS. On indique donc
plutôt
un alias, comme webmaster pour un serveur HTTPS, postmaster pour un
serveur de messagerie, etc.
- Le numéro de
téléphone est celui qui sera utilisé par
l'autorité d'enregistrement lors de la validation du certificat.
Validez la demande. L'autorité d'enregistrement de votre
laboratoire reçoit
alors une demande de validation de cette demande. Il vous contacte pour
vérifier le bien fondé de cette demande. Le cas
échéant, il valide le certificat.
Vous recevez alors un message signé et chiffré
contenant
deux pièces attachées. La première est
nommée nom.de.votre.serveur.pem.
Elle contient le certificat pour votre serveur. Sauvegardez cette
pièce jointe dans un fichier sur votre serveur. Il ne contient
pas d'information confidentielle.
La deuxième pièce jointe s'appelle nom.de.votre.serveur.key. Elle
contient la clé privée pour votre serveur. De la
protection de cette clé dépendra la
sécurité
de votre serveur. Sauvegardez cette pièce jointe dans un
répertoire de votre serveur qui n'est accessible que par
vous-même. Utilisez alors les mécanismes de gestion des
droits sur ce fichier afin qu'il ne soit lisible que par vous. La
commande Unix correspondante est la suivante :
chmod 400 nom.de.votre.serveur.key
Configuration
de mod_ssl pour Apache 2.x
Le support de SSL, et donc a fortiori de HTTPS, dans
Apache est assuré par un module appelé mod_ssl. La plupart des distributions
de Linux incluent les paquetages nécessaires pour une
installation immédiate de mod_ssl. Des exemples de configuration
sont également fournis avec ces paquetages.
Dans Apache 2.0, la configuration du module mod_ssl est
dans un fichier nommé conf.d/ssl.conf.
On y trouvera deux sortes de directives concernant SSL. Les
directives globales, notamment celles qui concernent la gestion du
cache
SSL, le générateur de nombres pseudo-aléatoires,
les types MIME concernant les autorités de certifications,
etc. Ces directives n'ont pas besoin d'être
modifiées
pour une utilisation des certificats issus de l'IGC du CNRS.
Un second ensemble de directive se trouve dans la section
comprise entre la balise "<VirtualHost
_default_:443>" et la balise "</VirtualHost>".
Tous les exemples de configuration
ci-dessous concernent cette section. Si ces lignes sont absentes, vous
devrez les rajouter, si ces lignes sont commentées (elles
commencent par le caractère "#"),
vous pouvez simplement supprimer le commentaire. Notez que les chemins
d'accès sont ceux qui correspondent à Linux CentOS 5.2.
Sur d'autres plateformes, vous aurez éventuellement besoin
de modifier ces fichiers.
La clé
privée du serveur
Le chemin d'accès du fichier contenant la clé
privée du serveur est indiqué par la directive "SSLCertificateKeyFile". A
l'origine, la directive contient :
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
Modifiez cette ligne et remplacez la par :
SSLCertificateKeyFile /etc/pki/tls/private/nom.de.votre.serveur.key
Dans certaines distributions de mod_ssl pour Apache,
le répertoire de la clé privée contient un certain
nombre d'exemples de certificats de serveurs. Ces certificats sont
inutiles. Vous pouvez les supprimer par les commandes suivantes :
cd /etc/pki/tls/private
rm -f snake*.key
Copiez le fichier
nom.de.votre.serveur.key
dans le répertoire "
/etc/pki/tls/private".
Modifiez les permissions de ce fichier afin qu'il ne soit lisible que
par l'administrateur. Les commandes Unix correspondantes sont les
suivantes :
mv nom.de.votre.serveur.key /etc/pki/tls/private/.
chown root:root /etc/pki/tls/private/nom.de.votre.serveur.key
chmod 400 /etc/pki/tls/private/nom.de.votre.serveur.key
Le certificat
du serveur
Le chemin d'accès du fichier contenant le certificat du
serveur est indiqué par la directive "SSLCertificateFile" qui
s'utilise comme suit :
SSLCertificateFile /etc/pki/tls/certs/localhost.crt
Modifiez cette ligne et remplacez là par :
SSLCertificateFile /etc/pki/tls/certs/nom.de.votre.serveur.pem
Copiez le fichier
nom.de.votre.serveur.pem
dans le répertoire "
/etc/pki/tls/certs/nom.de.votre.serveur.pem".
Les commandes Unix correspondantes sont les suivantes :
mv nom.de.votre.serveur.pem /etc/pki/tls/certs/.
chown root:root /etc/pki/tls/certs/nom.de.votre.serveur.pem
Les
autorités de certification
Lorsque le serveur HTTPS requiert le certificat de
l'utilisateur, il vérifie que l'émetteur de ce certificat
fait partie d'une liste d'autorités de certifications
acceptables. Il y a deux directives qui indiquent à mod_ssl
comment constituer cette liste.
La directive "SSLCACertificateFile"
indique le chemin d'accès vers un fichier contenant, l'un
à la suite de l'autre, tous les certificats acceptables. La
distribution de mod_ssl pour Apache 2.x fournit un tel fichier,
appelé "ca-bundle.crt",
qui correspond à peu de choses près à la liste des
autorités de certitication pré-configurées dans
les
navigateurs comme Internet Explorer, Mozilla, Netscape, etc.
Il serait possible de rajouter les autorités de
certification du CNRS dans cette liste. Malheureusement, toute mise
à jour ultérieure de mod_ssl risque d'entraîner la
perte de ces informations.
Pour cette raison, on utilisera plutôt la directive "SSLCACertificatePath" qui
indique le chemin d'un répertoire contenant, à raison
d'un
certificat par fichier, les certificats des autorités de
certification du CNRS et de vos partenaires.
On peut très bien utiliser ces deux directives en
parallèle, comme indiqué ci-dessous (le répertoire
"/etc/pki/tls/ca-certs"
qui n'existe pas dans la distribution de mod_ssl sera
créé ultérieurement) :
SSLCACertificatePath /etc/pki/tls/ca-certs
SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
Il ne reste plus qu'à copier dans le répertoire
indiqué par la directive "SSLCACertificatePath"
les autorités de certification du CNRS. Pour plus de
facilité, vous trouverez ci-dessous un document "ca-cnrs.tgz".
Il contient les principales autorités de certification
du CNRS. Recopiez l'archive obtenue dans un répertoire
quelconque du serveur, par exemple "/tmp". Effectuez l'extraction par
les commandes Unix suivantes :
mkdir /etc/pki/tls/ca-certs
cd /etc/pki/tls/ca-certs
gunzip </tmp/ca-cnrs.tgz | tar xvf -
Afin d'accélérer la recherche du certificat de
l'autorité de certification ayant émis le certificat de
l'utilisateur, Apache utilise les hash-codes
des certificats et non pas les noms des fichiers contenus dans ce
répertoire. C'est pourquoi ce dernier contient un fichier "Makefile.crt" permettant
d'associer sous forme de lien symbolique le hash-code d'un certificat
avec le nom du fichier qui le contient. Lancez les commandes suivantes
afin de reconstituer ces associations :
cd /etc/pki/tls/ca-certs
make -f Makefile.crt
Ces deux commandes doivent être relancées chaque
fois qu'une nouvelle autorité de certification est
ajoutée
dans ce répertoire. Il n'est pas nécessaire de relancer
le
serveur Apache.
La chaîne
de certification
Le chemin d'accès menant du certificat du serveur vers
le certificat de l'autorité de certification racine du CNRS est
indiqué par la directive "SSLCertificateChainFile",
qui s'utilise comme suit :
SSLCertificateChainFile /etc/pki/tls/certs/server-cert-chain.crt
Le fichier indiqué contient la concaténation du
certificat du serveur, du certitificat de l'autorité
CNRS-Standard et du certificat de l'autorité CNRS. Pour
constituer ce fichier, utilisez les commandes suivantes :
cd /etc/pki/tls/certs/
cat nom.de.votre.serveur.pem \
../ca-certs/ca-cnrs2-standard.crt > server-cert-chain.crt
La longueur de
la chaîne de certification pour les clients
Lorsque la configuration des accès à une page du
serveur exige que l'utilisateur présente son certificat, Apache
vérifie la profondeur de la chaîne de certification qui
mène de ce certificat inclus à un certificat
d'autorité de certification racine exclus.
Les certificats CNRS2-Standard et CNRS2-Plus ont une longueur de 2.
Les
certificats CNRS2-Projets ont une longueur de 3.
La directive "SSLVerifyDepth"
permet d'indiquer la profondeur maximale autorisée. Par
défaut, elle est de 1.Modifiez-la en conséquence. La
ligne
suivante correspond à la valeur minimale pour une utilisation de
votre serveur Apache avec les certificats personnels du CNRS :
SSLVerifyDepth 3
Les listes de
révocation
Chaque autorité de certification publie à
intervalles réguliers une liste de révocation (certificate revocation list, CRL)
contenant les numéros de série des certificats
révoqués. Il s'agit de ceux qui ont été
déclarés invalides avant leur date d'expiration, soit
parce que leur titulaire a quitté ses fonctions dans le
laboratoire, soit parce que la clé privée
correspondante a été déclarée perdue ou
volée.
Pour votre serveur HTTPS, il est recommandé de mettre
à jour ces listes afin d'empêcher quiconque d'utiliser un
certificat révoqué. Dans Apache, les listes de
révocation sont stockées dans le répertoire
indiqué par les directives "SSLCARevocationPath"
et "SSLCARevocationFile".
Ces directives fonctionnent comme celles qui concernent les
autorités de certification.
La directive "SSLCARevocationFile"
désigne un fichier contenant toutes les listes de
révocation des autorités de certifications
installées sur ce site. En pratique, à chaque
modification
de l'une de ces listes de révocation, il faut reconstituer ce
fichier et recharger Apache. Cette opération n'étant pas
très dynamique, on préfèrera la seconde directive,
"SSLCARevocationPath".
La directive "SSLCARevocationPath"
désigne un répertoire contenant un ensemble de fichiers,
chacun d'eux correspondant à une liste de révocation. Ce
répertoire sera créé ultérieurement. Les
fichiers qu'il contient sont indexés via le "Makefile.crl" contenu dans ce
répertoire. Cette directive s'utilise comme suit :
SSLCARevocationPath /etc/pki/tls/ca-crls
Vous trouverez ci-dessous une archive "getcrl-cnrs.tgz" qui
contient le fichier "Makefile.crl" et le script "getcrl-cnrs". Il
permet de télécharger automatiquement toutes les listes
de
révocations des
autorités du CNRS. Ce script utilise la commande "wget". Vérifiez qu'elle est
disponible sur votre serveur. Ce script utilise aussi le chemin
d'accès du répertoire des listes de révocation tel
que configuré en standard sur Linux CentOS 5.2. Si vos listes de
révocation ne sont pas dans "/etc/pki/tls/ca-crls",
modifiez le script en conséquence, ligne 45.
Copiez cette archive dans un réperotire quelconque, par
exemple "/tmp". Effectuez l'extraction et le transfert des CRL par les
commandes Unix suivantes :
mkdir /etc/pki/tls/ca-crls
cd /etc/pki/tls/ca-crls
gunzip < /tmp/getcrl-cnrs.tgz | tar xvf -
./getcrl-cnrs
Rajoutez dans la crontab de
votre serveur la ligne qui permettra d'aller recharger ces listes
de révocation chaque nuit comme indiqué ci-dessous. Afin
que tous les serveurs configurés à l'aide de
cette fiche pratique n'aillent pas solliciter les serveurs de l'IGC au
même moment, l'exemple ci-dessous ne donne ni l'heure, ni les
minutes. L'heure s'indique de 0 à 23 et les minutes de 0
à
59.
minute heure * * * /etc/pki/tls/ca-crls/getcrl-cnrs
Relancez votre
serveur Apache
Vous pouvez (re)lancer le serveur Apache par la commande
suivante :
/sbin/service httpd restart
Par défaut, les hiérarchies des pages du serveur
HTTP et du serveur HTTPS sont les mêmes. Vous pouvez donc
accéder en HTTPS à votre site WWW par l'URL https://nom.de.votre.serveur
Exemples de
configuration d'accès authentifiés par certificats
Il n'est certes pas très utile de chiffrer des pages
accessibles en clair par ailleurs. Vous pouvez donc définir les
pages spécifiques de votre serveur HTTPS via la directive "DocumentRoot". De même,
il est recommandé de mettre à jour les différentes
informations administratives concernant le serveur HTTPS dans le
fichier
de configuration de SSL.
Par exemple, on trouvera les directives suivantes pour
indiquer que les pages accessibles en SSL sont dans le
répertorie
"/var/www/ssl", que le site
WWW s'appelle www.labo.cnrs.fr
et que l'adresse de l'administrateur webmaster@labo.cnrs.fr.
DocumentRoot "/var/www/ssl"
ServerName www.labo.cnrs.fr
ServerAdmin webmaster@labo.cnrs.fr
Notez que "ServerName"
correspond au nom du serveur pour lequel on a demandé le
certificat.
Les exemples qui suivent vous indiqueront comment mettre en
place des services utilisant les certificats, comme par exemple :
- un service authentifié par nom d'utilisateur et mot
de passe : l'intérêt de HTTPS dans ce cas est que le nom
d'utilisateur et le mot de passe circulent exclusivement de
façongetcrl-cnrs
chiffrée.
- un extranet du laboratoire : l'accès ne sera
permis qu'aux titulaires d'un certificat contenant le code de votre
laboratoire,
- un service restreint à une liste
d'utilisateurs : l'accès ne sera autorisé qu'aux
titulaires des certificats indiqués dans cette liste.
Dans ce chapitre également, tous
les exemples de configuration ci-dessous concernent la section
délimitée entre les balises "</VirtualHost _defaut_:443>"
et "</VirtualHost>"
du fichier de configuration SSL.
Elles sont toutes à insérer juste avant la balise "</VirtualHost>".
Configurer un
service authentifié par nom d'utilisateur et mot de passe
Le protocole HTTP définit un mécanisme
d'authentification très rudimentaire. Il consiste à coder
en Base64 l'identifiant et le mot de passe saisis par l'utilisateur et
à transmettre le résultat au serveur. Ce mécanisme
n'est donc pas plus sûr que l'échange en clair de ces
informations.
Cependant, si on utilise le protocole HTTPS, toutes les
informations échangées entre le client et le serveur sont
chiffrées. Ainsi, le mécanisme
ci-dessus
devient aussi sûr que peut l'être le protocole SSL. C'est
une solution optimale pour mettre en place un Webmail qui permet aux
utilisateurs d'accéder à leur messagerie depuis n'importe
quel poste de travail.
La configuration d'un service authentifié par
identifiant et mot de passe est assez largement décrite dans la
littérature concernant l'administration d'un serveur Apache.
Nous
rappellerons ici les grandes lignes.
Le fichier des utilisateurs et de leurs mots de passe peut
être situé à tout endroit hors de la
hiérarchie de fichiers accessibles par le WWW. La commande "htpasswd" permet de
créer (option "-c")
ou de modifier (sans l'option "-c")
un tel fichier. Dans l'exemple ci-dessous, on a placé le fichier
"pw_exemple1" des mots de passe dans le répertoire de
configuration d'Apache. La déclaration des utilisateurs et
de leurs mots de passe se fait de la façon suivante :
cd /etc/httpd/conf
htpasswd -c pw_exemple1 user1
htpasswd pw_exemple1 user2
htpasswd pw_exemple1 user3
...
chmod 644 pw_exemple1
La dernière ligne est impérative, car la
commande "htpasswd -c"
crée le fichier avec des permissions tellement restrictives
qu'il
ne peut pas être lu par les instances du serveur WWW
chargées de vérifier le mot de passe.
Les pages WWW concernant le service qu'on souhaite
authentifier par identifiant et mot de passe sont placées dans
le
répertoire "exemple1"
relativement au répertoire indiqué par la directive "DocumentRoot" ci-dessus. Les
directives d'Apache utilisées pour déclarer ce service
sont les suivantes :
# Exemple de service authentifie par mot de passe
<Location /exemple1>getcrl-cnrs
AllowOverride AuthConfig
AuthType Basic
AuthName "Premier exemple"
AuthUserFile /etc/httpd/conf/pw_exemple1
require valid-user
</Location>
Configurer un
service restreint à un groupe d'utilisateurs
Le module mod_ssl permet d'utiliser le même
mécanisme que ci-dessus, mais en se servant du certificat de
l'utilisateur en lieu et place de son identifiant et de son mot de
passe. La validité du certificat présenté par
l'utilisateur est vérifiée par mod_ssl. Ensuite, Apache
utilise le nom distingué (Distinguished
name, DN) contenu dans le certificat de l'utilisateur comme
identifiant et le recherche dans le fichier des mots de passe. La
vérification du mot de passe est totalement inutile, mais pour
des raisons techniques, Apache va le comparer à une chaîne
de caractère prédéfinie. Il s'agit de "password".
Ainsi, pour une authentification des utilisateurs par
certificat, Apache nécessite un fichier de mots de passe qui
contient une ligne par utilisateur autorisé. Cette ligne
comprend
deux valeurs séparées par des ":", la première est
le DN correspondant à l'utilisateur, la deuxième est
l'encodage du mot "password".
L'exemple ci-dessous donne le contenu d'un tel fichier pour
Apache 2.0 :
/C=FR/O=CNRS/OU=UMR123/CN=Prenom1 Nom1/emailAddress=nom1@lab.cnrs.fr:xxj31ZMTZzkVA
/C=FR/O=CNRS/OU=MOY123/CN=Prenom2 Nom2/emailAddress=nom2@lab.cnrs.fr:xxj31ZMTZzkVA
...
Les directives Apache sont à peu de choses près
les mêmes que celles pour une authentification par identificateur
et mot de passe. Il faut juste rajouter le fait que l'authentification
se fait par SSL (option "+FakeBasicAuth")
et que la présentation du certificat de l'utilisateur est
requise (directive "SSLVerifyClient").
Le fichier "pw_exemple2" est au format décrit ci-dessus :
# Exemple de service authentifie par certificats
<Location /exemple2>
SSLVerifyClient require
SSLOptions +FakeBasicAuth
AllowOverride AuthConfig
AuthType Basic
AuthName "Deuxième exemple"
AuthUserFile /etc/httpd/conf/pw_exemple2
require valid-user
</Location>
Notez que si un utilisateur non autorisé tente
d'accéder à ce service, il verra s'afficher une
fenêtre d'authentification lui demandant son identificateur et
son
mot de passe. Il n'y a aucune combinaison d'identificateur et de mot de
passe qui puisse fonctionner.
Par ailleurs, si vous avez un grand nombre d'utilisateurs
à gérer de la sorte, les performances de
l'authentification seront sensiblement améliorées
en
utilisant un fichier DBM pour indexer la liste des DN des certificats
autorisés. Consultez la documentation d'Apache concernant la
directive AuthDBMUserFile.
Configuration
d'un Extranet de laboratoire
Les deux exemples précédents impliquent qu'on
connaisse la liste exhaustive des utilisateurs potentiels du service.
Apache permet également de définir des listes de
contrôles d'accès fondées sur les
caractéristiques des certificats des utilisateurs. On peut
par exemple tester si le certificat a été émis par
telle ou telle autorité de certification, si l'attribut
décrivant le laboratoire a telle ou telle valeur, etc.
Les directives ci-dessous permettent de vérifier si
l'utilisateur qui désire accéder au service "exemple3" dispose d'un certificat
émis par l'une des autorités de certification du CNRS et
que le code de laboratoire dans le certificat est UMR1234.
# Exemple de service authentifie par liste de controles d'acces
<Location /exemple3>
SSLVerifyClient require
SSLRequire ( %{SSL_CLIENT_I_DN} eq "/C=FR/O=CNRS/CN=CNRS2-Plus" \
or %{SSL_CLIENT_I_DN} eq "/C=FR/O=CNRS/CN=CNRS2-Standard" \
) \
and %{SSL_CLIENT_S_DN_OU} eq "UMR1234"
</Location>
La documentation de
la directive "SSLRequire"
de mod_ssl décrit la syntaxe et les différents attributs
qu'on peut utiliser pour déclarer des listes de contrôles
d'accès.
Configuration pour les scripts
Apache et mod_ssl permettent d'enrichir l'environnement des
scripts CGI, PHP, etc. avec les informations issues des algorithmes de
chiffement utilisés, du certificat du serveur, du certificat de
l'utilisateur s'il a été requis, etc.
C'est la section "<Files
...>" d'Apache qui contrôle ces opérations. Le
paramètre est une expression régulière Perl
décrivant les fichiers auxquels s'appliquent les directives
contenues dans cette section. Sur une distribution de Apache et mod_ssl
sur RedHat 9, la section "Files"
est configurée comme suit :
<Files ~ "\.(cgi|shtml|phtml|php3?)$">
SSLOptions +StdEnvVars
</Files>
Cette configuration indique que lors de l'accès aux
pages dont le suffixe est "cgi",
"shtml", "pthml, "php" suivi ou pas d'un "3", l'option SSL "StdEnvVars" est activée.
Cette option permet de transmettre au script via l'environnement, un
ensemble de variables décrivant la connexion sur laquelle ces
pages ont été requises. La documentation de mod_ssl
décrit la signification de toutes ces variables. Le script PHP
ci-dessous en donne une bonne idée :
<head>
<title>CNRS DR15 - Test PHP</title>
</head>
<body>
<pre>
<?php print_r ($HTTP_SERVER_VARS) ?>
</pre>
</body>
Installez ce script dans le répertoire "exemple3"
ci-dessus sous le nom "printenv.php"
et accédez à l'URL https://nom.de.votre.serveur/exemple3/printenv.php. Vous
pouvez aussi utiliser le script suivant qui est un script CGI
écrit en Perl : https://www.dr15.cnrs.fr/auth-cgi/printenv
La liste des variables de l'environnement s'affiche.
Souvenez-vous que le serveur HTTPS a été
configuré de telle sorte que l'utilisateur doit présenter
son certificat pour accéder aux pages contenues dans
répertoire "exemple3".
L'environnement du script sera alors enrichi de variables
décrivant le certificat de l'utilisateur. Elles commencent
toutes
par "SSL_CLIENT_S_DN_xx". Le "S" signifie "subject" (titulaire du certificat)
et "DN" signifie "Distinguished Name".
Les "xx" correspondent aux
divers attributs contenus qui composent le DN du certificat de
l'utilisateur. Ainsi :
| SSL_CLIENT_S_DN_C |
correspond au pays (FR) |
| SSL_CLIENT_S_DN_O |
correspond à
l'organisme (CNRS) |
| SSL_CLIENT_S_DN_OU |
correspond à la
subdivision de l'organisme. C'est le code du laboratoire |
| SSL_CLIENT_S_DN_CN |
correspond au
prénom et au nom (dans cet ordre) du titulaire du certificat |
| SSL_CLIENT_S_DN_Email |
correspond à
l'adresse électronique du titulaire du certificat |
Les variables commençant par "SSL_CLIENT_I_DN_" donnent ces
informations pour l'autorité de certification qui a émis
le certificat. Le "I"
signifie issuer
(émetteur).
Les variables commençant par "SSL_CIPHER_" donnent les
informations sur l'algorithme de chiffrement utilisé, la
longueur
des clés, etc.
Vous pouvez également afficher le contenu des
certificats du client et du serveur. Comme cette opération
alourdit l'environnement, donc le volume de données transmises
entre le serveur et le script, elle n'est pas activée par
défaut. Pour ce faire, vous devez modifier la section Files comme suit :
<Files ~ "\.(cgi|shtml|phtml|php3?)$">
SSLOptions +StdEnvVars +ExportCertData
</Files>
Avec toutes ces variables, vous pourrez procéder
à la réalisation de scripts authentifiés par
certificat avec un très haut degré de souplesse.
Cette archive contient les principales autorités de certification du CNRS. Son contenu est à installer dans /etc/pki/tls/ca-certs
Ce script permet de récupérer les listes de révocations des autorités de certification du CNRS. Il est à installer dans /etc/pki/tls/ca-crls et à lancer à intervalles réguliers via la crontab
