1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
|
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="fr" xml:lang="fr"><head><!--
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
This file is generated from xml source: DO NOT EDIT
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
-->
<title>Chiffrement SSL/TLS fort: foire aux questions - Serveur Apache HTTP</title>
<link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
<link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" />
<link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" />
<link href="../images/favicon.ico" rel="shortcut icon" /></head>
<body id="manual-page"><div id="page-header">
<p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossaire</a> | <a href="../sitemap.html">Plan du site</a></p>
<p class="apache">Serveur Apache HTTP Version 2.3</p>
<img alt="" src="../images/feather.gif" /></div>
<div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div>
<div id="path">
<a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">Serveur HTTP</a> > <a href="http://httpd.apache.org/docs/">Documentation</a> > <a href="../">Version 2.3</a> > <a href="./">SSL/TLS</a></div><div id="page-content"><div id="preamble"><h1>Chiffrement SSL/TLS fort: foire aux questions</h1>
<div class="toplang">
<p><span>Langues Disponibles: </span><a href="../en/ssl/ssl_faq.html" hreflang="en" rel="alternate" title="English"> en </a> |
<a href="../fr/ssl/ssl_faq.html" title="Français"> fr </a></p>
</div>
<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>
<p>Ce chapitre propose une Foire Aux Questions (FAQ) et les réponses
correspondantes selon la tradition populaire USENET. La plupart des questions
ont été posés dans le Newsgroup
<code><a href="news:comp.infosystems.www.servers.unix">comp.infosystems.www.servers.unix</a></code> ou dans la liste de diffusion du
support mod_ssl <code><a href="mailto:modssl-users@modssl.org">modssl-users@modssl.org</a></code>. Elles ont été rassemblées ici afin
de ne pas avoir à répondre encore et encore aux mêmes questions.</p>
<p>Vous êtes prié de lire ce chapitre au moins une fois avant d'installer
mod_ssl, ou d'y rechercher la solution à votre problème avant de le soumettre
à l'auteur.</p>
</div>
<div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#about">A propos de mod_ssl</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#installation">Installation</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#aboutconfig">Configuration</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#aboutcerts">Certificats</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#aboutssl">Le protocole SSL</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#support">Support de mod_ssl</a></li>
</ul></div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="about" id="about">A propos de mod_ssl</a></h2>
<ul>
<li><a href="#history">Quel est l'historique de mod_ssl ?</a></li>
<li><a href="#wassenaar">mod_ssl et l'arrangement Wassenaar</a></li>
</ul>
<h3><a name="history" id="history">Quel est l'historique de mod_ssl ?</a></h3>
<p>Le paquet mod_ssl version 1 a été créé en avril 1998 par <a href="mailto:rse@engelschall.com">Ralf S. Engelschall</a> par portage des
patches sources 1.17 du module <a href="http://www.apache-ssl.org/">Apache-SSL</a> de <a href="mailto:ben@algroup.co.uk">Ben Laurie</a> pour Apache 1.2.6 vers
Apache 1.3b6. Il fut ensuite entièrement réassemblé pour Apache 1.3.0 en
fusionnant l'ancien mod_ssl 1.x avec le nouveau Apache-SSL 1.18 pour cause
de conflits avec le cycle de développement du module de Ben Laurie. Depuis
lors, mod_ssl vole de ses propres ailes sous le nom de mod_ssl v2. La
première version distribuée au public fut mod_ssl 2.0.0 à partir du
10 août 1998. </p>
<p>Quand les restrictions à l'exportation des US sur les logiciels de
cryptographie furent assouplis, <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> devint partie
intégrante du serveur HTTP Apache à partir de la distribution de
Apache httpd 2.</p>
<h3><a name="wassenaar" id="wassenaar">mod_ssl est-il concerné par
l'arrangement Wassenaar ?</a></h3>
<p>Tout d'abord, examinons en quoi consiste <dfn>Wassenaar</dfn> et son
<dfn>Arrangement sur le contrôle de l'exportation des armes conventionnelles
et le double usage des biens et des technologies</dfn> : c'est un
règlement international, établi en 1995, qui contrôle le commerce des armes
conventionnelles et le double usage des biens et des technologies. Il
remplace le règlement précédent <dfn>CoCom</dfn>. Pour plus de détails sur
l'arrangement et ses signataires, se référer à <a href="http://www.wassenaar.org/">http://www.wassenaar.org/</a>.</p>
<p>En bref, l'Arrangement Wassenaar a pour but d'empêcher la constitution
de puissances militaires qui pourraient menacer la sécurité et la
stabilité régionales et internationales. L'Arrangement Wassenaar contrôle
l'exportation de logiciels de cryptographie comme biens à double usage,
c'est à dire ayant des applications à la fois militaires et civiles.
Cependant, l'Arrangement Wassenaar exempte les logiciels grand public et
les logiciels libres du contrôle à l'exportation.</p>
<p>Dans l'actuelle <cite>List of Dual Use Goods and Technologies And
Munitions</cite>, sous <q>GENERAL SOFTWARE NOTE (GSN)</q>, il est écrit
<q>La liste ne prend pas en compte les "logiciels" qui sont soit :
1. [...] 2. "dans le domaine public".</q> Et sous
<q>DEFINITIONS OF TERMS USED IN THESE LISTS</q>, <q>In the public
domain</q> est défini comme <q>"technologie" ou "logiciel" qui a été
fourni sans restrictions à propos de sa redistribution ultérieure. Note:
les restrictions de Copyright ne privent pas la "technologie" ou le
"logiciel" de leur appartenance au "domaine public".</q></p>
<p>Ainsi, selon l'Arrangement Wassenaar et sa <q>List of Dual Use Goods and
Technologies And Munitions List</q>, mod_ssl et OpenSSL appartiennent au
<q>domaine public</q>, et ne sont donc pas concernés
par les dispositions de l'arrangement.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="installation" id="installation">Installation</a></h2>
<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>
<h3><a name="mutex" id="mutex">Pourquoi le démarrage d'Apache provoque-t-il des
erreurs de permission en rapport avec SSLMutex ?</a></h3>
<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 <code class="directive"><a href="../mod/mpm_common.html#user">User</a></code>).</p>
<h3><a name="entropy" id="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></h3>
<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, <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> doit fournir
suffisamment d'entropie au PRNG pour lui permettre de fonctionner
correctement. Ce niveau d'entropie est défini par la directive
<code class="directive"><a href="../mod/mod_ssl.html#sslrandomseed">SSLRandomSeed</a></code>.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="aboutconfig" id="aboutconfig">Configuration</a></h2>
<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>
<h3><a name="parallel" id="parallel">Peut-on faire cohabiter HTTP et HTTPS sur le même
serveur ?</a></h3>
<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>
<h3><a name="ports" id="ports">Quel port HTTPS utilise-t-il ?</a></h3>
<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>
<h3><a name="httpstest" id="httpstest">Comment s'exprimer en langage HTTPS à des fins
de test ?</a></h3>
<p>Alors que vous utilisez simplement</p>
<div class="example"><p><code>$ telnet localhost 80<br />
GET / HTTP/1.0</code></p></div>
<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>
<div class="example"><p><code>$ openssl s_client -connect localhost:443 -state -debug<br />
GET / HTTP/1.0</code></p></div>
<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>
<div class="example"><p><code>$ curl http://localhost/<br />
$ curl https://localhost/</code></p></div>
<h3><a name="hang" id="hang">Pourquoi la communication se bloque-t-elle lorsque je
me connecte à mon serveur Apache configuré pour SSL ?</a></h3>
<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>
<h3><a name="refused" id="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></h3>
<p>Une configuration incorrecte peut provoquer ce type d'erreur.
Assurez-vous que vos directives <code class="directive"><a href="../mod/mpm_common.html#listen">Listen</a></code> s'accordent avec vos directives
<code class="directive"><a href="../mod/core.html#virtualhost"><VirtualHost></a></code>. Si
l'erreur persiste, recommencez depuis le début en restaurant la
configuration par défaut fournie par<code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code>.</p>
<h3><a name="envvars" id="envvars">Pourquoi les variables <code>SSL_XXX</code>
ne sont-elles pas disponibles dans mes scripts CGI et SSI ?</a></h3>
<p>Assurez-vous que la directive ``<code>SSLOptions +StdEnvVars</code>'' est
bien présente dans le contexte de vos requêtes CGI/SSI.</p>
<h3><a name="relative" id="relative">Comment puis-je basculer entre les protocoles HTTP et
HTTPS dans les hyperliens relatifs ?</a></h3>
<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 <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>, vous pouvez
manipuler des hyperliens relatifs, pour obtenir le même effet.</p>
<div class="example"><p><code>
RewriteEngine on<br />
RewriteRule ^/(.*):SSL$ https://%{SERVER_NAME}/$1 [R,L]<br />
RewriteRule ^/(.*):NOSSL$ http://%{SERVER_NAME}/$1 [R,L]
</code></p></div>
<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>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="aboutcerts" id="aboutcerts">Certificats</a></h2>
<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="#badcert">Pour quelle raison une connexion échoue-t-elle avec
l'erreur "alert bad certificate" ?</a></li>
<li><a href="#keysize">Pourquoi ma clé privée de 2048 bits ne
fonctionne-t-elle pas ?</a></li>
<li><a href="#hashsymlinks">Pourquoi l'authentification des clients ne
fonctionne-t-elle plus après une mise à jour de SSLeay version 0.8
vers la version 0.9 ?</a></li>
<li><a href="#pemder">Comment convertir un certificat du format PEM
au format DER ?</a></li>
<li><a href="#verisign">Pourquoi ne trouve-t-on pas les programmes
<code>getca</code> ou <code>getverisign</code> mentionnés par Verisign
pour installer un certificat Verisign ?</a></li>
<li><a href="#sgc">Puis-je utiliser la fonctionnalité "Cryptographie Transmise
par Serveur" (Server Gated Cryptography - SGC), aussi connue sous le nom
d'Identifiant Global Verisign (Verisign Global ID) avec mod_ssl ?</a></li>
<li><a href="#gid">Pourquoi les navigateurs se plaignent-ils de ne pas pouvoir
vérifier mon certificat de serveur Verisign Global ID ?</a></li>
</ul>
<h3><a name="keyscerts" id="keyscerts">Qu'est-ce qu'un clé privée RSA, un certificat,
une demande de signature de certificat (CSR) ?</a></h3>
<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>
<h3><a name="startup" id="startup">Y a-t-il une différence au démarrage entre un serveur
Apache non SSL et un serveur Apache supportant SSL ?</a></h3>
<p>Oui. En général, avec ou sans <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> 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>
<h3><a name="selfcert" id="selfcert">Comment créer un certificat auto-signé SSL à des
fins de test ?</a></h3>
<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> :
<pre>
SSLCertificateFile /chemin/vers/server.crt
SSLCertificateKeyFile /chemin/vers/server.key
</pre>
</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>
<h3><a name="realcert" id="realcert">Comment créer un vrai certificat SSL ?</a></h3>
<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 1024</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 :
<pre>
SSLCertificateFile /chemin/vers/server.crt
SSLCertificateKeyFile /chemin vers/server.key
</pre>
Le fichier <code>server.csr</code> n'est plus nécessaire.
</li>
</ol>
<h3><a name="ownca" id="ownca">Comment créer et utiliser sa propre Autorité de
certification (CA) ?</a></h3>
<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 1024</strong></code><br />
<br />
Sauvegardez le fichier <code>host.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 />
<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</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>
<h3><a name="passphrase" id="passphrase">Comment modifier le mot de passe
de ma clé privée ?</a></h3>
<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>
<h3><a name="removepassphrase" id="removepassphrase">Comment démarrer Apache sans avoir à entrer de
mot de passe ?</a></h3>
<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>
<h3><a name="verify" id="verify">Comment vérifier si une clé privée correspond bien
à son certificat ?</a></h3>
<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>
<h3><a name="badcert" id="badcert">>Pour quelle raison une connexion échoue-t-elle avec
l'erreur "alert bad certificate" ?</a></h3>
<p>Les erreurs du type <code>OpenSSL: error:14094412: SSL
routines:SSL3_READ_BYTES:sslv3 alert bad certificate</code> dans le fichier
journal de SSL sont souvent causées par un navigateur qui ne sait pas
manipuler le certificat ou la clé privée du serveur. Par exemple,
Netscape Navigator 3.x ne reconnaît pas une clé RSA dont la longueur
est différente de 1024 bits.</p>
<h3><a name="keysize" id="keysize">Pourquoi ma clé privée de 2048 bits ne
fonctionne-t-elle pas ?</a></h3>
<p>La longueur des clés privées pour SSL doit être de 512 ou 1024 bits, pour
des raison de compatibilité avec certains navigateurs. Une longueur de 1024
bits est recommandée car des clés d'une longueur supérieure sont incompatibles
avec certaines versions de Netscape Navigator et Microsoft Internet Explorer,
ainsi qu'avec d'autres navigateurs qui utilisent le kit de chiffrement
BSAFE de RSA.</p>
<h3><a name="hashsymlinks" id="hashsymlinks">Pourquoi l'authentification des clients ne
fonctionne-t-elle plus après une mise à jour de SSLeay version 0.8
vers la version 0.9 ?</a></h3>
<p>Les certificats de CA situés dans le chemin que vous avez
défini à l'aide de <code>SSLCACertificatePath</code> sont localisés par
SSLeay au moyen de liens symboliques représentant l'empreinte du certificat
(hash symlinks). Ces empreintes sont générées à l'aide de la commande
`<code>openssl x509 -noout -hash</code>'. Cependant, SSLeay 0.8 et 0.9
utilisent des algorithmes différents pour calculer l'empreinte d'un
certificat. Vous devrez supprimer les anciens liens symboliques et en créer
de nouveau après la mise à jour. Utilisez le <code>Makefile</code> fourni par
<code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code>.</p>
<h3><a name="pemder" id="pemder">Comment convertir un certificat du format PEM
au format DER ?</a></h3>
<p>Le format des certificats par défaut pour SSLeay/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>
<h3><a name="verisign" id="verisign">Pourquoi ne trouve-t-on pas les programmes
<code>getca</code> ou <code>getverisign</code> mentionnés par Verisign
pour installer un certificat Verisign ?</a></h3>
<p>Verisign n'a jamais fourni d'instructions spécifiques à Apache+mod_ssl.
Les instructions fournies concernent Stronghold de C2Net (un serveur
commercial basé sur Apache avec support SSL).</p>
<p>Pour installer votre certificat, il vous suffit d'enregistrer le
certificat dans un fichier, et de fournir le nom de ce fichier à la directive
<code class="directive"><a href="../mod/mod_ssl.html#sslcertificatefile">SSLCertificateFile</a></code>. Vous devez aussi
fournir le nom du fichier contenant la clé privée. Pour plus de détails, voir
la directive <code class="directive"><a href="../mod/mod_ssl.html#sslcertificatekeyfile">SSLCertificateKeyFile</a></code>.</p>
<h3><a name="sgc" id="sgc">Puis-je utiliser la fonctionnalité "Cryptographie Transmise
par Serveur" (Server Gated Cryptography - SGC), aussi connue sous le nom
d'Identifiant Global Verisign (Verisign Global ID) avec mod_ssl ?</a></h3>
<p>Oui. <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> supporte SGC depuis la version 2.1. Aucune
configuration spécifique n'est nécessaire - utilisez simplement le
Global ID comme certificat de serveur. La <em>mise à niveau</em> des clients
est gérée automatiquement par <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> à l'exécution.</p>
<h3><a name="gid" id="gid">Pourquoi les navigateurs se plaignent-ils de ne pas pouvoir
vérifier mon certificat de serveur Verisign Global ID ?</a></h3>
<p>Verisign utilise un certificat de CA intermédiaire entre le certificat
de CA racine (installé dans les navigateurs) et le certificat du serveur (que
vous avez installé sur le serveur). Verisign a dû vous envoyer ce certificat
de CA additionnel. Dans la négative, réclamez-le. Ensuite, installez ce
certificat à l'aide de la directive
<code class="directive"><a href="../mod/mod_ssl.html#sslcertificatechainfile">SSLCertificateChainFile</a></code>. Ceci assure
que le certificat de CA intermédiaire est bien envoyé au navigateur, ce qui
comble le vide dans la chaîne de certification.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="aboutssl" id="aboutssl">Le protocole SSL</a></h2>
<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">Pourquoi n'est-il pas 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="#nn">Pourquoi des erreurs d'entrée/sortie apparaissent-elles, ou
le message "Netscape a reçu des données erronées du serveur" s'affiche-t-il,
lorsqu'on se connecte à un serveur Apache+mod_ssl
avec Netscape Navigator ?</a></li>
</ul>
<h3><a name="random" id="random">Pourquoi de nombreuses et aléatoires erreurs de
protocole SSL apparaissent-elles en cas de forte charge du serveur ?</a></h3>
<p>Ce problème peut avoir plusieurs causes, mais la principale réside dans le
cache de session SSL défini par la directive
<code class="directive"><a href="../mod/mod_ssl.html#sslsessioncache">SSLSessionCache</a></code>. 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>
<h3><a name="load" id="load">Pourquoi la charge de mon serveur est-elle plus
importante depuis qu'il sert des ressources chiffrées en SSL ?</a></h3>
<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>
<h3><a name="establishing" id="establishing">Pourquoi les connexions en HTTPS à mon serveur
prennent-elles parfois jusqu'à 30 secondes pour s'établir ?</a></h3>
<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
<code class="directive"><a href="../mod/mod_ssl.html#sslrandomseed">SSLRandomSeed</a></code>.</p>
<h3><a name="ciphers" id="ciphers">Quels sont les algorithmes de chiffrement
supportés par mod_ssl ?</a></h3>
<p>En général, tous les algorithmes de chiffrement supportés par la version
d'OpenSSL installée, le sont aussi par <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code>. 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 MD5</li>
<li>RC4 avec MD5 (version d'exportation limitée à une clé de 40 bits)</li>
<li>RC2 avec MD5</li>
<li>RC2 avec MD5 (version d'exportation limitée à une clé de 40 bits)</li>
<li>IDEA avec MD5</li>
<li>DES avec MD5</li>
<li>Triple-DES avec MD5</li>
</ol>
<p>Pour déterminer la liste réelle des algorithmes disponibles, vous
pouvez utiliser la commande suivante :</p>
<div class="example"><p><code>$ openssl ciphers -v</code></p></div>
<h3><a name="adh" id="adh">Pourquoi une erreur ``no shared cipher'' apparaît-elle
quand j'essaie d'utiliser un algorithme de chiffrement
Diffie-Hellman anonyme (ADH) ?</a></h3>
<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 <code class="directive"><a href="../mod/mod_ssl.html#sslciphersuite">SSLCipherSuite</a></code>.</p>
<h3><a name="sharedciphers" id="sharedciphers">Pourquoi une erreur ``no shared cipher''
apparaît-elle lorsqu'on se connecte à mon serveur
fraîchement installé ?</a></h3>
<p>Soit vous avez fait une erreur en définissant votre directive
<code class="directive"><a href="../mod/mod_ssl.html#sslciphersuite">SSLCipherSuite</a></code> (comparez-la avec
l'exemple préconfiguré dans <code>httpd.conf-dist</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>
<h3><a name="vhosts" id="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></h3>
<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 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. Bingo !</p>
<h3><a name="vhosts2" id="vhosts2">Pourquoi n'est-il pas possible d'utiliser
l'hébergement virtuel basé sur le nom d'hôte
pour différencier plusieurs hôtes virtuels ?</a></h3>
<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>Et là, on reçoit un choc en apprenant que ce n'est pas possible.</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 contient aucun champ relatif
à l'hôte, le serveur n'a aucun moyen de déterminer quel hôte virtuel SSL il
doit utiliser. En général, il utilisera le premier qu'il trouve et qui
correspond à l'adresse IP et au port spécifiés.</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>
<div class="example"><p><code>
NameVirtualHost 192.168.1.1:80
</code></p></div>
<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>
<h3><a name="comp" id="comp">Comment mettre en oeuvre la compression SSL ?</a></h3>
<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>
<h3><a name="lockicon" id="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></h3>
<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>
<h3><a name="msie" id="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></h3>
<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>
<div class="example"><p><code>
SetEnvIf User-Agent ".*MSIE.*" \<br />
nokeepalive ssl-unclean-shutdown \<br />
downgrade-1.0 force-response-1.0
</code></p></div>
<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
<code class="directive"><a href="../mod/mod_setenvif.html#setenvif">SetEnvIf</a></code> 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>
<p>Un autre problème vient du fait que les versions d'exportation
56 bits de MSIE 5.x présentent une mauvaise implémentation de
SSLv3, qui interagit de manière inappropriée avec les versions
d'OpenSSL supérieures à 0.9.4. Vous pouvez ignorer ce problème et
demander à vos clients de mettre à jour leurs navigateurs, vous
pouvez revenir à OpenSSL 0.9.4 (non recommandé), ou vous pouvez
contourner le problème, en sachant que vos modifications
affecteront tous les types de navigateurs :</p>
<div class="example"><p><code>SSLProtocol all -SSLv3</code></p></div>
<p>va désactiver complètement le protocole SSLv3 et ainsi permettre
aux navigateurs concernés de fonctionner. Une meilleure solution
consiste à ne désactiver que les algorithmes de chiffrement qui
posent problème.</p>
<div class="example"><p><code>SSLCipherSuite
ALL:!ADH:<strong>!EXPORT56</strong>:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP</code>
</p></div>
<p>Ceci permet aussi aux versions de MSIE incriminées de
fonctionner, mais n'enlève que le support des derniers algorithmes
de chiffrement TLS 56 bits.</p>
<p>Autre problème avec les clients MSIE 5.x : ils refusent de se
connecter à des URLs de la forme <code>https://12.34.56.78/</code>
(où une adresse IP est utilisée à la place d'un nom d'hôte), si le
serveur utilise le dispositif de cryptographie transmise par le
serveur (SGC). Le problème ne peut être contourné qu'en utilisant
le nom de domaine pleinement qualifié (FQDN) du site web dans les
hyperliens à la place de l'adresse IP, car MSIE 5.x gère la
négociation SGC de manière inappropriée.</p>
<p>Enfin, pour certaines versions de MSIE, il semble nécessaire
qu'une session SSL puisse être réutilisée (un comportement tout à
fait non conforme aux standard, bien entendu). Les connections avec
ces versions de MSIE ne fonctionnent que si un cache de session SSL
est mis en oeuvre. Ainsi, pour contourner le problème, assurez-vous
d'utiliser un cache de session (voir la directive
<code class="directive"><a href="../mod/mod_ssl.html#sslsessioncache">SSLSessionCache</a></code>).</p>
<h3><a name="nn" id="nn">Pourquoi des erreurs d'entrée/sortie apparaissent-elles, ou
le message "Netscape a reçu des données erronées du serveur" s'affiche-t-il,
lorsqu'on se connecte à un serveur Apache+mod_ssl
avec Netscape Navigator ?</a></h3>
<p>
Ceci arrive en général quand vous avez créé un nouveau certificat
de serveur pour un domaine donné, mais aviez auparavant configuré
votre navigateur pour toujours accepter l'ancien certificat du
serveur. Si vous supprimez de votre navigateur l'entrée
correspondant à l'ancien certificat, tout devrait rentrer dans
l'ordre. L'implémentation de SSL dans Netscape étant correcte, les
erreurs d'entrées/sorties avec Netscape Navigator sont en général
causées par les certificats installés.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="support" id="support">Support de mod_ssl</a></h2>
<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>
<h3><a name="resources" id="resources">Quelles sont les sources d'informations
disponibles en cas de problème avec mod_ssl ?</a></h3>
<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/trunk/ssl/ssl_faq.html">
http://httpd.apache.org/docs/trunk/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>
<dt>Les archives de la liste de diffusion de support modssl-users
<a href="http://www.modssl.org/support/">http://www.modssl.org/support/</a></dt>
<dd>Vous pouvez chercher la solution à votre problème dans les
archives de la liste de diffusion modssl-users. Vous n'êtes
probablement pas la première personne à rencontrer ce problème !
</dd>
</dl>
<h3><a name="contact" id="contact">Qui peut-on contacter pour un support en cas de
problème avec mod_ssl ?</a></h3>
<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 modssl-users</em><br />
<a href="mailto:modssl-users@modssl.org">
modssl-users@modssl.org</a><br />
C'est la manière la plus efficace de soumettre votre rapport de
problème, car ainsi, les autres en sont informés, et pourront
bénéficier des réponses apportées. Vous devez tout d'abord vous
abonner à la liste, mais vous pourrez ensuite discuter
facilement de votre problème avec l'auteur et l'ensemble de la
communauté d'utilisateurs de mod_ssl.
</li>
<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>
<h3><a name="reportdetails" id="reportdetails">Quelles informations dois-je fournir lors
de l'écriture d'un rapport de bogue ?</a></h3>
<p>Vous devez toujours fournir au moins les informations
suivantes :</p>
<dl>
<dt>Les versions d'Apache 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+mod_ssl+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 <code class="program"><a href="../programs/configure.html">configure</a></code> 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+mod_ssl+OpenSSL 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>
<h3><a name="coredumphelp" id="coredumphelp">Un vidage mémoire s'est produit,
pouvez-vous m'aider ?</a></h3>
<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>
<h3><a name="backtrace" id="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></h3>
<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>
</div></div>
<div class="bottomlang">
<p><span>Langues Disponibles: </span><a href="../en/ssl/ssl_faq.html" hreflang="en" rel="alternate" title="English"> en </a> |
<a href="../fr/ssl/ssl_faq.html" title="Français"> fr </a></p>
</div><div id="footer">
<p class="apache">Copyright 2010 The Apache Software Foundation.<br />Autorisé sous <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
<p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossaire</a> | <a href="../sitemap.html">Plan du site</a></p></div>
</body></html>
|
