Serveur Apache HTTP Version 2.4
Serveur Apache HTTP Version 2.4
Le sage n'apporte pas de bonnes r�ponses, il pose les bonnes questions
-- Claude Levi-Strauss
Des erreurs telles que ``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)''
sont souvent provoqu�es par des permissions trop restrictives sur les
r�pertoires parents. Assurez-vous que tous les r�pertoires
parents (ici /opt, /opt/apache et
/opt/apache/logs) ont le bit x positionn� au moins pour
l'UID sous lequel les processus enfants d'Apache s'ex�cutent (voir la
directive User).
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
/dev/random). 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.
Pour �viter cette erreur, mod_ssl doit fournir
suffisamment d'entropie au PRNG pour lui permettre de fonctionner
correctement. Ce niveau d'entropie est d�fini par la directive
SSLRandomSeed.
SSL_XXX
ne sont-elles pas disponibles dans mes scripts CGI et SSI ?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.
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 https://example.com:8080/.
Alors que vous utilisez simplement
$ telnet localhost 80
GET / HTTP/1.0
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 s_client vous permet cependant
d'effectuer un test similaire via HTTPS :
$ openssl s_client -connect localhost:443 -state -debug
GET / HTTP/1.0
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 cURL. Gr�ce � lui, vous pouvez v�rifier si Apache r�pond correctement aux requ�tes via HTTP et HTTPS comme suit :
$ curl http://localhost/
$ curl https://localhost/
Ceci peut arriver si vous vous connectez � un serveur HTTPS (ou �
un serveur virtuel) via HTTP (par exemple, en utilisant
http://example.com/ au lieu de https://example.com).
Cela peut aussi arriver en essayant de vous connecter via HTTPS � un
serveur HTTP (par exemple, en utilisant https://example.com/
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.
Une configuration incorrecte peut provoquer ce type d'erreur.
Assurez-vous que vos directives Listen s'accordent avec vos directives
<VirtualHost>. Si
l'erreur persiste, recommencez depuis le d�but en restaurant la
configuration par d�faut fournie parmod_ssl.
SSL_XXX
ne sont-elles pas disponibles dans mes scripts CGI et SSI ?Assurez-vous que la directive ``SSLOptions +StdEnvVars'' est
bien pr�sente dans le contexte de vos requ�tes CGI/SSI.
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 mod_rewrite, vous pouvez
manipuler des hyperliens relatifs, pour obtenir le m�me effet.
RewriteEngine on
RewriteRule ^/(.*)_SSL$ https://%{SERVER_NAME}/$1 [R,L]
RewriteRule ^/(.*)_NOSSL$ http://%{SERVER_NAME}/$1 [R,L]
Ce jeu de r�gles rewrite vous permet d'utiliser des hyperliens de la
forme <a href="document.html_SSL"> pour passer en HTTPS
dans les liens relatifs. (Remplacez SSL par NOSSL pour passer en HTTP.)
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.
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.
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.
Se r�f�rer au chapitre Introduction pour une description g�n�rale du protocole SSL.
Oui. En g�n�ral, avec ou sans mod_ssl 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.
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 ci-dessous 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 !
PATH.server.key et server.crt :$ openssl req -new -x509 -nodes -out server.crt
-keyout server.keyapache2.conf :
SSLCertificateFile /path/to/this/server.crt SSLCertificateKeyFile /path/to/this/server.key
server.key n'a
pas 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�.$ openssl rsa -des3 -in server.key -out
server.key.new
$ mv server.key.new server.key
server.key ainsi que son mot de
passe en lieu s�r.
Voici la marche � suivre pas � pas :
PATH.
$ openssl genrsa -des3 -out server.key 2048server.key 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 :$ openssl rsa -noout -text -in server.key$ openssl rsa -in server.key -out server.key.unsecure$ openssl req -new -key server.key -out server.csrhttps://www.foo.dom/, le FQDN sera "www.foo.dom". Vous
pouvez afficher les d�tails de ce CSR avec :$ openssl req -noout -text -in server.csr$ openssl x509 -noout -text -in server.crtserver.key et server.crt. Ils sont pr�cis�s dans
votre fichier apache2.conf comme suit :
SSLCertificateFile /path/to/this/server.crt SSLCertificateKeyFile /path/to/this/server.keyLe fichier
server.csr n'est plus n�cessaire.
La solution la plus simple consiste � utiliser les scripts
CA.sh ou CA.pl 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 :
$ openssl genrsa -des3 -out server.key 2048server.key 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 :$ openssl rsa -noout -text -in server.key$ openssl rsa -in server.key -out server.key.unsecure$ openssl req -new -x509 -nodes -sha1 -days 365
-key server.key -out server.crtserver.crt. Vous pouvez afficher les d�tails de ce
certificat avec :$ openssl x509 -noout -text -in server.crtVous 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 :
$ openssl rsa -des3 -in server.key -out server.key.new
$ mv server.key.new server.key
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.
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 !
$ cp server.key server.key.org$ openssl rsa -in server.key.org -out server.key$ chmod 400 server.keyMaintenant, server.key 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).
Une autre alternative consiste � utiliser la directive
``SSLPassPhraseDialog exec:/chemin/vers/programme''. Gardez
cependant � l'esprit que ce n'est bien entendu ni plus ni moins
s�curis�.
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�.
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 :
$ openssl x509 -noout -text -in server.crt
$ openssl rsa -noout -text -in server.key
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 :
$ openssl x509 -noout -modulus -in server.crt | openssl md5
$ openssl rsa -noout -modulus -in server.key | openssl md5
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.
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 :
$ openssl req -noout -modulus -in server.csr | openssl md5
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 cert.pem en son �quivalent
au format DER cert.der � l'aide de la commande suivante :
$ openssl x509 -in cert.pem -out cert.der
-outform DER
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.
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.
Vous devez inclure ces certificats interm�diaires via la
directive SSLCertificateChainFile.
Ce probl�me peut avoir plusieurs causes, mais la principale r�side dans le
cache de session SSL d�fini par la directive
SSLSessionCache. 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).
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.
Ce probl�me provient en g�n�ral d'un p�riph�rique /dev/random
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
SSLRandomSeed.
En g�n�ral, tous les algorithmes de chiffrement support�s par la version
d'OpenSSL install�e, le sont aussi par mod_ssl. 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 :
Pour d�terminer la liste r�elle des algorithmes disponibles, vous pouvez utiliser la commande suivante :
$ openssl ciphers -v
Par d�faut et pour des raisons de s�curit�, OpenSSl ne permet pas 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.
Pour pouvoir utiliser les algorithmes de chiffrements Diffie-Hellman
anonymes (ADH), vous devez compiler OpenSSL avec
``-DSSL_ALLOW_ADH'', puis ajouter ``ADH'' � votre
directive SSLCipherSuite.
Soit vous avez fait une erreur en d�finissant votre directive
SSLCipherSuite (comparez-la avec
l'exemple pr�configur� dans extra/httpd-ssl.conf), 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.
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 Host. 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.
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.
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.
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.
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.
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.
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.
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 :
NameVirtualHost 192.168.1.1:80
il existe d'autres solutions alternatives comme :
Utiliser des adresses IP diff�rentes pour chaque h�te SSL. Utiliser des num�ros de port diff�rents pour chaque h�te SSL.
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.
Depuis la version 0.9.8, OpenSSL supporte cette compression par d�faut
lorsqu'il est compil� avec l'option zlib. 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 %{SSL_COMPRESS_METHOD}x.
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.
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 :
SetEnvIf User-Agent "MSIE [2-5]" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
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
SetEnvIf 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 tous vos clients, ceux utilisant MSIE,
mais aussi les autres.
Le protocole TLS-SRP (Echange de clés sécurisé par mot de passe
pour TLS comme spécifié dans la RFC 5054) peut compléter ou même
remplacer les certificats lors du processus d'authentification des
connexions SSL. Pour utiliser TLS-SRP, spécifiez un fichier de
vérification SRP OpenSSL via la directive SSLSRPVerifierFile. Vous pouvez créer
le fichier de vérification via l'utilitaire openssl :
openssl srp -srpvfile passwd.srpv -add username
Une fois ce fichier créé, vous devez le référencer dans la configuration du serveur SSL :
SSLSRPVerifierFile /path/to/passwd.srpv
Pour forcer les clients � utiliser des algorithmes de chiffrement basés sur TLS-SRP et s'affranchissant des certificats, utilisez la directive suivante :
SSLCipherSuite "!DSS:!aRSA:SRP"
Depuis la version 2.4.7,
mod_ssl 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.
Si votre client bas� sur Java s'arr�te avec une exception telle
que java.lang.RuntimeException: Could not generate DH
keypair et
java.security.InvalidAlgorithmParameterException: Prime size
must be multiple of 64, and can only range from 512 to 1024
(inclusive), et si httpd enregistre le message tlsv1
alert internal error (SSL alert number 80) dans son journal
des erreurs (avec un LogLevel
info ou sup�rieur), vous pouvez soit r�arranger la
liste d'algorithmes de mod_ssl via la directive SSLCipherSuite (�ventuellement en
conjonction avec la directive SSLHonorCipherOrder), soit utiliser la
directive SSLCertificateFile
pour configurer 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.
Pour g�n�rer des param�tres DH personnalis�s, utilisez la
commande openssl dhparam. Vous pouvez aussi ajouter les
param�tres DH standards issus de la RFC 2409, section 6.2
au fichier SSLCertificateFile
consid�r� :
-----BEGIN DH PARAMETERS----- MIGHAoGBAP//////////yQ/aoiFowjTExmKLgNwc0SkCTgiKZ8x0Agu+pjsTmyJR Sgh5jjQE3e+VGbPNOkMbMCsKbfJfFDdP4TVtbVHCReSFtXZiXn7G9ExC6aY37WsL /1y29Aa37e44a/taiZ+lrp8kEXxLH+ZJKGZR7OZTgf//////////AgEC -----END DH PARAMETERS-----
Voici les sources d'informations disponibles ; vous devez chercher ici en cas de probl�me.
Voici toutes les possibilit�s de support pour mod_ssl, par ordre de pr�f�rence. Merci d'utiliser ces possibilit�s dans cet ordre - ne vous pr�cipitez pas sur celle qui vous para�t la plus all�chante.
Vous devez toujours fournir au moins les informations suivantes :
httpd -v. La version d'OpenSSL peut �tre d�termin�e
en ex�cutant openssl version. Si Lynx est install�,
vous pouvez aussi ex�cuter la commandelynx -mime_header
http://localhost/ | grep Server et ainsi obtenir ces
informations en une seule fois.
configure que
vous avez utilis�e.
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.
Vous trouverez ci-dessous les diff�rentes �tapes permettant d'obtenir une journalisation des �v�nements (backtrace) :
OPTIM="-g -ggdb3"''. Sur les autres plates-formes,
l'option ``OPTIM="-g"'' est un minimum.
CoreDumpDirectory /tmp'' pour �tre s�r que le
fichier de vidage m�moire puisse bien �tre �crit. Vous devriez
obtenir un fichier /tmp/core ou
/tmp/httpd.core. 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 setuid() (� moins
qu'il effectue un exec()) car des informations d'un
niveau privil�gi� pourraient �tre transmises en m�moire. Si
n�cessaire, vous pouvez ex�cuter /chemin/vers/httpd -X
manuellement afin de ne pas permettre � Apache de se cl�ner (fork).
gdb /path/to/httpd /tmp/httpd.core ou une commande
similaire. Dans GDB, tout ce que vous avez � faire est d'entrer
bt, et voila, vous obtenez la backtrace. Pour les
d�bogueurs autres que GDB consulter le manuel correspondant.