mirror of
https://github.com/apache/httpd.git
synced 2025-07-05 16:21:14 +03:00
3bdce8069a
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1771654 13f79535-47bb-0310-9956-ffa450edef68
1019 lines
55 KiB
Plaintext
1019 lines
55 KiB
Plaintext
<?xml version="1.0" ?>
|
|
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
|
|
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
|
|
<!-- English Revision: 1682923 -->
|
|
<!-- French translation : Lucien GENTIS -->
|
|
<!-- Reviewed by : Vincent Deffontaines -->
|
|
|
|
<!--
|
|
Licensed to the Apache Software Foundation (ASF) under one or more
|
|
contributor license agreements. See the NOTICE file distributed with
|
|
this work for additional information regarding copyright ownership.
|
|
The ASF licenses this file to You under the Apache License, Version 2.0
|
|
(the "License"); you may not use this file except in compliance with
|
|
the License. You may obtain a copy of the License at
|
|
|
|
http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
Unless required by applicable law or agreed to in writing, software
|
|
distributed under the License is distributed on an "AS IS" BASIS,
|
|
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
See the License for the specific language governing permissions and
|
|
limitations under the License.
|
|
-->
|
|
|
|
<manualpage metafile="ssl_faq.xml.meta">
|
|
<parentdocument href="./">SSL/TLS</parentdocument>
|
|
|
|
<title>Chiffrement SSL/TLS fort: foire aux questions</title>
|
|
|
|
<summary>
|
|
<blockquote>
|
|
<p>Le sage n'apporte pas de bonnes réponses, il pose les bonnes questions</p>
|
|
<p class="cite">-- <cite>Claude Levi-Strauss</cite></p>
|
|
|
|
</blockquote>
|
|
</summary>
|
|
|
|
<section id="installation"><title>Installation</title>
|
|
<ul>
|
|
<li><a href="#mutex">Pourquoi le démarrage d'Apache provoque-t-il des
|
|
erreurs de permission en rapport avec SSLMutex ?</a></li>
|
|
<li><a href="#entropy">Pourquoi mod_ssl s'arrête-t-il avec l'erreur
|
|
"Failed to generate temporary 512 bit RSA private key" au démarrage
|
|
d'Apache ?</a></li>
|
|
</ul>
|
|
|
|
<section id="mutex"><title>Pourquoi le démarrage d'Apache provoque-t-il des
|
|
erreurs de permission en rapport avec SSLMutex ?</title>
|
|
<p>Des erreurs telles que ``<code>mod_ssl: Child could not open
|
|
SSLMutex lockfile /opt/apache/logs/ssl_mutex.18332 (avec l'erreur
|
|
système qui suit) [...] System: Permission denied (errno: 13)</code>''
|
|
sont souvent provoquées par des permissions trop restrictives sur les
|
|
répertoires <em>parents</em>. Assurez-vous que tous les répertoires
|
|
parents (ici <code>/opt</code>, <code>/opt/apache</code> et
|
|
<code>/opt/apache/logs</code>) ont le bit x positionné au moins pour
|
|
l'UID sous lequel les processus enfants d'Apache s'exécutent (voir la
|
|
directive <directive module="mod_unixd">User</directive>).</p>
|
|
</section>
|
|
|
|
<section id="entropy"><title>Pourquoi mod_ssl s'arrête-t-il avec l'erreur
|
|
"Failed to generate temporary 512 bit RSA private key" au démarrage
|
|
d'Apache ?</title>
|
|
<p>Pour fonctionner correctement, les logiciels de cryptographie ont
|
|
besoin d'une source de données aléatoires. De nombreux systèmes
|
|
d'exploitation libres proposent un "périphérique source d'entropie"
|
|
qui fournit ce service (il se nomme en général
|
|
<code>/dev/random</code>). Sur d'autres systèmes, les applications
|
|
doivent amorcer manuellement
|
|
le Générateur de Nombres Pseudo-Aléatoires d'OpenSSL
|
|
(Pseudo Random Number Generator -PRNG) à l'aide de données appropriées
|
|
avant de générer des clés ou d'effectuer un chiffrement à clé
|
|
publique. Depuis la version 0.9.5, les fonctions d'OpenSSL qui nécessitent
|
|
des données aléatoires provoquent une erreur si le PRNG n'a pas été amorcé
|
|
avec une source de données aléatoires d'au moins 128 bits.</p>
|
|
<p>Pour éviter cette erreur, <module>mod_ssl</module> doit fournir
|
|
suffisamment d'entropie au PRNG pour lui permettre de fonctionner
|
|
correctement. Ce niveau d'entropie est défini par la directive
|
|
<directive module="mod_ssl">SSLRandomSeed</directive>.</p>
|
|
</section>
|
|
</section>
|
|
<!-- /installation -->
|
|
|
|
<section id="aboutconfig"><title>Configuration</title>
|
|
<ul>
|
|
<li><a href="#parallel">Peut-on faire cohabiter HTTP et HTTPS sur le même
|
|
serveur ?</a></li>
|
|
<li><a href="#ports">Quel port HTTPS utilise-t-il ?</a></li>
|
|
<li><a href="#httpstest">Comment s'exprimer en langage HTTPS à des fins
|
|
de test ?</a></li>
|
|
<li><a href="#hang">Pourquoi la communication se bloque-t-elle lorsque je
|
|
me connecte à mon serveur Apache configuré pour SSL ?</a></li>
|
|
<li><a href="#refused">Pourquoi, lorsque je tente d'accéder en HTTPS à mon
|
|
serveur Apache+mod_ssl fraîchement installé, l'erreur ``Connection Refused''
|
|
s'affiche-t-elle ?</a></li>
|
|
<li><a href="#envvars">Pourquoi les variables <code>SSL_XXX</code>
|
|
ne sont-elles pas disponibles dans mes scripts CGI et SSI ?</a></li>
|
|
<li><a href="#relative">Comment puis-je basculer entre les protocoles HTTP et
|
|
HTTPS dans les hyperliens relatifs ?</a></li>
|
|
</ul>
|
|
|
|
<section id="parallel"><title>Peut-on faire cohabiter HTTP et HTTPS sur le même
|
|
serveur ?</title>
|
|
<p>Oui. HTTP et HTTPS utilisent des ports différents (HTTP écoute le port
|
|
80 et HTTPS le port 443), si bien qu'il n'y a pas de conflit direct entre
|
|
les deux. Vous pouvez soit exécuter deux instances séparées du serveur,
|
|
chacune d'entre elles écoutant l'un de ces ports, soit utiliser l'élégante
|
|
fonctionnalité d'Apache que constituent les hôtes virtuels pour créer
|
|
deux serveurs virtuels gérés par la même instance d'Apache - le
|
|
premier serveur répondant en HTTP aux requêtes sur le port 80,
|
|
le second répondant en HTTPS aux requêtes sur le port
|
|
443.</p>
|
|
</section>
|
|
|
|
<section id="ports"><title>Quel port HTTPS utilise-t-il ?</title>
|
|
<p>Vous pouvez associer le protocole HTTPS à n'importe quel port, mais le port
|
|
standard est le port 443, que tout navigateur compatible HTTPS va utiliser par
|
|
défaut. Vous pouvez forcer votre navigateur à utiliser un port différent en le
|
|
précisant dans l'URL. Par exemple, si votre serveur est configuré pour
|
|
servir des pages en HTTPS sur le port 8080, vous pourrez y accéder par
|
|
l'adresse <code>https://example.com:8080/</code>.</p>
|
|
</section>
|
|
|
|
<section id="httpstest"><title>Comment s'exprimer en langage HTTPS à des fins
|
|
de test ?</title>
|
|
<p>Alors que vous utilisez simplement</p>
|
|
|
|
<example>$ telnet localhost 80<br />
|
|
GET / HTTP/1.0</example>
|
|
|
|
<p>pour tester facilement Apache via HTTP, les choses ne sont pas si
|
|
simples pour HTTPS à cause du protocole SSL situé entre TCP et HTTP.
|
|
La commande OpenSSL <code>s_client</code> vous permet cependant
|
|
d'effectuer un test similaire via HTTPS :</p>
|
|
|
|
<example>$ openssl s_client -connect localhost:443 -state -debug<br />
|
|
GET / HTTP/1.0</example>
|
|
|
|
<p>Avant la véritable réponse HTTP, vous recevrez des informations
|
|
détaillées à propos de l'établissement de la connexion SSL. Si vous
|
|
recherchez un client en ligne de commande à usage plus général qui comprend
|
|
directement HTTP et HTTPS, qui peut effectuer des opérations GET et POST,
|
|
peut utiliser un mandataire, supporte les requêtes portant sur une partie
|
|
d'un fichier (byte-range), etc..., vous devriez vous tourner vers
|
|
l'excellent outil <a href="http://curl.haxx.se/">cURL</a>. Grâce à lui,
|
|
vous pouvez vérifier si Apache répond correctement aux requêtes via
|
|
HTTP et HTTPS comme suit :</p>
|
|
|
|
<example>$ curl http://localhost/<br />
|
|
$ curl https://localhost/</example>
|
|
</section>
|
|
|
|
<section id="hang"><title>Pourquoi la communication se bloque-t-elle lorsque je
|
|
me connecte à mon serveur Apache configuré pour SSL ?</title>
|
|
<p>Ceci peut arriver si vous vous connectez à un serveur HTTPS (ou à
|
|
un serveur virtuel) via HTTP (par exemple, en utilisant
|
|
<code>http://example.com/</code> au lieu de <code>https://example.com</code>).
|
|
Cela peut aussi arriver en essayant de vous connecter via HTTPS à un
|
|
serveur HTTP (par exemple, en utilisant <code>https://example.com/</code>
|
|
avec un serveur qui ne supporte pas HTTPS, ou le supporte, mais sur un
|
|
port non standard). Assurez-vous que vous vous connectez bien à un
|
|
serveur (virtuel) qui supporte SSL.</p>
|
|
</section>
|
|
|
|
<section id="refused"><title>Pourquoi, lorsque je tente d'accéder en HTTPS à mon
|
|
serveur Apache+mod_ssl fraîchement installé, l'erreur ``Connection Refused''
|
|
s'affiche-t-elle ?</title>
|
|
<p>Une configuration incorrecte peut provoquer ce type d'erreur.
|
|
Assurez-vous que vos directives <directive module="mpm_common"
|
|
>Listen</directive> s'accordent avec vos directives
|
|
<directive type="section" module="core">VirtualHost</directive>. Si
|
|
l'erreur persiste, recommencez depuis le début en restaurant la
|
|
configuration par défaut fournie par<module>mod_ssl</module>.</p>
|
|
</section>
|
|
|
|
<section id="envvars"><title>Pourquoi les variables <code>SSL_XXX</code>
|
|
ne sont-elles pas disponibles dans mes scripts CGI et SSI ?</title>
|
|
<p>Assurez-vous que la directive ``<code>SSLOptions +StdEnvVars</code>'' est
|
|
bien présente dans le contexte de vos requêtes CGI/SSI.</p>
|
|
</section>
|
|
|
|
<section id="relative">
|
|
<title>Comment puis-je basculer entre les protocoles HTTP et
|
|
HTTPS dans les hyperliens relatifs ?</title>
|
|
<p>Normalement, pour basculer entre HTTP et HTTPS, vous devez utiliser des
|
|
hyperliens pleinement qualifiés (car vous devez modifier le schéma de l'URL).
|
|
Cependant, à l'aide du module <module>mod_rewrite</module>, vous pouvez
|
|
manipuler des hyperliens relatifs, pour obtenir le même effet.</p>
|
|
<highlight language="config">
|
|
RewriteEngine on
|
|
RewriteRule "^/(.*)_SSL$" "https://%{SERVER_NAME}/$1" [R,L]
|
|
RewriteRule "^/(.*)_NOSSL$" "http://%{SERVER_NAME}/$1" [R,L]
|
|
</highlight>
|
|
|
|
<p>Ce jeu de règles rewrite vous permet d'utiliser des hyperliens de la
|
|
forme <code><a href="document.html_SSL"></code> pour passer en HTTPS
|
|
dans les liens relatifs. (Remplacez SSL par NOSSL pour passer en HTTP.)</p>
|
|
</section>
|
|
</section>
|
|
<!-- configuration -->
|
|
|
|
<section id="aboutcerts"><title>Certificats</title>
|
|
<ul>
|
|
<li><a href="#keyscerts">Qu'est-ce qu'un clé privée RSA, un certificat,
|
|
une demande de signature de certificat (CSR) ?</a></li>
|
|
<li><a href="#startup">Y a-t-il une différence au démarrage entre un serveur
|
|
Apache non SSL et un serveur Apache supportant SSL ?</a></li>
|
|
<li><a href="#selfcert">Comment créer un certificat auto-signé SSL à des
|
|
fins de test ?</a></li>
|
|
<li><a href="#realcert">Comment créer un vrai certificat SSL ?</a></li>
|
|
<li><a href="#ownca">Comment créer et utiliser sa propre Autorité de
|
|
certification (CA) ?</a></li>
|
|
<li><a href="#passphrase">Comment modifier le mot de passe
|
|
de ma clé privée ?</a></li>
|
|
<li><a href="#removepassphrase">Comment démarrer Apache sans avoir à entrer de
|
|
mot de passe ?</a></li>
|
|
<li><a href="#verify">Comment vérifier si une clé privée correspond bien
|
|
à son certificat ?</a></li>
|
|
<li><a href="#pemder">Comment convertir un certificat du format PEM
|
|
au format DER ?</a></li>
|
|
<li><a href="#gid">Pourquoi les navigateurs se plaignent-ils de ne pas pouvoir
|
|
vérifier mon certificat de serveur ?</a></li>
|
|
</ul>
|
|
|
|
<section id="keyscerts"><title>Qu'est-ce qu'un clé privée RSA, un certificat,
|
|
une demande de signature de certificat (CSR) ?</title>
|
|
<p>Un fichier de clé privée RSA est un fichier numérique que vous pouvez
|
|
utiliser pour déchiffrer des messages que l'on vous a envoyés. Il a son
|
|
pendant à caractère public que vous pouvez distribuer (par le biais de votre
|
|
certificat), ce qui permet aux utilisateurs de chiffrer les messages qu'ils
|
|
vous envoient.</p>
|
|
<p>Une Demande de Signature de Certificat (CSR) est un fichier numérique
|
|
qui contient votre clé publique et votre nom. La CSR doit être envoyée à
|
|
une Autorité de Certification (CA), qui va la convertir en vrai certificat
|
|
en la signant.</p>
|
|
<p>Un certificat contient votre clé publique RSA, votre nom, le nom
|
|
de la CA, et est signé numériquement par cette dernière. Les navigateurs
|
|
qui reconnaissent la CA peuvent vérifier la signature du certificat, et
|
|
ainsi en extraire votre clé publique RSA. Ceci leur permet de vous envoyer
|
|
des messages chiffrés que vous seul pourrez déchiffrer.</p>
|
|
<p>Se référer au chapitre <a href="ssl_intro.html">Introduction</a>
|
|
pour une description générale du protocole SSL.</p>
|
|
</section>
|
|
|
|
<section id="startup"><title>Y a-t-il une différence au démarrage entre un serveur
|
|
Apache non SSL et un serveur Apache supportant SSL ?</title>
|
|
<p>Oui. En général, avec ou sans <module>mod_ssl</module> intégré, le démarrage
|
|
d'Apache ne présente pas de différences. Cependant, si votre fichier de clé
|
|
privée SSL possède un mot de passe, vous devrez le taper au démarrage
|
|
d'Apache.</p>
|
|
|
|
<p>Devoir entrer manuellement le mot de passe au démarrage du serveur peut
|
|
poser quelques problèmes - par exemple, quand le serveur est démarré au
|
|
moyen de scripts au lancement du système. Dans ce cas, vous pouvez suivre
|
|
les étapes <a href="#removepassphrase">ci-dessous</a> pour supprimer le
|
|
mot de passe de votre clé privée. Gardez à l'esprit qu'agir ainsi augmente
|
|
les risques de sécurité - agissez avec précaution !</p>
|
|
</section>
|
|
|
|
<section id="selfcert"><title>Comment créer un certificat auto-signé SSL à des
|
|
fins de test ?</title>
|
|
<ol>
|
|
<li>Vérifiez qu'OpenSSL est installé et l'exécutable openssl dans votre
|
|
<code>PATH</code>.<br />
|
|
<br />
|
|
</li>
|
|
<li>Exécuter la commande suivante pour créer les fichiers
|
|
<code>server.key</code> et <code>server.crt</code> :<br />
|
|
<code><strong>$ openssl req -new -x509 -nodes -out server.crt
|
|
-keyout server.key</strong></code><br />
|
|
Ces fichiers seront utilisés comme suit dans votre
|
|
<code>httpd.conf</code> :
|
|
<highlight language="config">
|
|
SSLCertificateFile /path/to/this/server.crt
|
|
SSLCertificateKeyFile /path/to/this/server.key
|
|
</highlight>
|
|
</li>
|
|
<li>Il est important de savoir que le fichier <code>server.key</code> n'a
|
|
<em>pas</em> de mot de passe. Pour ajouter un mot de passe à la clé, vous
|
|
devez exécuter la commande suivante et confirmer le mot de passe comme
|
|
demandé.<br />
|
|
<p><code><strong>$ openssl rsa -des3 -in server.key -out
|
|
server.key.new</strong></code><br />
|
|
<code><strong>$ mv server.key.new server.key</strong></code><br /></p>
|
|
Sauvegardez le fichier <code>server.key</code> ainsi que son mot de
|
|
passe en lieu sûr.
|
|
</li>
|
|
</ol>
|
|
</section>
|
|
|
|
<section id="realcert"><title>Comment créer un vrai certificat SSL ?</title>
|
|
<p>Voici la marche à suivre pas à pas :</p>
|
|
<ol>
|
|
<li>Assurez-vous qu'OpenSSL est bien installé et dans votre <code>PATH</code>.
|
|
<br />
|
|
<br />
|
|
</li>
|
|
<li>Créez une clé privée RSA pour votre serveur Apache
|
|
(elle sera au format PEM et chiffrée en Triple-DES):<br />
|
|
<br />
|
|
<code><strong>$ openssl genrsa -des3 -out server.key 2048</strong></code><br />
|
|
<br />
|
|
Enregistrez le fichier <code>server.key</code> et le mot de passe
|
|
éventuellement défini en lieu sûr.
|
|
Vous pouvez afficher les détails de cette clé privée RSA à l'aide de la
|
|
commande :<br />
|
|
|
|
<br />
|
|
<code><strong>$ openssl rsa -noout -text -in server.key</strong></code><br />
|
|
<br />
|
|
Si nécessaire, vous pouvez aussi créer une version PEM non chiffrée
|
|
(non recommandé) de clé privée RSA avec :<br />
|
|
<br />
|
|
<code><strong>$ openssl rsa -in server.key -out server.key.unsecure</strong></code><br />
|
|
<br />
|
|
|
|
</li>
|
|
<li>Créez une Demande de signature de Certificat (CSR) à l'aide de la
|
|
clé privée précédemment générée (la sortie sera au format PEM):<br />
|
|
<br />
|
|
<code><strong>$ openssl req -new -key server.key -out server.csr</strong></code><br />
|
|
<br />
|
|
Vous devez entrer le Nom de Domaine Pleinement Qualifié
|
|
("Fully Qualified Domain Name" ou FQDN) de votre serveur lorsqu'OpenSSL
|
|
vous demande le "CommonName", c'est à dire que si vous générez une CSR
|
|
pour un site web auquel on accèdera par l'URL
|
|
<code>https://www.foo.dom/</code>, le FQDN sera "www.foo.dom". Vous
|
|
pouvez afficher les détails de ce CSR avec :<br />
|
|
|
|
<br />
|
|
<code><strong>$ openssl req -noout -text -in server.csr</strong></code><br />
|
|
<br />
|
|
</li>
|
|
<li>Vous devez maintenant envoyer la CSR à une Autorité de Certification
|
|
(CA), afin que cette dernière puisse la signer. Une fois la CSR signée,
|
|
vous disposerez d'un véritable certificat que vous pourrez utiliser avec
|
|
Apache. Vous pouvez faire signer votre CSR par une CA commerciale ou par
|
|
votre propre CA.<br />
|
|
Les CAs commerciales vous demandent en général de leur envoyer la CSR
|
|
par l'intermédiaire d'un formulaire web, de régler le montant de la
|
|
signature, puis vous envoient un certificat signé que vous pouvez
|
|
enregistrer dans un fichier server.crt.
|
|
|
|
Pour plus de détails sur la manière de créer sa propre CA, et de
|
|
l'utiliser pour signer une CSR, voir <a href="#ownca">ci-dessous</a>.<br />
|
|
|
|
Une fois la CSR signée, vous pouvez afficher les détails du certificat
|
|
comme suit :<br />
|
|
<br />
|
|
<code><strong>$ openssl x509 -noout -text -in server.crt</strong></code><br />
|
|
|
|
</li>
|
|
<li>Vous devez maintenant disposer de deux fichiers :
|
|
<code>server.key</code> et <code>server.crt</code>. Ils sont précisés dans
|
|
votre fichier <code>httpd.conf</code> comme suit :
|
|
<highlight language="config">
|
|
SSLCertificateFile /path/to/this/server.crt
|
|
SSLCertificateKeyFile /path/to/this/server.key
|
|
</highlight>
|
|
Le fichier <code>server.csr</code> n'est plus nécessaire.
|
|
</li>
|
|
|
|
</ol>
|
|
</section>
|
|
|
|
<section id="ownca"><title>Comment créer et utiliser sa propre Autorité de
|
|
certification (CA) ?</title>
|
|
<p>La solution la plus simple consiste à utiliser les scripts
|
|
<code>CA.sh</code> ou <code>CA.pl</code> fournis avec OpenSSL. De
|
|
préférence, utilisez cette solution, à moins que vous ayez de bonnes
|
|
raisons de ne pas le faire. Dans ce dernier cas, vous pouvez créer un
|
|
certificat auto-signé comme suit :</p>
|
|
|
|
<ol>
|
|
<li>Créez une clé privée RSA pour votre serveur
|
|
(elle sera au format PEM et chiffrée en Triple-DES) :<br />
|
|
<br />
|
|
<code><strong>$ openssl genrsa -des3 -out server.key 2048</strong></code><br />
|
|
<br />
|
|
Sauvegardez le fichier <code>server.key</code> et le mot de passe
|
|
éventuellement défini en lieu sûr.
|
|
Vous pouvez afficher les détails de cette clé privée RSA à l'aide de la
|
|
commande :<br />
|
|
<br />
|
|
<code><strong>$ openssl rsa -noout -text -in server.key</strong></code><br />
|
|
<br />
|
|
Si nécessaire, vous pouvez aussi créer une version PEM non chiffrée
|
|
(non recommandé) de cette clé privée RSA avec :<br />
|
|
<br />
|
|
<code><strong>$ openssl rsa -in server.key -out server.key.unsecure</strong></code><br />
|
|
<br />
|
|
</li>
|
|
<li>Créez un certificat auto-signé (structure X509) à l'aide de la clé RSA
|
|
que vous venez de générer (la sortie sera au format PEM) :<br />
|
|
<br />
|
|
<code><strong>$ openssl req -new -x509 -nodes -sha1 -days 365
|
|
-key server.key -out server.crt -extensions usr_cert</strong></code><br />
|
|
<br />
|
|
Cette commande signe le certificat du serveur et produit un fichier
|
|
<code>server.crt</code>. Vous pouvez afficher les détails de ce
|
|
certificat avec :<br />
|
|
<br />
|
|
<code><strong>$ openssl x509 -noout -text -in server.crt</strong></code><br />
|
|
<br />
|
|
</li>
|
|
</ol>
|
|
</section>
|
|
|
|
<section id="passphrase"><title>Comment modifier le mot de passe
|
|
de ma clé privée ?</title>
|
|
<p>Vous devez simplement lire la clé avec l'ancien mot de passe et la
|
|
réécrire en spécifiant le nouveau mot de passe. Pour cela, vous pouvez
|
|
utiliser les commandes suivantes :</p>
|
|
|
|
|
|
<p><code><strong>$ openssl rsa -des3 -in server.key -out server.key.new</strong></code><br />
|
|
<code><strong>$ mv server.key.new server.key</strong></code><br /></p>
|
|
|
|
<p>La première fois qu'il vous est demandé un mot de passe PEM, vous
|
|
devez entrer l'ancien mot de passe. Ensuite, on vous demandera d'entrer
|
|
encore un mot de passe - cette fois, entrez le nouveau mot de passe. Si on
|
|
vous demande de vérifier le mot de passe, vous devrez entrer le nouveau
|
|
mot de passe une seconde fois.</p>
|
|
</section>
|
|
|
|
<section id="removepassphrase"><title>Comment démarrer Apache sans avoir à entrer de
|
|
mot de passe ?</title>
|
|
<p>L'apparition de ce dialogue au démarrage et à chaque redémarrage provient
|
|
du fait que la clé privée RSA contenue dans votre fichier server.key est
|
|
enregistrée sous forme chiffrée pour des raisons de sécurité. Le
|
|
déchiffrement de ce fichier nécessite un mot de passe, afin de pouvoir être
|
|
lu et interprété. Cependant, La suppression du mot de passe diminue le niveau de
|
|
sécurité du serveur - agissez avec précautions !</p>
|
|
<ol>
|
|
<li>Supprimer le chiffrement de la clé privée RSA (tout en conservant une
|
|
copie de sauvegarde du fichier original) :<br />
|
|
<br />
|
|
<code><strong>$ cp server.key server.key.org</strong></code><br />
|
|
<code><strong>$ openssl rsa -in server.key.org -out server.key</strong></code><br />
|
|
|
|
<br />
|
|
</li>
|
|
<li>Assurez-vous que le fichier server.key n'est lisible que par root :<br />
|
|
<br />
|
|
<code><strong>$ chmod 400 server.key</strong></code><br />
|
|
<br />
|
|
</li>
|
|
</ol>
|
|
|
|
<p>Maintenant, <code>server.key</code> contient une copie non chiffrée de
|
|
la clé. Si vous utilisez ce fichier pour votre serveur, il ne vous
|
|
demandera plus de mot de passe. CEPENDANT, si quelqu'un arrive à obtenir
|
|
cette clé, il sera en mesure d'usurper votre identité sur le réseau.
|
|
Vous DEVEZ par conséquent vous assurer que seuls root ou le serveur web
|
|
peuvent lire ce fichier (de préférence, démarrez le serveur web sous
|
|
root et faites le s'exécuter sous un autre utilisateur, en n'autorisant
|
|
la lecture de la clé que par root).</p>
|
|
|
|
<p>Une autre alternative consiste à utiliser la directive
|
|
``<code>SSLPassPhraseDialog exec:/chemin/vers/programme</code>''. Gardez
|
|
cependant à l'esprit que ce n'est bien entendu ni plus ni moins
|
|
sécurisé.</p>
|
|
</section>
|
|
|
|
<section id="verify"><title>Comment vérifier si une clé privée correspond bien
|
|
à son certificat ?</title>
|
|
<p>Une clé privée contient une série de nombres. Deux de ces nombres forment la
|
|
"clé publique", les autres appartiennent à la "clé privée". Les bits de la
|
|
"clé publique" sont inclus quand vous générez une CSR, et font par
|
|
conséquent partie du certificat associé.</p>
|
|
<p>Pour vérifier que la clé publique contenue dans votre certificat
|
|
correspond bien à la partie publique de votre clé privée, il vous suffit
|
|
de comparer ces nombres. Pour afficher le certificat et la clé,
|
|
utilisez cette commande :</p>
|
|
|
|
<p><code><strong>$ openssl x509 -noout -text -in server.crt</strong></code><br />
|
|
<code><strong>$ openssl rsa -noout -text -in server.key</strong></code></p>
|
|
|
|
<p>Les parties `modulus' et `public exponent' doivent être identiques dans
|
|
la clé et le certificat. Comme le `public exponent' est habituellement
|
|
65537, et comme il est difficile de vérifier visuellement que les nombreux
|
|
nombres du `modulus' sont identiques, vous pouvez utiliser l'approche
|
|
suivante :</p>
|
|
|
|
<p><code><strong>$ openssl x509 -noout -modulus -in server.crt | openssl md5</strong></code><br />
|
|
<code><strong>$ openssl rsa -noout -modulus -in server.key | openssl md5</strong></code></p>
|
|
|
|
<p>Il ne vous reste ainsi que deux nombres relativement courts à comparer.
|
|
Il est possible, en théorie que ces deux nombres soient les mêmes, sans que
|
|
les nombres du modulus soient identiques, mais les chances en sont infimes.</p>
|
|
<p>Si vous souhaitez vérifier à quelle clé ou certificat appartient une CSR
|
|
particulière, vous pouvez effectuer le même calcul
|
|
sur la CSR comme suit :</p>
|
|
|
|
<p><code><strong>$ openssl req -noout -modulus -in server.csr | openssl md5</strong></code></p>
|
|
</section>
|
|
|
|
<section id="pemder"><title>Comment convertir un certificat du format PEM
|
|
au format DER ?</title>
|
|
<p>Le format des certificats par défaut pour OpenSSL est le format PEM,
|
|
qui est tout simplement un format DER codé en Base64, avec des lignes
|
|
d'en-têtes et des annotations. Certaines applications, comme
|
|
Microsoft Internet Explorer, ont besoin d'un certificat au format DER de base.
|
|
Vous pouvez convertir un fichier PEM <code>cert.pem</code> en son équivalent
|
|
au format DER <code>cert.der</code> à l'aide de la commande suivante :
|
|
<code><strong>$ openssl x509 -in cert.pem -out cert.der
|
|
-outform DER</strong></code></p>
|
|
</section>
|
|
|
|
<section id="gid"><title>Pourquoi les navigateurs se plaignent-ils de ne pas pouvoir
|
|
vérifier mon certificat de serveur ?</title>
|
|
|
|
<p>Ceci peut se produire si votre certificat de serveur est signé
|
|
par une autorité de certification intermédiaire. Plusieurs CAs,
|
|
comme Verisign ou Thawte, ont commencé à signer les certificats avec
|
|
des certificats intermédiaires au lieu de leur certificat racine.</p>
|
|
|
|
<p>Les certificats de CA intermédiaires se situe à un niveau
|
|
intermédiaire entre le certificat racine de la CA (qui est installé dans les
|
|
navigateurs) et le certificat du serveur (que vous avez installé sur
|
|
votre serveur). Pour que le navigateur puisse traverser et vérifier
|
|
la chaîne de confiance depuis le certificat du serveur jusqu'au
|
|
certificat racine, il faut lui fournir les certificats
|
|
intermédiaires. Les CAs devraient pouvoir fournir de tels
|
|
paquetages de certificats intermédiaires à installer sur les
|
|
serveurs.</p>
|
|
|
|
<p>Vous devez inclure ces certificats intermédiaires via la
|
|
directive <directive
|
|
module="mod_ssl">SSLCertificateChainFile</directive>.</p>
|
|
</section>
|
|
</section>
|
|
<!-- /certs -->
|
|
|
|
<section id="aboutssl"><title>Le protocole SSL</title>
|
|
<ul>
|
|
<li><a href="#random">Pourquoi de nombreuses et aléatoires erreurs de
|
|
protocole SSL apparaissent-elles en cas de forte charge du serveur ?</a></li>
|
|
<li><a href="#load">Pourquoi la charge de mon serveur est-elle plus
|
|
importante depuis qu'il sert des ressources chiffrées en SSL ?</a></li>
|
|
<li><a href="#establishing">Pourquoi les connexions en HTTPS à mon serveur
|
|
prennent-elles parfois jusqu'à 30 secondes pour s'établir ?</a></li>
|
|
<li><a href="#ciphers">Quels sont les algorithmes de chiffrement
|
|
supportés par mod_ssl ?</a></li>
|
|
<li><a href="#adh">Pourquoi une erreur ``no shared cipher'' apparaît-elle
|
|
quand j'essaie d'utiliser un algorithme de chiffrement
|
|
Diffie-Hellman anonyme (ADH) ?</a></li>
|
|
<li><a href="#sharedciphers">Pourquoi une erreur ``no shared cipher''
|
|
apparaît-elle lorsqu'on se connecte à mon serveur
|
|
fraîchement installé ?</a></li>
|
|
<li><a href="#vhosts">Pourquoi ne peut-on pas utiliser SSL avec des hôtes
|
|
virtuels identifiés par un nom et non par une adresse IP ?</a></li>
|
|
<li><a href="#vhosts2">Est-il possible d'utiliser
|
|
l'hébergement virtuel basé sur le nom d'hôte
|
|
pour différencier plusieurs hôtes virtuels ?</a></li>
|
|
<li><a href="#comp">Comment mettre en oeuvre la compression SSL ?</a></li>
|
|
<li><a href="#lockicon">Lorsque j'utilise l'authentification de base sur HTTPS,
|
|
l'icône de verrouillage des navigateurs Netscape reste ouverte quand la boîte
|
|
de dialogue d'authentification apparaît. Cela signifie-t-il que les utilisateur
|
|
et mot de passe sont envoyés en clair ?</a></li>
|
|
<li><a href="#msie">Pourquoi des erreurs d'entrée/sortie apparaissent-elles
|
|
lorsqu'on se connecte à un serveur Apache+mod_ssl avec
|
|
Microsoft Internet Explorer (MSIE) ?</a></li>
|
|
<li><a href="#srp">Comment activer TLS-SRP ?</a></li>
|
|
<li><a href="#javadh">Pourquoi des erreurs de négociation apparaissent
|
|
avec les clients basés sur Java lorsqu'on utilise un certificat de plus
|
|
de 1024 bits ?</a></li>
|
|
</ul>
|
|
|
|
<section id="random"><title>Pourquoi de nombreuses et aléatoires erreurs de
|
|
protocole SSL apparaissent-elles en cas de forte charge du serveur ?</title>
|
|
<p>Ce problème peut avoir plusieurs causes, mais la principale réside dans le
|
|
cache de session SSL défini par la directive
|
|
<directive module="mod_ssl">SSLSessionCache</directive>. Le cache de session
|
|
DBM est souvent à la source du problème qui peut être résolu en utilisant le
|
|
cache de session SHM (ou en n'utilisant tout simplement pas de cache).</p>
|
|
</section>
|
|
|
|
<section id="load"><title>Pourquoi la charge de mon serveur est-elle plus
|
|
importante depuis qu'il sert des ressources chiffrées en SSL ?</title>
|
|
<p>SSL utilise un procédé de chiffrement fort qui nécessite la manipulation
|
|
d'une quantité très importante de nombres. Lorsque vous effectuez une requête
|
|
pour une page web via HTTPS, tout (même les images) est chiffré avant d'être
|
|
transmis. C'est pourquoi un accroissement du traffic HTTPS entraîne une
|
|
augmentation de la charge.</p>
|
|
</section>
|
|
|
|
<section id="establishing"><title>Pourquoi les connexions en HTTPS à mon serveur
|
|
prennent-elles parfois jusqu'à 30 secondes pour s'établir ?</title>
|
|
<p>Ce problème provient en général d'un périphérique <code>/dev/random</code>
|
|
qui bloque l'appel système read(2) jusqu'à ce que suffisamment d'entropie
|
|
soit disponible pour servir la requête. Pour plus d'information, se référer au
|
|
manuel de référence de la directive
|
|
<directive module="mod_ssl">SSLRandomSeed</directive>.</p>
|
|
</section>
|
|
|
|
<section id="ciphers"><title>Quels sont les algorithmes de chiffrement
|
|
supportés par mod_ssl ?</title>
|
|
<p>En général, tous les algorithmes de chiffrement supportés par la version
|
|
d'OpenSSL installée, le sont aussi par <module>mod_ssl</module>. La liste des
|
|
algorithmes disponibles peut dépendre de la manière dont vous avez installé
|
|
OpenSSL. Typiquement, au moins les algorithmes suivants sont supportés :</p>
|
|
|
|
<ol>
|
|
<li>RC4 avec SHA1</li>
|
|
<li>AES avec SHA1</li>
|
|
<li>Triple-DES avec SHA1</li>
|
|
</ol>
|
|
|
|
<p>Pour déterminer la liste réelle des algorithmes disponibles, vous
|
|
pouvez utiliser la commande suivante :</p>
|
|
<example>$ openssl ciphers -v</example>
|
|
</section>
|
|
|
|
<section id="adh"><title>Pourquoi une erreur ``no shared cipher'' apparaît-elle
|
|
quand j'essaie d'utiliser un algorithme de chiffrement
|
|
Diffie-Hellman anonyme (ADH) ?</title>
|
|
<p>Par défaut et pour des raisons de sécurité, OpenSSl ne permet <em>pas</em>
|
|
l'utilisation des algorithmes de chiffrements ADH. Veuillez vous informer
|
|
sur les effets pervers potentiels si vous choisissez d'activer le support
|
|
de ces algorithmes de chiffrements.</p>
|
|
<p>Pour pouvoir utiliser les algorithmes de chiffrements Diffie-Hellman
|
|
anonymes (ADH), vous devez compiler OpenSSL avec
|
|
``<code>-DSSL_ALLOW_ADH</code>'', puis ajouter ``<code>ADH</code>'' à votre
|
|
directive <directive module="mod_ssl">SSLCipherSuite</directive>.</p>
|
|
</section>
|
|
|
|
<section id="sharedciphers"><title>Pourquoi une erreur ``no shared cipher''
|
|
apparaît-elle lorsqu'on se connecte à mon serveur
|
|
fraîchement installé ?</title>
|
|
<p>Soit vous avez fait une erreur en définissant votre directive
|
|
<directive module="mod_ssl">SSLCipherSuite</directive> (comparez-la avec
|
|
l'exemple préconfiguré dans <code>extra/httpd-ssl.conf</code>), soit vous avez
|
|
choisi d'utiliser des algorithmes DSA/DH au lieu de RSA lorsque vous avez
|
|
généré votre clé privée, et avez ignoré ou êtes passé outre les
|
|
avertissements. Si vous avez choisi DSA/DH, votre serveur est incapable de
|
|
communiquer en utilisant des algorithmes de chiffrements SSL basés sur RSA
|
|
(du moins tant que vous n'aurez pas configuré une paire clé/certificat RSA
|
|
additionnelle). Les navigateurs modernes tels que NS ou IE ne peuvent
|
|
communiquer par SSL qu'avec des algorithmes RSA. C'est ce qui provoque l'erreur
|
|
"no shared ciphers". Pour la corriger, générez une nouvelle paire
|
|
clé/certificat pour le serveur en utilisant un algorithme de chiffrement
|
|
RSA.</p>
|
|
</section>
|
|
|
|
<section id="vhosts"><title>Pourquoi ne peut-on pas utiliser SSL avec des hôtes
|
|
virtuels identifiés par un nom et non par une adresse IP ?</title>
|
|
<p>La raison est très technique, et s'apparente au problème de la primauté de
|
|
l'oeuf ou de la poule. La couche du protocole SSL se trouve en dessous de la
|
|
couche de protocole HTTP qu'elle encapsule. Lors de l'établissement d'une
|
|
connexion SSL (HTTPS), Apache/mod_ssl doit négocier les paramètres du
|
|
protocole SSL avec le client. Pour cela, mod_ssl doit consulter la
|
|
configuration du serveur virtuel (par exemple, il doit accéder à la suite
|
|
d'algorithmes de chiffrement, au certificat du serveur, etc...). Mais afin de
|
|
sélectionner le bon serveur virtuel, Apache doit connaître le contenu du champ
|
|
d'en-tête HTTP <code>Host</code>. Pour cela, il doit lire l'en-tête de la
|
|
requête HTTP. Mais il ne peut le faire tant que la négociation SSL n'est pas
|
|
terminée, or, la phase de négociation SSL a besoin du nom d'hôte contenu
|
|
dans l'en-tête de la requête. Voir la question suivante pour
|
|
contourner ce problème.</p>
|
|
|
|
<p>Notez que si votre certificat comporte un nom de serveur avec
|
|
caractères génériques, ou des noms de serveurs multiples dans le
|
|
champ subjectAltName, vous pouvez utiliser SSL avec les serveurs
|
|
virtuels à base de noms sans avoir à contourner ce problème.</p>
|
|
</section>
|
|
|
|
<section id="vhosts2"><title>Est-il possible d'utiliser
|
|
l'hébergement virtuel basé sur le nom d'hôte
|
|
pour différencier plusieurs hôtes virtuels ?</title>
|
|
<p>L'hébergement virtuel basé sur le nom est une méthode très populaire
|
|
d'identification des différents hôtes virtuels. Il permet d'utiliser la
|
|
même adresse IP et le même numéro de port pour de nombreux sites
|
|
différents. Lorsqu'on se tourne vers SSL, il semble tout naturel de penser
|
|
que l'on peut appliquer la même méthode pour gérer plusieurs hôtes
|
|
virtuels SSL sur le même serveur.</p>
|
|
|
|
<p>C'est possible, mais seulement si on utilise une version 2.2.12
|
|
ou supérieure du serveur web compilée avec OpenSSL
|
|
version 0.9.8j ou supérieure. Ceci est du au fait que
|
|
l'utilisation de l'hébergement virtuel à base de nom
|
|
avec SSL nécessite une fonctionnalité appelée
|
|
Indication du Nom de Serveur (Server Name Indication - SNI) que
|
|
seules les révisions les plus récentes de la
|
|
spécification SSL supportent.</p>
|
|
|
|
<p>Notez que si votre certificat comporte un nom de serveur avec
|
|
caractères génériques, ou des noms de serveurs multiples dans le
|
|
champ subjectAltName, vous pouvez utiliser SSL avec les serveurs
|
|
virtuels à base de noms sans avoir à contourner ce problème.</p>
|
|
|
|
<p>La raison en est que le protocole SSL constitue une couche séparée qui
|
|
encapsule le protocole HTTP. Aini, la session SSL nécessite une
|
|
transaction séparée qui prend place avant que la session HTTP n'ait débuté.
|
|
Le serveur reçoit une requête SSL sur l'adresse IP X et le port Y
|
|
(habituellement 443). Comme la requête SSL ne contenait aucun
|
|
en-tête Host:, le serveur n'avait aucun moyen de déterminer quel hôte virtuel SSL il
|
|
devait utiliser. En général, il utilisait le premier
|
|
qu'il trouvait et qui
|
|
correspondait à l'adresse IP et au port spécifiés.</p>
|
|
|
|
<p>Par contre, si vous utilisez des versions du serveur web et
|
|
d'OpenSSL qui supportent SNI, et si le navigateur du client le
|
|
supporte aussi, alors le nom d'hôte sera inclus dans la
|
|
requête SSL originale, et le serveur web pourra
|
|
sélectionner le bon serveur virtuel SSL.</p>
|
|
|
|
<p>Bien entendu, vous pouvez utiliser l'hébergement virtuel basé sur le nom
|
|
pour identifier de nombreux hôtes virtuels non-SSL
|
|
(tous sur le port 80 par exemple), et ne gérer qu'un seul hôte virtuel SSL
|
|
(sur le port 443). Mais dans ce cas, vous devez définir le numéro de port
|
|
non-SSL à l'aide de la directive NameVirtualHost dans ce style :</p>
|
|
|
|
<highlight language="config">
|
|
NameVirtualHost 192.168.1.1:80
|
|
</highlight>
|
|
|
|
<p>il existe d'autres solutions alternatives comme :</p>
|
|
|
|
<p>Utiliser des adresses IP différentes pour chaque hôte SSL.
|
|
Utiliser des numéros de port différents pour chaque hôte SSL.</p>
|
|
</section>
|
|
|
|
<section id="comp"><title>Comment mettre en oeuvre la compression SSL ?</title>
|
|
<p>Bien que la négociation pour la compression SSL ait été définie dans la
|
|
spécification de SSLv2 et TLS, ce n'est qu'en mai 2004 que la RFC 3749 a
|
|
défini DEFLATE comme une méthode de compression standard négociable.
|
|
</p>
|
|
<p>Depuis la version 0.9.8, OpenSSL supporte cette compression par défaut
|
|
lorsqu'il est compilé avec l'option <code>zlib</code>. Si le client et le
|
|
serveur supportent la compression, elle sera utilisée. Cependant, la
|
|
plupart des clients essaient encore de se connecter avec un Hello SSLv2.
|
|
Comme SSLv2 ne comportait pas de table des algorithmes de compression préférés
|
|
dans sa négociation, la compression ne peut pas être négociée avec ces clients.
|
|
Si le client désactive le support SSLv2, un Hello SSLv3 ou TLS peut être
|
|
envoyé, selon la bibliothèque SSL utilisée, et la compression peut être mise
|
|
en oeuvre. Vous pouvez vérifier si un client utilise la compression SSL en
|
|
journalisant la variable <code>%{SSL_COMPRESS_METHOD}x</code>.
|
|
</p>
|
|
</section>
|
|
|
|
<section id="lockicon"><title>Lorsque j'utilise l'authentification de base sur HTTPS,
|
|
l'icône de verrouillage des navigateurs Netscape reste ouverte quand la boîte
|
|
de dialogue d'authentification apparaît. Cela signifie-t-il que les utilisateur
|
|
et mot de passe sont envoyés en clair ?</title>
|
|
<p>Non, le couple utilisateur/mot de passe est transmis sous forme chiffrée.
|
|
L'icône de chiffrement dans les navigateurs Netscape n'est pas vraiment
|
|
synchronisé avec la couche SSL/TLS. Il ne passe à l'état verrouillé
|
|
qu'au moment où la première partie des données relatives à la page web
|
|
proprement dite sont transférées, ce qui peut prêter à confusion. Le
|
|
dispositif d'authentification de base appartient à la couche HTTP, qui
|
|
est située au dessus de la couche SSL/TLS dans HTTPS. Avant tout
|
|
transfert de données HTTP sous HTTPS, la couche SSL/TLS a déjà achevé
|
|
sa phase de négociation et basculé dans le mode de communication
|
|
chiffrée. Ne vous laissez donc pas abuser par l'état de cet icône.</p>
|
|
</section>
|
|
|
|
<section id="msie"><title>Pourquoi des erreurs d'entrée/sortie apparaissent-elles
|
|
lorsqu'on se connecte via HTTPS à un serveur Apache+mod_ssl avec des
|
|
versions anciennes de
|
|
Microsoft Internet Explorer (MSIE) ?</title>
|
|
<p>La première raison en est la présence dans l'implémentation SSL de
|
|
certaines versions de MSIE de bogues subtils en rapport avec le
|
|
dispositif de "maintien en vie" (keep-alive) HTTP, et les alertes de
|
|
notification de fermeture de session SSL en cas de coupure de la
|
|
connexion au point d'entrée (socket). De plus, l'interaction entre
|
|
SSL et les fonctionnalités HTTP/1.1 pose problème avec certaines
|
|
versions de MSIE. Vous pouvez contourner ces problèmes en interdisant
|
|
à Apache l'utilisation de HTTP/1.1, les connexions avec maintien en vie
|
|
ou l'envoi de messages de notification de fermeture de session SSL aux
|
|
clients MSIE. Pour cela, vous pouvez utiliser la directive suivante
|
|
dans votre section d'hôte virtuel avec support SSL :</p>
|
|
<highlight language="config">
|
|
SetEnvIf User-Agent "MSIE [2-5]" \
|
|
nokeepalive ssl-unclean-shutdown \
|
|
downgrade-1.0 force-response-1.0
|
|
</highlight>
|
|
<p>En outre, certaines versions de MSIE ont des problèmes avec des
|
|
algorithmes de chiffrement particuliers. Hélas, il n'est pas
|
|
possible d'apporter une solution spécifique à MSIE pour ces
|
|
problèmes, car les algorithmes de chiffrement sont utilisés dès la
|
|
phase de négociation SSL. Ainsi, une directive
|
|
<directive module="mod_setenvif">SetEnvIf</directive> spécifique
|
|
à MSIE ne peut être d'aucun secours. Par contre, vous devrez
|
|
ajuster les paramètres généraux de manière drastique. Avant de
|
|
vous décider, soyez sûr que vos clients rencontrent vraiment des
|
|
problèmes. Dans la négative, n'effectuez pas ces ajustements car
|
|
ils affecteront <em>tous</em> vos clients, ceux utilisant MSIE,
|
|
mais aussi les autres.</p>
|
|
|
|
</section>
|
|
|
|
<section id="srp"><title>Comment activer TLS-SRP ?</title>
|
|
<p>TLS-SRP (Echange de clés avec mot de passe distant sécurisé,
|
|
défini dans la RFC 5054) peut compléter ou même remplacer les
|
|
certificats au cours de l'authentification d'une connexion SSL. Pour
|
|
utiliser TLS-SRP, affectez à la directive <directive
|
|
module="mod_ssl">SSLSRPVerifierFile</directive> un fichier de
|
|
vérification OpenSSL SRP. Pour créer ce fichier de vérification,
|
|
utilisez l'outil <code>openssl</code> :</p>
|
|
<example>
|
|
openssl srp -srpvfile passwd.srpv -add username
|
|
</example>
|
|
<p>Une fois ce fichier créé, spécifiez-le dans la configuration SSL
|
|
du serveur :</p>
|
|
<example>
|
|
SSLSRPVerifierFile /path/to/passwd.srpv
|
|
</example>
|
|
<p>Pour forcer les clients à utiliser des algorithmes de chiffrement
|
|
non basés sur les certificats, utilisez la directive suivante :</p>
|
|
<example>
|
|
SSLCipherSuite "!DSS:!aRSA:SRP"
|
|
</example>
|
|
</section>
|
|
|
|
<section id="javadh"><title>Pourquoi des erreurs de négociation apparaissent
|
|
avec les clients basés sur Java lorsqu'on utilise un certificat de plus
|
|
de 1024 bits ?</title>
|
|
<p>Depuis la version 2.5.0-dev et à/c du 29/09/2013,
|
|
<module>mod_ssl</module> utilise des paramètres DH qui comportent
|
|
des nombres premiers de plus de 1024 bits. Cependant, java 7 et ses versions
|
|
antérieures ne supportent que les nombres premiers DH d'une longueur
|
|
maximale de 1024 bits.</p>
|
|
|
|
<p>Si votre client basé sur Java s'arrête avec une exception telle
|
|
que <code>java.lang.RuntimeException: Could not generate DH
|
|
keypair</code> et
|
|
<code>java.security.InvalidAlgorithmParameterException: Prime size
|
|
must be multiple of 64, and can only range from 512 to 1024
|
|
(inclusive)</code>, et si httpd enregistre le message <code>tlsv1
|
|
alert internal error (SSL alert number 80)</code> dans son journal
|
|
des erreurs (avec un <directive module="core">LogLevel</directive>
|
|
<code>info</code> ou supérieur), vous pouvez soit réarranger la
|
|
liste d'algorithmes de mod_ssl via la directive <directive
|
|
module="mod_ssl">SSLCipherSuite</directive> (éventuellement en
|
|
conjonction avec la directive <directive
|
|
module="mod_ssl">SSLHonorCipherOrder</directive>), soit utiliser des
|
|
paramètres DH personnalisés avec un nombre
|
|
premier de 1024 bits, paramètres qui seront toujours prioritaires
|
|
par rapport à tout autre paramètre DH par défaut.</p>
|
|
|
|
<p>Pour générer des paramètres DH personnalisés, utilisez la
|
|
commande <code>openssl dhparam 1024</code>. Vous pouvez aussi
|
|
utiliser les paramètres DH standards issus de la <a
|
|
href="http://www.ietf.org/rfc/rfc2409.txt">RFC 2409</a>, section 6.2 :</p>
|
|
<example><pre>-----BEGIN DH PARAMETERS-----
|
|
MIGHAoGBAP//////////yQ/aoiFowjTExmKLgNwc0SkCTgiKZ8x0Agu+pjsTmyJR
|
|
Sgh5jjQE3e+VGbPNOkMbMCsKbfJfFDdP4TVtbVHCReSFtXZiXn7G9ExC6aY37WsL
|
|
/1y29Aa37e44a/taiZ+lrp8kEXxLH+ZJKGZR7OZTgf//////////AgEC
|
|
-----END DH PARAMETERS-----</pre></example>
|
|
<p>Ajoute les paramètres personnalisés incluant les lignes "BEGIN DH
|
|
PARAMETERS" et "END DH PARAMETERS" à la fin du premier fichier de
|
|
certificat défini via la directive <directive
|
|
module="mod_ssl">SSLCertificateFile</directive>.</p>
|
|
</section>
|
|
|
|
|
|
</section>
|
|
<!-- /aboutssl -->
|
|
|
|
<section id="support"><title>Support de mod_ssl</title>
|
|
<ul>
|
|
<li><a href="#resources">Quelles sont les sources d'informations
|
|
disponibles en cas de problème avec mod_ssl ?</a></li>
|
|
<li><a href="#contact">Qui peut-on contacter pour un support en cas de
|
|
problème avec mod_ssl ?</a></li>
|
|
<li><a href="#reportdetails">Quelles informations dois-je fournir lors
|
|
de l'écriture d'un rapport de bogue ?</a></li>
|
|
<li><a href="#coredumphelp">Un vidage mémoire s'est produit,
|
|
pouvez-vous m'aider ?</a></li>
|
|
<li><a href="#backtrace">Comment puis-je obtenir une journalisation de
|
|
ce qui s'est passé, pour m'aider à trouver la raison de ce vidage
|
|
mémoire ?</a></li>
|
|
</ul>
|
|
|
|
<section id="resources"><title>Quelles sont les sources d'informations
|
|
disponibles en cas de problème avec mod_ssl ?</title>
|
|
<p>Voici les sources d'informations disponibles ; vous devez chercher
|
|
ici en cas de problème.</p>
|
|
|
|
<dl>
|
|
<dt>Vous trouverez des réponses dans la Foire Aux Questions du
|
|
manuel utilisateur (ce document)</dt>
|
|
<dd><a href="http://httpd.apache.org/docs/&httpd.docs;/ssl/ssl_faq.html">
|
|
http://httpd.apache.org/docs/&httpd.docs;/ssl/ssl_faq.html</a><br />
|
|
Cherchez tout d'abord dans la foire aux questions
|
|
(ce document). Si votre question est courante, on a déjà dû y
|
|
répondre de nombreuses fois, et elle fait probablement partie
|
|
de ce document.
|
|
</dd>
|
|
</dl>
|
|
</section>
|
|
|
|
<section id="contact"><title>Qui peut-on contacter pour un support en cas de
|
|
problème avec mod_ssl ?</title>
|
|
<p>Voici toutes les possibilités de support pour mod_ssl, par ordre
|
|
de préférence. Merci d'utiliser ces possibilités
|
|
<em>dans cet ordre</em> - ne vous précipitez pas sur celle qui vous
|
|
paraît la plus alléchante. </p>
|
|
<ol>
|
|
<li><em>Envoyez un rapport de problème à la liste de diffusion de
|
|
support des utilisateurs d'Apache httpd</em><br />
|
|
<a href="mailto:users@httpd.apache.org">
|
|
users@httpd.apache.org</a><br />
|
|
C'est la deuxième manière de soumettre votre rapport de
|
|
problème. Ici aussi, vous devez d'abord vous abonner à la
|
|
liste, mais vous pourrez ensuite discuter facilement de votre
|
|
problème avec l'ensemble de la communauté d'utilisateurs
|
|
d'Apache httpd.
|
|
</li>
|
|
|
|
<li><em>Ecrire un rapport de problème dans la base de données des
|
|
bogues</em><br />
|
|
<a href="http://httpd.apache.org/bug_report.html">
|
|
http://httpd.apache.org/bug_report.html</a><br />
|
|
C'est la dernière manière de soumettre votre rapport de
|
|
problème. Vous ne devez utiliser cette solution que si vous
|
|
avez déjà écrit aux listes de diffusion, et n'avez pas trouvé
|
|
de solution. Merci de suivre les instructions de la page
|
|
mentionnée ci-dessus <em>avec soin</em>.
|
|
</li>
|
|
</ol>
|
|
</section>
|
|
|
|
<section id="reportdetails"><title>Quelles informations dois-je fournir lors
|
|
de l'écriture d'un rapport de bogue ?</title>
|
|
<p>Vous devez toujours fournir au moins les informations
|
|
suivantes :</p>
|
|
|
|
<dl>
|
|
<dt>Les versions d'Apache httpd et OpenSSL installées</dt>
|
|
<dd>La version d'Apache peut être déterminée en exécutant
|
|
<code>httpd -v</code>. La version d'OpenSSL peut être déterminée
|
|
en exécutant <code>openssl version</code>. Si Lynx est installé,
|
|
vous pouvez aussi exécuter la commande<code>lynx -mime_header
|
|
http://localhost/ | grep Server</code> et ainsi obtenir ces
|
|
informations en une seule fois.
|
|
</dd>
|
|
|
|
<dt>Les détails de votre installation d'Apache httpd et OpenSSL</dt>
|
|
<dd>A cet effet, vous pouvez fournir un fichier journal de votre
|
|
session de terminal qui montre les étapes de la configuration et
|
|
de l'installation. En cas d'impossibilité, vous devez au moins
|
|
fournir la ligne de commande <program>configure</program> que
|
|
vous avez utilisée.
|
|
</dd>
|
|
|
|
<dt>En cas de vidage mémoire, inclure une trace de ce qui s'est
|
|
passé</dt>
|
|
<dd>Si votre serveur Apache httpd fait un vidage de sa
|
|
mémoire, merci de fournir en pièce jointe un fichier contenant
|
|
une trace de la zone dédiée à la pile (voir
|
|
<a href="#backtrace">ci-dessous</a> pour des informations sur la manière
|
|
de l'obtenir). Il est nécessaire de disposer de ces informations
|
|
afin de pouvoir déterminer la raison de votre vidage mémoire.
|
|
</dd>
|
|
|
|
<dt>Une description détaillée de votre problème</dt>
|
|
|
|
<dd>Ne riez pas, nous sommes sérieux ! De nombreux rapports
|
|
n'incluent pas de description de la véritable nature du problème.
|
|
Sans ces informations, il est très difficile pour quiconque de
|
|
vous aider. Donc, et c'est votre propre intérêt (vous souhaitez
|
|
que le problème soit résolu, n'est-ce pas ?), fournissez, s'il vous
|
|
plait, le maximum de détails possible. Bien entendu, vous devez
|
|
aussi inclure tout ce qui a été dit précédemment.
|
|
</dd>
|
|
</dl>
|
|
</section>
|
|
|
|
<section id="coredumphelp"><title>Un vidage mémoire s'est produit,
|
|
pouvez-vous m'aider ?</title>
|
|
<p>En général non, du moins tant que vous n'aurez pas fourni plus de
|
|
détails à propos de la localisation dans le code où Apache a effectué
|
|
son vidage mémoire. Ce dont nous avons en général besoin pour vous
|
|
aider est une trace de ce qui s'est passé (voir la question suivante).
|
|
Sans cette information, il est pratiquement impossible de déterminer
|
|
la nature du problème et de vous aider à le résoudre.</p>
|
|
</section>
|
|
|
|
<section id="backtrace"><title>Comment puis-je obtenir une journalisation de
|
|
ce qui s'est passé, pour m'aider à trouver la raison de ce vidage
|
|
mémoire ?</title>
|
|
<p>Vous trouverez ci-dessous les différentes étapes permettant
|
|
d'obtenir une journalisation des évènements (backtrace) :</p>
|
|
<ol>
|
|
<li>Assurez-vous que les symboles de débogage sont disponibles, au
|
|
moins pour Apache. Pour cela, sur les plates-formes où GCC/GDB est
|
|
utilisé, vous devez compiler Apache+mod_ssl avec l'option
|
|
``<code>OPTIM="-g -ggdb3"</code>''. Sur les autres plates-formes,
|
|
l'option ``<code>OPTIM="-g"</code>'' est un minimum.
|
|
</li>
|
|
|
|
<li>Démarrez le serveur et essayez de reproduire le vidage mémoire.
|
|
A cet effet, vous pouvez utiliser une directive du style
|
|
``<code>CoreDumpDirectory /tmp</code>'' pour être sûr que le
|
|
fichier de vidage mémoire puisse bien être écrit. Vous devriez
|
|
obtenir un fichier <code>/tmp/core</code> ou
|
|
<code>/tmp/httpd.core</code>. Si ce n'est pas le cas, essayez de
|
|
lancer votre serveur sous un UID autre que root.
|
|
Pour des raisons de sécurité, de nombreux
|
|
noyaux modernes de permettent pas à un processus de vider sa
|
|
mémoire une fois qu'il a accompli un <code>setuid()</code> (à moins
|
|
qu'il effectue un <code>exec()</code>) car des informations d'un
|
|
niveau privilégié pourraient être transmises en mémoire. Si
|
|
nécessaire, vous pouvez exécuter <code>/chemin/vers/httpd -X</code>
|
|
manuellement afin de ne pas permettre à Apache de se clôner (fork).
|
|
</li>
|
|
|
|
<li>Analysez le vidage mémoire. Pour cela, exécutez
|
|
<code>gdb /path/to/httpd /tmp/httpd.core</code> ou une commande
|
|
similaire. Dans GDB, tout ce que vous avez à faire est d'entrer
|
|
<code>bt</code>, et voila, vous obtenez la backtrace. Pour les
|
|
débogueurs autres que GDB consulter le manuel correspondant.
|
|
</li>
|
|
</ol>
|
|
</section>
|
|
</section>
|
|
</manualpage>
|