Le CNRS
   Accueil > La Délégation à votre service > Informatique > Les certificats > Espace administration système > Mise en oeuvre d’un serveur Apache utilisant les certificats issus de l’IGC du CNRS

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 :

  1. Cliquez sur ce lien pour accéder au formulaire de demande de certificats de l'Autorité de certification CNRS-Standard
  2. Cliquez sur le lien "Demande" situé dans le pavé "Certificats serveurs" situé dans le bandeau de gauche de la page qui s'affiche.
  3. 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.



Liste des autorités de certification du CNRS -

Cette archive contient les principales autorités de certification du CNRS. Son contenu est à installer dans /etc/pki/tls/ca-certs



Script de récupération des listes de révocation -

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

 

Rechercher


sur le site de la délégation
Le CNRS Accueil Crédits Crédits Le CNRS Annuaires Mots clefs CNRS Autres sites Accueil Imprimer Contact Crédits Plan du site