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
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
|
<html>
<head>
<title>mod_ssl: F.A.Q.</title>
<!--
Copyright (c) 1998-2001 Ralf S. Engelschall. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above
copyright notice, this list of conditions and the following
disclaimer.
2. Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials
provided with the distribution.
3. All advertising materials mentioning features or use of this
software must display the following acknowledgment:
"This product includes software developed by
Ralf S. Engelschall <rse@engelschall.com> for use in the
mod_ssl project (http://www.modssl.org/)."
4. The name "mod_ssl" must not be used to endorse or promote
products derived from this software without prior written
permission.
5. Redistributions of any form whatsoever must retain the
following acknowledgment:
"This product includes software developed by
Ralf S. Engelschall <rse@engelschall.com> for use in the
mod_ssl project (http://www.modssl.org/)."
THIS SOFTWARE IS PROVIDED BY RALF S. ENGELSCHALL ``AS IS'' AND ANY
EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL RALF S. ENGELSCHALL OR
HIS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
OF THE POSSIBILITY OF SUCH DAMAGE.
-->
<style type="text/css"><!--
A:link {
text-decoration: none;
color: #6666cc;
}
A:active {
text-decoration: none;
color: #6666cc;
}
A:visited {
text-decoration: none;
color: #6666cc;
}
#sf {
font-family: arial,helvetica;
font-variant: normal;
font-style: normal;
}
H1 {
font-weight: bold;
font-size: 24pt;
line-height: 24pt;
font-family: arial,helvetica;
font-variant: normal;
font-style: normal;
}
H2 {
font-weight: bold;
font-size: 18pt;
line-height: 18pt;
font-family: arial,helvetica;
font-variant: normal;
font-style: normal;
}
H3 {
font-weight: bold;
font-size: 14pt;
line-height: 14pt;
font-family: arial,helvetica;
font-variant: normal;
font-style: normal;
}
H4 {
font-weight: bold;
font-size: 12pt;
line-height: 12pt;
font-family: arial,helvetica;
font-variant: normal;
font-style: normal;
}
#H {
}
#D {
background-color: #f0f0f0;
}
#faq {
font-weight: bold;
font-size: 16pt;
line-height: 16pt;
font-family: arial,helvetica;
font-variant: normal;
font-style: normal;
}
#howto {
font-weight: bold;
font-size: 16pt;
line-height: 16pt;
font-family: arial,helvetica;
font-variant: normal;
font-style: normal;
}
#term {
font-weight: bold;
font-size: 16pt;
line-height: 16pt;
font-family: arial,helvetica;
font-variant: normal;
font-style: normal;
}
--></style>
<script type="text/javascript" language="JavaScript">
<!-- Hiding the code
function ro_imgNormal(imgName) {
if (document.images) {
document[imgName].src = eval(imgName + '_n.src');
self.status = '';
}
}
function ro_imgOver(imgName, descript) {
if (document.images) {
document[imgName].src = eval(imgName + '_o.src');
self.status = descript;
}
}
// done hiding -->
</script>
<script type="text/javascript" language="JavaScript">
<!-- Hiding the code
if (document.images) {
ro_img_prev_top_n = new Image();
ro_img_prev_top_n.src = 'ssl_template.navbut-prev-n.gif';
ro_img_prev_top_o = new Image();
ro_img_prev_top_o.src = 'ssl_template.navbut-prev-s.gif';
}
// done hiding -->
</script>
<script type="text/javascript" language="JavaScript">
<!-- Hiding the code
if (document.images) {
ro_img_prev_bot_n = new Image();
ro_img_prev_bot_n.src = 'ssl_template.navbut-prev-n.gif';
ro_img_prev_bot_o = new Image();
ro_img_prev_bot_o.src = 'ssl_template.navbut-prev-s.gif';
}
// done hiding -->
</script>
<script type="text/javascript" language="JavaScript">
<!-- Hiding the code
if (document.images) {
ro_img_next_top_n = new Image();
ro_img_next_top_n.src = 'ssl_template.navbut-next-n.gif';
ro_img_next_top_o = new Image();
ro_img_next_top_o.src = 'ssl_template.navbut-next-s.gif';
}
// done hiding -->
</script>
<script type="text/javascript" language="JavaScript">
<!-- Hiding the code
if (document.images) {
ro_img_next_bot_n = new Image();
ro_img_next_bot_n.src = 'ssl_template.navbut-next-n.gif';
ro_img_next_bot_o = new Image();
ro_img_next_bot_o.src = 'ssl_template.navbut-next-s.gif';
}
// done hiding -->
</script>
</head>
<body bgcolor="#ffffff" text="#000000" link="#333399" alink="#9999ff" vlink="#000066">
<div align="center">
<table width="600" cellspacing="0" cellpadding="0" border="0" summary="">
<tr>
<td>
<img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="600" height="1" align="bottom" border="0"><br>
<table width="600" cellspacing="0" cellpadding="0" summary="">
<tr>
<td>
<table width="600" summary="">
<tr>
<td align="left" valign="bottom">
<font face="Arial,Helvetica" size="+2"><b>mod_ssl</b></font>
</td>
<td align="right">
<img src="ssl_template.head-chapter.gif" alt="Chapter" width="175" height="94"> <img src="ssl_template.head-num-6.gif" alt="6" width="74" height="89">
</td>
</tr>
</table>
</td>
</tr>
<tr>
<td><img src="ssl_template.imgdot-1x1-000000.gif" alt="" width="600" height="2" align="bottom" border="0"></td>
</tr>
<tr>
<td>
<table width="600" border="0" summary="">
<tr>
<td valign="top" align="left" width="250">
<a href="ssl_howto.html" onmouseover="ro_imgOver('ro_img_prev_top', 'previous page'); return true" onmouseout="ro_imgNormal('ro_img_prev_top'); return true" onfocus="ro_imgOver('ro_img_prev_top', 'previous page'); return true" onblur="ro_imgNormal('ro_img_prev_top'); return true"><img name="ro_img_prev_top" src="ssl_template.navbut-prev-n.gif" alt="previous page" width="70" height="18" border="0"></a><br><font color="#000000">HowTo</font>
</td>
<td valign="top" align="right" width="250">
<a href="ssl_glossary.html" onmouseover="ro_imgOver('ro_img_next_top', 'next page'); return true" onmouseout="ro_imgNormal('ro_img_next_top'); return true" onfocus="ro_imgOver('ro_img_next_top', 'next page'); return true" onblur="ro_imgNormal('ro_img_next_top'); return true"><img name="ro_img_next_top" src="ssl_template.navbut-next-n.gif" alt="next page" width="70" height="18" border="0"></a><br><font color="#000000">Glossary</font>
</td>
</tr>
</table>
</td>
</tr>
<tr>
<td>
<br>
<img src="ssl_template.title-faq.gif" alt="F.A.Q." width="456" height="60">
</td>
</tr>
</table>
<div align="right">
<table cellspacing="0" cellpadding="0" width="200" summary="">
<tr>
<td>
<em>
``The wise man doesn't give the right answers,
he poses the right questions.''
</em>
</td>
</tr>
<tr>
<td align="right">
<font size="-1">
Claude Levi-Strauss
</font>
</td>
</tr>
</table>
</div>
<p>
<table cellspacing="0" cellpadding="0" border="0" summary="">
<tr valign="bottom">
<td>
<img src="ssl_faq.gfont000.gif" alt="T" width="34" height="34" border="0" align="left">
his chapter is a collection of frequently asked questions (FAQ) and
corresponding answers following the popular USENET tradition. Most of these
questions occured on the Newsgroup <a
href="news:comp.infosystems.www.servers.unix">
<code>comp.infosystems.www.servers.unix</code></a> or the mod_ssl Support
Mailing List <a href="mailto:modssl-users@modssl.org">
<code>modssl-users@modssl.org</code></a>. They are collected at this place
to avoid answering the same questions over and over.
<p>
Please read this chapter at least once when installing mod_ssl or at least
search for your problem here before submitting a problem report to the
author.
</td>
<td>
</td>
<td>
<div align="right">
<table cellspacing="0" cellpadding="5" border="0" bgcolor="#ccccff" width="350" summary="">
<tr>
<td bgcolor="#333399">
<font face="Arial,Helvetica" color="#ccccff">
<b>Table Of Contents</b>
</font>
</td>
</tr>
<tr>
<td>
<font face="Arial,Helvetica" size="-1">
<a href="#ToC1"><strong>About the module</strong></a><br>
<a href="#ToC2"><strong>What is the history of mod_ssl?</strong></a><br>
<a href="#ToC3"><strong>Apache-SSL vs. mod_ssl: differences?</strong></a><br>
<a href="#ToC4"><strong>mod_ssl vs. commercial alternatives?</strong></a><br>
<a href="#ToC5"><strong>mod_ssl/Apache versions?</strong></a><br>
<a href="#ToC6"><strong>mod_ssl and Year 2000?</strong></a><br>
<a href="#ToC7"><strong>mod_ssl and Wassenaar Arrangement?</strong></a><br>
<a href="#ToC8"><strong>About Installation</strong></a><br>
<a href="#ToC9"><strong>Core dumps for HTTPS requests?</strong></a><br>
<a href="#ToC10"><strong>Core dumps for Apache+mod_ssl+PHP3?</strong></a><br>
<a href="#ToC11"><strong>Undefined symbols on startup?</strong></a><br>
<a href="#ToC12"><strong>Permission problem on SSLMutex</strong></a><br>
<a href="#ToC13"><strong>Shared memory and process size?</strong></a><br>
<a href="#ToC14"><strong>Shared memory and pathname?</strong></a><br>
<a href="#ToC15"><strong>PRNG and not enough entropy?</strong></a><br>
<a href="#ToC16"><strong>About Configuration</strong></a><br>
<a href="#ToC17"><strong>HTTP and HTTPS with a single server?</strong></a><br>
<a href="#ToC18"><strong>Where is the HTTPS port?</strong></a><br>
<a href="#ToC19"><strong>How to test HTTPS manually?</strong></a><br>
<a href="#ToC20"><strong>Why does my connection hang?</strong></a><br>
<a href="#ToC21"><strong>Why do I get connection refused?</strong></a><br>
<a href="#ToC22"><strong>Why are the SSL_XXX variables missing?</strong></a><br>
<a href="#ToC23"><strong>How to switch with relative hyperlinks?</strong></a><br>
<a href="#ToC24"><strong>About Certificates</strong></a><br>
<a href="#ToC25"><strong>What are Keys, CSRs and Certs?</strong></a><br>
<a href="#ToC26"><strong>Difference on startup?</strong></a><br>
<a href="#ToC27"><strong>How to create a dummy cert?</strong></a><br>
<a href="#ToC28"><strong>How to create a real cert?</strong></a><br>
<a href="#ToC29"><strong>How to create my own CA?</strong></a><br>
<a href="#ToC30"><strong>How to change a pass phrase?</strong></a><br>
<a href="#ToC31"><strong>How to remove a pass phrase?</strong></a><br>
<a href="#ToC32"><strong>How to verify a key/cert pair?</strong></a><br>
<a href="#ToC33"><strong>Bad Certificate Error?</strong></a><br>
<a href="#ToC34"><strong>Why does a 2048-bit key not work?</strong></a><br>
<a href="#ToC35"><strong>Why is client auth broken?</strong></a><br>
<a href="#ToC36"><strong>How to convert from PEM to DER?</strong></a><br>
<a href="#ToC37"><strong>Verisign and the magic getca program?</strong></a><br>
<a href="#ToC38"><strong>Global IDs or SGC?</strong></a><br>
<a href="#ToC39"><strong>Global IDs and Cert Chain?</strong></a><br>
<a href="#ToC40"><strong>About SSL Protocol</strong></a><br>
<a href="#ToC41"><strong>Random SSL errors under heavy load?</strong></a><br>
<a href="#ToC42"><strong>Why has the server a higher load?</strong></a><br>
<a href="#ToC43"><strong>Why are connections horribly slow?</strong></a><br>
<a href="#ToC44"><strong>Which ciphers are supported?</strong></a><br>
<a href="#ToC45"><strong>How to use Anonymous-DH ciphers</strong></a><br>
<a href="#ToC46"><strong>Why do I get 'no shared ciphers'?</strong></a><br>
<a href="#ToC47"><strong>HTTPS and name-based vhosts</strong></a><br>
<a href="#ToC48"><strong>The lock icon in Netscape locks very late</strong></a><br>
<a href="#ToC49"><strong>Why do I get I/O errors with MSIE clients?</strong></a><br>
<a href="#ToC50"><strong>Why do I get I/O errors with NS clients?</strong></a><br>
<a href="#ToC51"><strong>About Support</strong></a><br>
<a href="#ToC52"><strong>Resources in case of problems?</strong></a><br>
<a href="#ToC53"><strong>Support in case of problems?</strong></a><br>
<a href="#ToC54"><strong>How to write a problem report?</strong></a><br>
<a href="#ToC55"><strong>I got a core dump, can you help me?</strong></a><br>
<a href="#ToC56"><strong>How to get a backtrace?</strong></a><br>
</font>
</td>
</tr>
</table>
</div>
</td>
</tr>
</table>
<h2><a name="ToC1">About the module</a></h2>
<ul>
<p>
<li><a name="ToC2"></a>
<a name="history"></a>
<strong id="faq">
What is the history of mod_ssl?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#history"><b>L</b></a>]
<p>
The mod_ssl v1 package was initially created in April 1998 by <a
href="mailto:rse@engelschall.com">Ralf S. Engelschall</a> via porting <a
href="mailto:ben@algroup.co.uk">Ben Laurie</a>'s <a
href="http://www.apache-ssl.org/">Apache-SSL</a> 1.17 source patches for
Apache 1.2.6 to Apache 1.3b6. Because of conflicts with Ben
Laurie's development cycle it then was re-assembled from scratch for
Apache 1.3.0 by merging the old mod_ssl 1.x with the newer Apache-SSL
1.18. From this point on mod_ssl lived its own life as mod_ssl v2. The
first publically released version was mod_ssl 2.0.0 from August 10th,
1998. As of this writing (August 1999) the current mod_ssl version is 2.4.0.
<p>
After one year of very active development with over 1000 working hours and
over 40 releases mod_ssl reached its current state. The result is an
already very clean source base implementing a very rich functionality.
The code size increased by a factor of 4 to currently a total of over
10.000 lines of ANSI C consisting of approx. 70% code and 30% code
documentation. From the original Apache-SSL code currently approx. 5% is
remaining only.
<p>
<li><a name="ToC3"></a>
<a name="apssl-diff"></a>
<strong id="faq">
What are the functional differences between mod_ssl and Apache-SSL, from where
it is originally derived?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#apssl-diff"><b>L</b></a>]
<p>
This neither can be answered in short (there were too many code changes)
nor can be answered at all by the author (there would immediately be flame
wars with no reasonable results at the end). But as you easily can guess
from the 5% of remaining Apache-SSL code, a lot of differences exists,
although user-visible backward compatibility exists for most things.
<p>
When you really want a detailed comparison you have to read the entries in
the large <code>CHANGES</code> file that is in the mod_ssl
distribution. Usually this is much too hard-core. So I recommend you to
either believe in the opinion and recommendations of other users (the
simplest approach) or do a comparison yourself (the most reasonable
approach). For the latter, grab distributions of mod_ssl (from <a
href="http://www.modssl.org/">http://www.modssl.org</a>) and Apache-SSL
(from <a href="http://www.apache-ssl.org/">http://www.apache-ssl.org</a>),
install both packages, read their documentation and try them out yourself.
Then choose the one which pleases you most.
<p>
A few final hints to help direct your comparison: quality of documentation
("can you easily find answers and are they sufficient?"), quality of
source code ("is the source code reviewable so you can make sure there
aren't any trapdoors or inherent security risks because of bad programming
style?"), easy and clean installation ("can the SSL functionality easily
added to an Apache source tree without manual editing or patching?"),
clean integration into Apache ("is the SSL functionality encapsulated and
cleanly separated from the remaining Apache functionality?"), support for
Dynamic Shared Object (DSO) facility ("can the SSL functionality built as
a separate DSO for maximum flexibility?"), Win32 port ("is the SSL
functionality available also under the Win32 platform?"), amount and
quality of functionality ("is the provided SSL functionality and control
possibilities sufficient for your situation?"), quality of problem tracing
("is it possible for you to easily trace down the problems via logfiles,
etc?"), etc. pp.
<p>
<li><a name="ToC4"></a>
<a name="apssl-diff"></a>
<strong id="faq">
What are the major differences between mod_ssl and
the commercial alternatives like Raven or Stronghold?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#apssl-diff"><b>L</b></a>]
<p>
In the past (until September 20th, 2000) the major difference was
the RSA license which one received (very cheaply in contrast to
a direct licensing from RSA DSI) with the commercial Apache SSL
products. On the other hand, one needed this license only in the US,
of course. So for non-US citizens this point was useless. But now
even for US citizens the situations changed because the RSA patent
expired on September 20th, 2000 and RSA DSI also placed the RSA
algorithm explicitly into the public domain.
<p>
Second, there is the point that one has guaranteed support from
the commercial vendors. On the other hand, if you monitored the
Open Source quality of mod_ssl and the support activities
found on <a href="mailto:modssl-users@modssl.org">
<code>modssl-users@modssl.org</code></a>, you could ask yourself
whether you are really convinced that you can get better support
from a commercial vendor.
<p>
Third, people often think they would receive perhaps at least a
better technical SSL solution than mod_ssl from the commercial
vendors. But this is not really true, because all commercial
alternatives (Raven 1.4.x, Stronghold 3.x, RedHat SWS 2.x, etc.)
<i>are</i> actually based on mod_ssl and OpenSSL. The reason for
this common misunderstanding is mainly because some vendors make no
attempt to make it reasonably clear that their product is actually
mod_ssl based. So, do not think, just because the commercial
alternatives are usually more expensive, that you are also receiving
an alternative <i>technical</i> SSL solution. This is usually not
the case. Actually the vendor versions of Apache, mod_ssl and OpenSSL
often stay behind the latest free versions and perhaps this way still do not
include important bug and security fixes. On the other hand,
it sometimes occurs that a vendor version includes useful changes
which are not available through the official freely available
packages. But most vendors play fair and contribute back those
changes to the free software world, of course.
<p>
So, in short: There are lots of commercial versions of the popular
Apache+mod_ssl+OpenSSL server combination available. Every user
should decide carefully whether they really need to buy a commercial
version or whether it would not be sufficient to directly use the
free and official versions of the Apache, mod_ssl and OpenSSL
packages.
<p>
<li><a name="ToC5"></a>
<a name="what-version"></a>
<strong id="faq">
How do I know which mod_ssl version is for which Apache version?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#what-version"><b>L</b></a>]
<p>
That's trivial: mod_ssl uses version strings of the syntax
<em><mod_ssl-version></em>-<em><apache-version></em>, for
instance <code>2.4.0-1.3.9</code>. This directly indicates that it's
mod_ssl version 2.4.0 for Apache version 1.3.9. And this also means you
<em>only</em> can apply this mod_ssl version to exactly this Apache
version (unless you use the <code>--force</code> option to mod_ssl's
<code>configure</code> command ;-).
<p>
<li><a name="ToC6"></a>
<a name="y2k"></a>
<strong id="faq">
Is mod_ssl Year 2000 compliant?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#y2k"><b>L</b></a>]
<p>
Yes, mod_ssl is Year 2000 compliant.
<p>
Because first mod_ssl internally never stores years as two digits.
Instead it always uses the ANSI C & POSIX numerical data type
<code>time_t</code> type, which on almost all Unix platforms at the moment
is a <code>signed long</code> (usually 32-bits) representing seconds since
epoch of January 1st, 1970, 00:00 UTC. This signed value overflows in
early January 2038 and not in the year 2000. Second, date and time
presentations (for instance the variable ``<code>%{TIME_YEAR}</code>'')
are done with full year value instead of abbreviating to two digits.
<p>
Additionally according to a <a
href="../../misc/FAQ.html#year2000">Year 2000
statement</a> from the Apache Group, the Apache webserver is Year 2000
compliant, too. But whether OpenSSL or the underlying Operating System
(either a Unix or Win32 platform) is Year 2000 compliant is a different
question which cannot be answered here.
<p>
<li><a name="ToC7"></a>
<a name="wassenaar"></a>
<strong id="faq">
What about mod_ssl and the Wassenaar Arrangement?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#wassenaar"><b>L</b></a>]
<p>
First, let us explain what <i>Wassenaar</i> and it's <i>Arrangement on
Export Controls for Conventional Arms and Dual-Use Goods and
Technologies</i> is: This is a international regime, established 1995, to
control trade in conventional arms and dual-use goods and technology. It
replaced the previous <i>CoCom</i> regime. 33 countries are signatories:
Argentina, Australia, Austria, Belgium, Bulgaria, Canada, Czech Republic,
Denmark, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Japan,
Luxembourg, Netherlands, New Zealand, Norway, Poland, Portugal, Republic
of Korea, Romania, Russian Federation, Slovak Republic, Spain, Sweden,
Switzerland, Turkey, Ukraine, United Kingdom and United States. For more
details look at <a
href="http://www.wassenaar.org/">http://www.wassenaar.org/</a>.
<p>
In short: The aim of the Wassenaar Arrangement is to prevent the build up
of military capabilities that threaten regional and international security
and stability. The Wassenaar Arrangement controls the export of
cryptography as a dual-use good, i.e., one that has both military and
civilian applications. However, the Wassenaar Arrangement also provides an
exemption from export controls for mass-market software and free software.
<p>
In the current Wassenaar ``<i>List of Dual Use Goods and Technologies And
Munitions</i>'', under ``<i>GENERAL SOFTWARE NOTE</i>'' (GSN) it says
``<i>The Lists do not control "software" which is either: 1. [...] 2. "in
the public domain".</i>'' And under ``<i>DEFINITIONS OF TERMS USED IN
THESE LISTS</i>'' one can find the definition: ``<i>"In the public
domain": This means "technology" or "software" which has been made
available without restrictions upon its further dissemination. N.B.
Copyright restrictions do not remove "technology" or "software" from being
"in the public domain".</i>''
<p>
So, both mod_ssl and OpenSSL are ``in the public domain'' for the purposes
of the Wassenaar Agreement and its ``<i>List of Dual Use Goods and
Technologies And Munitions List</i>''.
<p>
Additionally the Wassenaar Agreement itself has no direct consequence for
exporting cryptography software. What is actually allowed or forbidden to
be exported from the countries has still to be defined in the local laws
of each country. And at least according to official press releases from
the German BMWi (see <a
href="http://www.bmwi.de/presse/1998/1208prm2.html">here</a>) and the
Switzerland Bawi (see <a href="http://jya.com/wass-ch.htm">here</a>) there
will be no forthcoming export restriction for free cryptography software
for their countries. Remember that mod_ssl is created in Germany and
distributed from Switzerland.
<p>
So, mod_ssl and OpenSSL are not affected by the Wassenaar Agreement.
</ul>
<p>
<br>
<h2><a name="ToC8">About Installation</a></h2>
<ul>
<p>
<li><a name="ToC9"></a>
<a name="core-dbm"></a>
<strong id="faq">
When I access my website the first time via HTTPS I get a core dump?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#core-dbm"><b>L</b></a>]
<p>
There can be a lot of reasons why a core dump can occur, of course.
Ranging from buggy third-party modules, over buggy vendor libraries up to
a buggy mod_ssl version. But the above situation is often caused by old or
broken vendor DBM libraries. To solve it either build mod_ssl with the
built-in SDBM library (specify <tt>--enable-rule=SSL_SDBM</tt> at the
APACI command line) or switch from ``<tt>SSLSessionCache dbm:</tt>'' to the
newer ``<tt>SSLSessionCache shm:</tt>'' variant (after you have rebuilt
Apache with MM, of course).
<p>
<li><a name="ToC10"></a>
<a name="core-php3"></a>
<strong id="faq">
My Apache dumps core when I add both mod_ssl and PHP3?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#core-php3"><b>L</b></a>]
<p>
Make sure you add mod_ssl to the Apache source tree first and then do a
fresh configuration and installation of PHP3. For SSL support EAPI patches
are required which have to change internal Apache structures. PHP3 needs
to know about these in order to work correctly. Always make sure that
<tt>-DEAPI</tt> is contained in the compiler flags when PHP3 is build.
<p>
<li><a name="ToC11"></a>
<a name="dso-sym"></a>
<strong id="faq">
When I startup Apache I get errors about undefined symbols like ap_global_ctx?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#dso-sym"><b>L</b></a>]
<p>
This actually means you installed mod_ssl as a DSO, but without rebuilding
Apache with EAPI. Because EAPI is a requirement for mod_ssl, you need an
extra patched Apache (containing the EAPI patches) and you have to build
this Apache with EAPI enabled (explicitly specify
<tt>--enable-rule=EAPI</tt> at the APACI command line).
<p>
<li><a name="ToC12"></a>
<a name="mutex-perm"></a>
<strong id="faq">
When I startup Apache I get permission errors related to SSLMutex?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#mutex-perm"><b>L</b></a>]
<p>
When you receive entries like ``<code>mod_ssl: Child could not open
SSLMutex lockfile /opt/apache/logs/ssl_mutex.18332 (System error follows)
[...] System: Permission denied (errno: 13)</code>'' this is usually
caused by to restrictive permissions on the <i>parent</i> directories.
Make sure that all parent directories (here <code>/opt</code>,
<code>/opt/apache</code> and <code>/opt/apache/logs</code>) have the x-bit
set at least for the UID under which Apache's children are running (see
the <code>User</code> directive of Apache).
<p>
<li><a name="ToC13"></a>
<a name="mm"></a>
<strong id="faq">
When I use the MM library and the shared memory cache each process grows
1.5MB according to `top' although I specified 512000 as the cache size?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#mm"><b>L</b></a>]
<p>
The additional 1MB are caused by the global shared memory pool EAPI
allocates for all modules and which is not used by mod_ssl for
various reasons. So the actually allocated shared memory is always
1MB more than what you specify on <code>SSLSessionCache</code>.
But don't be confused by the display of `top': although is
indicates that <i>each</i> process grow, this is not reality, of
course. Instead the additional memory consumption is shared by
all processes, i.e. the 1.5MB are allocated only once per Apache
instance and not once per Apache server process.
<p>
<li><a name="ToC14"></a>
<a name="mmpath"></a>
<strong id="faq">
Apache creates files in a directory declared by the internal
EAPI_MM_CORE_PATH define. Is there a way to override the path using a
configuration directive?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#mmpath"><b>L</b></a>]
<p>
No, there is not configuration directive, because for technical
bootstrapping reasons, a directive not possible at all. Instead
use ``<code>CFLAGS='-DEAPI_MM_CORE_PATH="/path/to/wherever/"'
./configure ...</code>'' when building Apache or use option
<b>-d</b> when starting <code>httpd</code>.
<p>
<li><a name="ToC15"></a>
<a name="entropy"></a>
<strong id="faq">
When I fire up the server, mod_ssl stops with the error
"Failed to generate temporary 512 bit RSA private key", why?
And a "PRNG not seeded" error occurs if I try "make certificate".
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#entropy"><b>L</b></a>]
<p>
Cryptographic software needs a source of unpredictable data
to work correctly. Many open source operating systems provide
a "randomness device" that serves this purpose (usually named
<code>/dev/random</code>). On other systems, applications have to
seed the OpenSSL Pseudo Random Number Generator (PRNG) manually with
appropriate data before generating keys or performing public key
encryption. As of version 0.9.5, the OpenSSL functions that need
randomness report an error if the PRNG has not been seeded with
at least 128 bits of randomness. So mod_ssl has to provide enough
entropy to the PRNG to work correctly. For this one has to use the
<code>SSLRandomSeed</code> directives (to solve the run-time problem)
and create a <code>$HOME/.rnd</code> file to make sure enough
entropy is available also for the "<code>make certificate</code>"
step (in case the "<code>make certificate</code>" procedure is not
able to gather enough entropy theirself by searching for system
files).
</ul>
<p>
<br>
<h2><a name="ToC16">About Configuration</a></h2>
<ul>
<p>
<li><a name="ToC17"></a>
<a name="https-parallel"></a>
<strong id="faq">
Is it possible to provide HTTP and HTTPS with a single server?</strong>
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#https-parallel"><b>L</b></a>]
<p>
Yes, HTTP and HTTPS use different server ports, so there is no direct
conflict between them. Either run two separate server instances (one binds
to port 80, the other to port 443) or even use Apache's elegant virtual
hosting facility where you can easily create two virtual servers which
Apache dispatches: one responding to port 80 and speaking HTTP and one
responding to port 443 speaking HTTPS.
<p>
<li><a name="ToC18"></a>
<a name="https-port"></a>
<strong id="faq">
I know that HTTP is on port 80, but where is HTTPS?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#https-port"><b>L</b></a>]
<p>
You can run HTTPS on any port, but the standards specify port 443, which
is where any HTTPS compliant browser will look by default. You can force
your browser to look on a different port by specifying it in the URL like
this (for port 666): <code>https://secure.server.dom:666/</code>
<p>
<li><a name="ToC19"></a>
<a name="https-test"></a>
<strong id="faq">
How can I speak HTTPS manually for testing purposes?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#https-test"><b>L</b></a>]
<p>
While you usually just use
<p>
<code><b>$ telnet localhost 80</b></code><br>
<code><b>GET / HTTP/1.0</b></code>
<p>
for simple testing the HTTP protocol of Apache, it's not such easy for
HTTPS because of the SSL protocol between TCP and HTTP. But with the
help of OpenSSL's <code>s_client</code> command you can do a similar
check even for HTTPS:
<p>
<code><b>$ openssl s_client -connect localhost:443 -state -debug</b></code><br>
<code><b>GET / HTTP/1.0</b></code>
<p>
Before the actual HTTP response you receive detailed information about the
SSL handshake. For a more general command line client which directly
understands both the HTTP and HTTPS scheme, can perform GET and POST
methods, can use a proxy, supports byte ranges, etc. you should have a
look at nifty <a href="http://curl.haxx.nu/">cURL</a>
tool. With it you can directly check if your Apache is running fine on
Port 80 and 443 as following:
<p>
<code><b>$ curl http://localhost/</b></code><br>
<code><b>$ curl https://localhost/</b></code><br>
<p>
<li><a name="ToC20"></a>
<a name="hang"></a>
<strong id="faq">
Why does the connection hang when I connect to my SSL-aware Apache server?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#hang"><b>L</b></a>]
<p>
Because you connected with HTTP to the HTTPS port, i.e. you used an URL of
the form ``<code>http://</code>'' instead of ``<code>https://</code>''.
This also happens the other way round when you connect via HTTPS to a HTTP
port, i.e. when you try to use ``<code>https://</code>'' on a server that
doesn't support SSL (on this port). Make sure you are connecting to a
virtual server that supports SSL, which is probably the IP associated with
your hostname, not localhost (127.0.0.1).
<p>
<li><a name="ToC21"></a>
<a name="hang"></a>
<strong id="faq">
Why do I get ``Connection Refused'' messages when trying to access my freshly
installed Apache+mod_ssl server via HTTPS?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#hang"><b>L</b></a>]
<p>
There can be various reasons. Some of the common mistakes is that people
start Apache with just ``<tt>apachectl start</tt>'' (or
``<tt>httpd</tt>'') instead of ``<tt>apachectl startssl</tt>'' (or
``<tt>httpd -DSSL</tt>''. Or you're configuration is not correct. At
least make sure that your ``<tt>Listen</tt>'' directives match your
``<tt><VirtualHost></tt>'' directives. And if all fails, please do
yourself a favor and start over with the default configuration mod_ssl
provides you.
<p>
<li><a name="ToC22"></a>
<a name="env-vars"></a>
<strong id="faq">
In my CGI programs and SSI scripts the various documented
<code>SSL_XXX</code> variables do not exists. Why?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#env-vars"><b>L</b></a>]
<p>
Just make sure you have ``<code>SSLOptions +StdEnvVars</code>''
enabled for the context of your CGI/SSI requests.
<p>
<li><a name="ToC23"></a>
<a name="relative-links"></a>
<strong id="faq">
How can I use relative hyperlinks to switch between HTTP and HTTPS?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#relative-links"><b>L</b></a>]
<p>
Usually you have to use fully-qualified hyperlinks because
you have to change the URL scheme. But with the help of some URL
manipulations through mod_rewrite you can achieve the same effect while
you still can use relative URLs:
<pre>
RewriteEngine on
RewriteRule ^/(.*):SSL$ https://%{SERVER_NAME}/$1 [R,L]
RewriteRule ^/(.*):NOSSL$ http://%{SERVER_NAME}/$1 [R,L]
</pre>
This rewrite ruleset lets you use hyperlinks of the form
<pre>
<a href="document.html:SSL">
</pre>
</ul>
<p>
<br>
<h2><a name="ToC24">About Certificates</a></h2>
<ul>
<p>
<li><a name="ToC25"></a>
<a name="what-is"></a>
<strong id="faq">
What are RSA Private Keys, CSRs and Certificates?</strong>
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#what-is"><b>L</b></a>]
<p>
The RSA private key file is a digital file that you can use to decrypt
messages sent to you. It has a public component which you distribute (via
your Certificate file) which allows people to encrypt those messages to
you. A Certificate Signing Request (CSR) is a digital file which contains
your public key and your name. You send the CSR to a Certifying Authority
(CA) to be converted into a real Certificate. A Certificate contains your
RSA public key, your name, the name of the CA, and is digitally signed by
your CA. Browsers that know the CA can verify the signature on that
Certificate, thereby obtaining your RSA public key. That enables them to
send messages which only you can decrypt.
See the <a href="ssl_intro.html">Introduction</a> chapter for a general
description of the SSL protocol.
<p>
<li><a name="ToC26"></a>
<a name="startup"></a>
<strong id="faq">
Seems like there is a difference on startup between the original Apache and an SSL-aware Apache?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#startup"><b>L</b></a>]
<p>
Yes, in general, starting Apache with a built-in mod_ssl is just like
starting an unencumbered Apache, except for the fact that when you have a
pass phrase on your SSL private key file. Then a startup dialog pops up
asking you to enter the pass phrase.
<p>
To type in the pass phrase manually when starting the server can be
problematic, for instance when starting the server from the system boot
scripts. As an alternative to this situation you can follow the steps
below under ``How can I get rid of the pass-phrase dialog at Apache
startup time?''.
<p>
<li><a name="ToC27"></a>
<a name="cert-dummy"></a>
<strong id="faq">
How can I create a dummy SSL server Certificate for testing purposes?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#cert-dummy"><b>L</b></a>]
<p>
A Certificate does not have to be signed by a public CA. You can use your
private key to sign the Certificate which contains your public key. You
can install this Certificate into your server, and people using Netscape
Navigator (not MSIE) will be able to connect after clicking OK to a
warning dialogue. You can get MSIE to work, and your customers can
eliminate the dialogue, by installing that Certificate manually into their
browsers.
<p>
Just use the ``<code>make certificate</code>'' command at the top-level
directory of the Apache source tree right before installing Apache via
``<code>make install</code>''. This creates a self-signed SSL Certificate
which expires after 30 days and isn't encrypted (which means you don't
need to enter a pass-phrase at Apache startup time).
<p>
BUT REMEMBER: YOU REALLY HAVE TO CREATE A REAL CERTIFICATE FOR THE LONG
RUN! HOW THIS IS DONE IS DESCRIBED IN THE NEXT ANSWER.
<p>
<li><a name="ToC28"></a>
<a name="cert-real"></a>
<strong id="faq">
Ok, I've got my server installed and want to create a real SSL
server Certificate for it. How do I do it?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#cert-real"><b>L</b></a>]
<p>
Here is a step-by-step description:
<p>
<ol>
<li>Make sure OpenSSL is really installed and in your <code>PATH</code>.
But some commands even work ok when you just run the
``<code>openssl</code>'' program from within the OpenSSL source tree as
``<code>./apps/openssl</code>''.
<p>
<li>Create a RSA private key for your Apache server
(will be Triple-DES encrypted and PEM formatted):
<p>
<code><strong>$ openssl genrsa -des3 -out server.key 1024</strong></code>
<p>
Please backup this <code>server.key</code> file and remember the
pass-phrase you had to enter at a secure location.
You can see the details of this RSA private key via the command:
<p>
<code><strong>$ openssl rsa -noout -text -in server.key</strong></code>
<p>
And you could create a decrypted PEM version (not recommended)
of this RSA private key via:
<p>
<code><strong>$ openssl rsa -in server.key -out server.key.unsecure</strong></code>
<p>
<li>Create a Certificate Signing Request (CSR) with the server RSA private
key (output will be PEM formatted):
<p>
<code><strong>$ openssl req -new -key server.key -out server.csr</strong></code>
<p>
Make sure you enter the FQDN ("Fully Qualified Domain Name") of the
server when OpenSSL prompts you for the "CommonName", i.e. when you
generate a CSR for a website which will be later accessed via
<code>https://www.foo.dom/</code>, enter "www.foo.dom" here.
You can see the details of this CSR via the command
<p>
<code><strong>$ openssl req -noout -text -in server.csr</strong></code>
<p>
<li>You now have to send this Certificate Signing Request (CSR) to
a Certifying Authority (CA) for signing. The result is then a real
Certificate which can be used for Apache. Here you have two options:
First you can let the CSR sign by a commercial CA like Verisign or
Thawte. Then you usually have to post the CSR into a web form, pay for
the signing and await the signed Certificate you then can store into a
server.crt file. For more information about commercial CAs have a look
at the following locations:
<p>
<ul>
<li> Verisign<br>
<a href="http://digitalid.verisign.com/server/apacheNotice.htm">
http://digitalid.verisign.com/server/apacheNotice.htm
</a>
<li> Thawte Consulting<br>
<a href="http://www.thawte.com/certs/server/request.html">
http://www.thawte.com/certs/server/request.html
</a>
<li> CertiSign Certificadora Digital Ltda.<br>
<a href="http://www.certisign.com.br">
http://www.certisign.com.br
</a>
<li> IKS GmbH<br>
<a href="http://www.iks-jena.de/produkte/ca/">
http://www.iks-jena.de/produkte/ca/
</a>
<li> Uptime Commerce Ltd.<br>
<a href="http://www.uptimecommerce.com">
http://www.uptimecommerce.com
</a>
<li> BelSign NV/SA<br>
<a href="http://www.belsign.be">
http://www.belsign.be
</a>
</ul>
<p>
Second you can use your own CA and now have to sign the CSR yourself by
this CA. Read the next answer in this FAQ on how to sign a CSR with
your CA yourself.
You can see the details of the received Certificate via the command:
<p>
<code><strong>$ openssl x509 -noout -text -in server.crt</strong></code>
<p>
<li>Now you have two files: <code>server.key</code> and
<code>server.crt</code>. These now can be used as following inside your
Apache's <code>httpd.conf</code> file:
<pre>
SSLCertificateFile /path/to/this/server.crt
SSLCertificateKeyFile /path/to/this/server.key
</pre>
The <code>server.csr</code> file is no longer needed.
</ol>
<p>
<li><a name="ToC29"></a>
<a name="cert-ownca"></a>
<strong id="faq">
How can I create and use my own Certificate Authority (CA)?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#cert-ownca"><b>L</b></a>]
<p>
The short answer is to use the <code>CA.sh</code> or <code>CA.pl</code>
script provided by OpenSSL. The long and manual answer is this:
<p>
<ol>
<li>Create a RSA private key for your CA
(will be Triple-DES encrypted and PEM formatted):
<p>
<code><strong>$ openssl genrsa -des3 -out ca.key 1024</strong></code>
<p>
Please backup this <code>ca.key</code> file and remember the
pass-phrase you currently entered at a secure location.
You can see the details of this RSA private key via the command
<p>
<code><strong>$ openssl rsa -noout -text -in ca.key</strong></code>
<p>
And you can create a decrypted PEM version (not recommended) of this
private key via:
<p>
<code><strong>$ openssl rsa -in ca.key -out ca.key.unsecure</strong></code>
<p>
<li>Create a self-signed CA Certificate (X509 structure)
with the RSA key of the CA (output will be PEM formatted):
<p>
<code><strong>$ openssl req -new -x509 -days 365 -key ca.key -out ca.crt</strong></code>
<p>
You can see the details of this Certificate via the command:
<p>
<code><strong>$ openssl x509 -noout -text -in ca.crt</strong></code>
<p>
<li>Prepare a script for signing which is needed because
the ``<code>openssl ca</code>'' command has some strange requirements
and the default OpenSSL config doesn't allow one easily to use
``<code>openssl ca</code>'' directly. So a script named
<code>sign.sh</code> is distributed with the mod_ssl distribution
(subdir <code>pkg.contrib/</code>). Use this script for signing.
<p>
<li>Now you can use this CA to sign server CSR's in order to create real
SSL Certificates for use inside an Apache webserver (assuming
you already have a <code>server.csr</code> at hand):
<p>
<code><strong>$ ./sign.sh server.csr</strong></code>
<p>
This signs the server CSR and results in a <code>server.crt</code> file.
</ol>
<p>
<li><a name="ToC30"></a>
<a name="change-passphrase"></a>
<strong id="faq">
How can I change the pass-phrase on my private key file?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#change-passphrase"><b>L</b></a>]
<p>
You simply have to read it with the old pass-phrase and write it again
by specifying the new pass-phrase. You can accomplish this with the following
commands:
<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>
Here you're asked two times for a PEM pass-phrase. At the first
prompt enter the old pass-phrase and at the second prompt
enter the new pass-phrase.
<p>
<li><a name="ToC31"></a>
<a name="remove-passphrase"></a>
<strong id="faq">
How can I get rid of the pass-phrase dialog at Apache startup time?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#remove-passphrase"><b>L</b></a>]
<p>
The reason why this dialog pops up at startup and every re-start
is that the RSA private key inside your server.key file is stored in
encrypted format for security reasons. The pass-phrase is needed to be
able to read and parse this file. When you can be sure that your server is
secure enough you perform two steps:
<p>
<ol>
<li>Remove the encryption from the RSA private key (while
preserving the original file):
<p>
<code><strong>$ cp server.key server.key.org</strong></code><br>
<code><strong>$ openssl rsa -in server.key.org -out server.key</strong></code>
<p>
<li>Make sure the server.key file is now only readable by root:
<p>
<code><strong>$ chmod 400 server.key</strong></code>
</ol>
<p>
Now <code>server.key</code> will contain an unencrypted copy of the key.
If you point your server at this file it will not prompt you for a
pass-phrase. HOWEVER, if anyone gets this key they will be able to
impersonate you on the net. PLEASE make sure that the permissions on that
file are really such that only root or the web server user can read it
(preferably get your web server to start as root but run as another
server, and have the key readable only by root).
<p>
As an alternative approach you can use the ``<code>SSLPassPhraseDialog
exec:/path/to/program</code>'' facility. But keep in mind that this is
neither more nor less secure, of course.
<p>
<li><a name="ToC32"></a>
<a name="verify-key"></a>
<strong id="faq">
How do I verify that a private key matches its Certificate?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#verify-key"><b>L</b></a>]
<p>
The private key contains a series of numbers. Two of those numbers form
the "public key", the others are part of your "private key". The "public
key" bits are also embedded in your Certificate (we get them from your
CSR). To check that the public key in your cert matches the public
portion of your private key, you need to view the cert and the key and
compare the numbers. To view the Certificate and the key run the
commands:
<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>
The `modulus' and the `public exponent' portions in the key and the
Certificate must match. But since the public exponent is usually 65537
and it's bothering comparing long modulus you can use the following
approach:
<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>
And then compare these really shorter numbers. With overwhelming
probability they will differ if the keys are different. BTW, if I want to
check to which key or certificate a particular CSR belongs you can compute
<p>
<code><strong>$ openssl req -noout -modulus -in server.csr | openssl md5</strong></code>
<p>
<li><a name="ToC33"></a>
<a name="keysize1"></a>
<strong id="faq">
What does it mean when my connections fail with an "alert bad certificate"
error?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#keysize1"><b>L</b></a>]
<p>
Usually when you see errors like ``<tt>OpenSSL: error:14094412: SSL
routines:SSL3_READ_BYTES:sslv3 alert bad certificate</tt>'' in the SSL
logfile, this means that the browser was unable to handle the server
certificate/private-key which perhaps contain a RSA-key not equal to 1024
bits. For instance Netscape Navigator 3.x is one of those browsers.
<p>
<li><a name="ToC34"></a>
<a name="keysize2"></a>
<strong id="faq">
Why does my 2048-bit private key not work?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#keysize2"><b>L</b></a>]
<p>
The private key sizes for SSL must be either 512 or 1024 for compatibility
with certain web browsers. A keysize of 1024 bits is recommended because
keys larger than 1024 bits are incompatible with some versions of Netscape
Navigator and Microsoft Internet Explorer, and with other browsers that
use RSA's BSAFE cryptography toolkit.
<p>
<li><a name="ToC35"></a>
<a name="hash-symlinks"></a>
<strong id="faq">
Why is client authentication broken after upgrading from
SSLeay version 0.8 to 0.9?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#hash-symlinks"><b>L</b></a>]
<p>
The CA certificates under the path you configured with
<code>SSLCACertificatePath</code> are found by SSLeay through hash
symlinks. These hash values are generated by the `<code>openssl x509 -noout
-hash</code>' command. But the algorithm used to calculate the hash for a
certificate has changed between SSLeay 0.8 and 0.9. So you have to remove
all old hash symlinks and re-create new ones after upgrading. Use the
<code>Makefile</code> mod_ssl placed into this directory.
<p>
<li><a name="ToC36"></a>
<a name="pem-to-der"></a>
<strong id="faq">
How can I convert a certificate from PEM to DER format?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#pem-to-der"><b>L</b></a>]
<p>
The default certificate format for SSLeay/OpenSSL is PEM, which actually
is Base64 encoded DER with header and footer lines. For some applications
(e.g. Microsoft Internet Explorer) you need the certificate in plain DER
format. You can convert a PEM file <code>cert.pem</code> into the
corresponding DER file <code>cert.der</code> with the following command:
<code><strong>$ openssl x509 -in cert.pem -out cert.der -outform DER</strong></code>
<p>
<li><a name="ToC37"></a>
<a name="verisign-getca"></a>
<strong id="faq">
I try to install a Verisign certificate. Why can't I find neither the
<code>getca</code> nor <code>getverisign</code> programs Verisign mentions?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#verisign-getca"><b>L</b></a>]
<p>
This is because Verisign has never provided specific instructions
for Apache+mod_ssl. Rather they tell you what you should do
if you were using C2Net's Stronghold (a commercial Apache
based server with SSL support). The only thing you have to do
is to save the certificate into a file and give the name of
that file to the <code>SSLCertificateFile</code> directive.
Remember that you need to give the key file in as well (see
<code>SSLCertificateKeyFile</code> directive). For a better
CA-related overview on SSL certificate fiddling you can look at <a
href="http://www.thawte.com/certs/server/keygen/mod_ssl.html">
Thawte's mod_ssl instructions</a>.
<p>
<li><a name="ToC38"></a>
<a name="gid"></a>
<strong id="faq">
Can I use the Server Gated Cryptography (SGC) facility (aka Verisign Global
ID) also with mod_ssl?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#gid"><b>L</b></a>]
<p>
Yes, mod_ssl since version 2.1 supports the SGC facility. You don't have
to configure anything special for this, just use a Global ID as your
server certificate. The <i>step up</i> of the clients are then
automatically handled by mod_ssl under run-time. For details please read
the <tt>README.GlobalID</tt> document in the mod_ssl distribution.
<p>
<li><a name="ToC39"></a>
<a name="gid"></a>
<strong id="faq">
After I have installed my new Verisign Global ID server certificate, the
browsers complain that they cannot verify the server certificate?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#gid"><b>L</b></a>]
<p>
That is because Verisign uses an intermediate CA certificate between
the root CA certificate (which is installed in the browsers) and
the server certificate (which you installed in the server). You
should have received this additional CA certificate from Verisign.
If not, complain to them. Then configure this certificate with the
<code>SSLCertificateChainFile</code> directive in the server. This
makes sure the intermediate CA certificate is send to the browser
and this way fills the gap in the certificate chain.
</ul>
<p>
<br>
<h2><a name="ToC40">About SSL Protocol</a></h2>
<ul>
<p>
<li><a name="ToC41"></a>
<a name="random-errors"></a>
<strong id="faq">
Why do I get lots of random SSL protocol errors under heavy server load?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#random-errors"><b>L</b></a>]
<p>
There can be a number of reasons for this, but the main one
is problems with the SSL session Cache specified by the
<tt>SSLSessionCache</tt> directive. The DBM session cache is most
likely the source of the problem, so trying the SHM session cache or
no cache at all may help.
<p>
<li><a name="ToC42"></a>
<a name="load"></a>
<strong id="faq">
Why has my webserver a higher load now that I run SSL there?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#load"><b>L</b></a>]
<p>
Because SSL uses strong cryptographic encryption and this needs a lot of
number crunching. And because when you request a webpage via HTTPS even
the images are transferred encrypted. So, when you have a lot of HTTPS
traffic the load increases.
<p>
<li><a name="ToC43"></a>
<a name="random"></a>
<strong id="faq">
Often HTTPS connections to my server require up to 30 seconds for establishing
the connection, although sometimes it works faster?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#random"><b>L</b></a>]
<p>
Usually this is caused by using a <code>/dev/random</code> device for
<code>SSLRandomSeed</code> which is blocking in read(2) calls if not
enough entropy is available. Read more about this problem in the refernce
chapter under <code>SSLRandomSeed</code>.
<p>
<li><a name="ToC44"></a>
<a name="ciphers"></a>
<strong id="faq">
What SSL Ciphers are supported by mod_ssl?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#ciphers"><b>L</b></a>]
<p>
Usually just all SSL ciphers which are supported by the
version of OpenSSL in use (can depend on the way you built
OpenSSL). Typically this at least includes the following:
<p>
<ul>
<li>RC4 with MD5
<li>RC4 with MD5 (export version restricted to 40-bit key)
<li>RC2 with MD5
<li>RC2 with MD5 (export version restricted to 40-bit key)
<li>IDEA with MD5
<li>DES with MD5
<li>Triple-DES with MD5
</ul>
<p>
To determine the actual list of supported ciphers you can
run the following command:
<p>
<code><strong>$ openssl ciphers -v</strong></code><br>
<p>
<li><a name="ToC45"></a>
<a name="cipher-adh"></a>
<strong id="faq">
I want to use Anonymous Diffie-Hellman (ADH) ciphers, but I always get ``no
shared cipher'' errors?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#cipher-adh"><b>L</b></a>]
<p>
In order to use Anonymous Diffie-Hellman (ADH) ciphers, it is not enough
to just put ``<code>ADH</code>'' into your <code>SSLCipherSuite</code>.
Additionally you have to build OpenSSL with
``<code>-DSSL_ALLOW_ADH</code>''. Because per default OpenSSL does not
allow ADH ciphers for security reasons. So if you are actually enabling
these ciphers make sure you are informed about the side-effects.
<p>
<li><a name="ToC46"></a>
<a name="cipher-shared"></a>
<strong id="faq">
I always just get a 'no shared ciphers' error if
I try to connect to my freshly installed server?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#cipher-shared"><b>L</b></a>]
<p>
Either you have messed up your <code>SSLCipherSuite</code>
directive (compare it with the pre-configured example in
<code>httpd.conf</code>) or you have choosen the DSA/DH
algorithms instead of RSA under "<code>make certificate</code>"
and ignored or overseen the warnings. Because if you have choosen
DSA/DH, then your server no longer speaks RSA-based SSL ciphers
(at least not until you also configure an additional RSA-based
certificate/key pair). But current browsers like NS or IE only speak
RSA ciphers. The result is the "no shared ciphers" error. To fix
this, regenerate your server certificate/key pair and this time
choose the RSA algorithm.
<p>
<li><a name="ToC47"></a>
<a name="vhosts"></a>
<strong id="faq">
Why can't I use SSL with name-based/non-IP-based virtual hosts?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#vhosts"><b>L</b></a>]
<p>
The reason is very technical. Actually it's some sort of a chicken and
egg problem: The SSL protocol layer stays below the HTTP protocol layer
and encapsulates HTTP. When an SSL connection (HTTPS) is established
Apache/mod_ssl has to negotiate the SSL protocol parameters with the
client. For this mod_ssl has to consult the configuration of the virtual
server (for instance it has to look for the cipher suite, the server
certificate, etc.). But in order to dispatch to the correct virtual server
Apache has to know the <code>Host</code> HTTP header field. For this the
HTTP request header has to be read. This cannot be done before the SSL
handshake is finished. But the information is already needed at the SSL
handshake phase. Bingo!
<p>
<li><a name="ToC48"></a>
<a name="lock-icon"></a>
<strong id="faq">
When I use Basic Authentication over HTTPS the lock icon in Netscape browsers
still show the unlocked state when the dialog pops up. Does this mean the
username/password is still transmitted unencrypted?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#lock-icon"><b>L</b></a>]
<p>
No, the username/password is already transmitted encrypted. The icon in
Netscape browsers is just not really synchronized with the SSL/TLS layer
(it toggles to the locked state when the first part of the actual webpage
data is transferred which is not quite correct) and this way confuses
people. The Basic Authentication facility is part of the HTTP layer and
this layer is above the SSL/TLS layer in HTTPS. And before any HTTP data
communication takes place in HTTPS the SSL/TLS layer has already done the
handshake phase and switched to encrypted communication. So, don't get
confused by this icon.
<p>
<li><a name="ToC49"></a>
<a name="io-ie"></a>
<strong id="faq">
When I connect via HTTPS to an Apache+mod_ssl+OpenSSL server with Microsoft Internet
Explorer (MSIE) I get various I/O errors. What is the reason?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#io-ie"><b>L</b></a>]
<p>
The first reason is that the SSL implementation in some MSIE versions has
some subtle bugs related to the HTTP keep-alive facility and the SSL close
notify alerts on socket connection close. Additionally the interaction
between SSL and HTTP/1.1 features are problematic with some MSIE versions,
too. You've to work-around these problems by forcing
Apache+mod_ssl+OpenSSL to not use HTTP/1.1, keep-alive connections or
sending the SSL close notify messages to MSIE clients. This can be done by
using the following directive in your SSL-aware virtual host section:
<pre>
SetEnvIf User-Agent ".*MSIE.*" \
<b>nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0</b></pre>
Additionally it is known some MSIE versions have also problems
with particular ciphers. Unfortunately one cannot workaround these
bugs only for those MSIE particular clients, because the ciphers
are already used in the SSL handshake phase. So a MSIE-specific
<tt>SetEnvIf</tt> doesn't work to solve these problems. Instead one
has to do more drastic adjustments to the global parameters. But
before you decide to do this, make sure your clients really have
problems. If not, do not do this, because it affects all(!) your
clients, i.e., also your non-MSIE clients.
<p>
The next problem is that 56bit export versions of MSIE 5.x browsers have a
broken SSLv3 implementation which badly interacts with OpenSSL versions
greater than 0.9.4. You can either accept this and force your clients to
upgrade their browsers, or you downgrade to OpenSSL 0.9.4 (hmmm), or you
can decide to workaround it by accepting the drawback that your workaround
will horribly affect also other browsers:
<pre>
SSLProtocol all <b>-SSLv3</b></pre>
This completely disables the SSLv3 protocol and lets those browsers work.
But usually this is an even less acceptable workaround. A more reasonable
workaround is to address the problem more closely and disable only the
ciphers which cause trouble.
<pre>
SSLCipherSuite ALL:!ADH:<b>!EXPORT56</b>:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP</pre>
This also lets the broken MSIE versions work, but only removes the
newer 56bit TLS ciphers.
<p>
Another problem with MSIE 5.x clients is that they refuse to connect to
URLs of the form <tt>https://12.34.56.78/</tt> (IP-addresses are used
instead of the hostname), if the server is using the Server Gated
Cryptography (SGC) facility. This can only be avoided by using the fully
qualified domain name (FQDN) of the website in hyperlinks instead, because
MSIE 5.x has an error in the way it handles the SGC negotiation.
<p>
And finally there are versions of MSIE which seem to require that
an SSL session can be reused (a totally non standard-conforming
behaviour, of course). Connection with those MSIE versions only work
if a SSL session cache is used. So, as a work-around, make sure you
are using a session cache (see <tt>SSLSessionCache</tt> directive).
<p>
<li><a name="ToC50"></a>
<a name="io-ns"></a>
<strong id="faq">
When I connect via HTTPS to an Apache+mod_ssl server with Netscape Navigator I
get I/O errors and the message "Netscape has encountered bad data from the
server" What's the reason?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#io-ns"><b>L</b></a>]
<p>
The problem usually is that you had created a new server certificate with
the same DN, but you had told your browser to accept forever the old
server certificate. Once you clear the entry in your browser for the old
certificate, everything usually will work fine. Netscape's SSL
implementation is correct, so when you encounter I/O errors with Netscape
Navigator it is most of the time caused by the configured certificates.
</ul>
<p>
<br>
<h2><a name="ToC51">About Support</a></h2>
<ul>
<p>
<li><a name="ToC52"></a>
<a name="resources"></a>
<strong id="faq">
What information resources are available in case of mod_ssl problems?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#resources"><b>L</b></a>]
<p>
The following information resources are available.
In case of problems you should search here first.
<p>
<ol>
<li><em>Answers in the User Manual's F.A.Q. List (this)</em><br>
<a href="http://www.modssl.org/docs/2.8/ssl_faq.html">
http://www.modssl.org/docs/2.8/ssl_faq.html</a><br>
First look inside the F.A.Q. (this text), perhaps your problem is such
popular that it was already answered a lot of times in the past.
<p>
<li><em>Postings from the modssl-users Support Mailing List</em>
<a href="http://www.modssl.org/support/">
http://www.modssl.org/support/</a><br>
Second search for your problem in one of the existing archives of the
modssl-users mailing list. Perhaps your problem popped up at least once for
another user, too.
<p>
<li><em>Problem Reports in the Bug Database</em>
<a href="http://www.modssl.org/support/bugdb/">
http://www.modssl.org/support/bugdb/</a><br>
Third look inside the mod_ssl Bug Database. Perhaps
someone else already has reported the problem.
</ol>
<p>
<li><a name="ToC53"></a>
<a name="contact"></a>
<strong id="faq">
What support contacts are available in case of mod_ssl problems?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#contact"><b>L</b></a>]
<p>
The following lists all support possibilities for mod_ssl, in order of
preference, i.e. start in this order and do not pick the support possibility
you just like most, please.
<p>
<ol>
<li><em>Write a Problem Report into the Bug Database</em><br>
<a href="http://www.modssl.org/support/bugdb/">
http://www.modssl.org/support/bugdb/</a><br>
This is the preferred way of submitting your problem report, because this
way it gets filed into the bug database (it cannot be lost) <em>and</em>
send to the modssl-users mailing list (others see the current problems and
learn from answers).
<p>
<li><em>Write a Problem Report to the modssl-users Support Mailing List</em><br>
<a href="mailto:modssl-users@modssl.org">
modssl-users @ modssl.org</a><br>
This is the second way of submitting your problem report. You have to
subscribe to the list first, but then you can easily discuss your problem
with both the author and the whole mod_ssl user community.
<p>
<li><em>Write a Problem Report to the author</em><br>
<a href="mailto:rse@engelschall.com">
rse @ engelschall.com</a><br>
This is the last way of submitting your problem report. Please avoid this
in your own interest because the author is really a very busy men. Your
mail will always be filed to one of his various mail-folders and is
usually not processed as fast as a posting on modssl-users.
</ol>
<p>
<li><a name="ToC54"></a>
<a name="report-details"></a>
<strong id="faq">
What information and details I've to provide to
the author when writing a bug report?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#report-details"><b>L</b></a>]
<p>
You have to at least always provide the following information:
<p>
<ul>
<li><em>Apache, mod_ssl and OpenSSL version information</em><br>
The mod_ssl version you should really know. For instance, it's the version
number in the distribution tarball. The Apache version can be determined
by running ``<code>httpd -v</code>''. The OpenSSL version can be
determined by running ``<code>openssl version</code>''. Alternatively when
you have Lynx installed you can run the command ``<code>lynx -mime_header
http://localhost/ | grep Server</code>'' to determine all information in a
single step.
<p>
<li><em>The details on how you built and installed Apache+mod_ssl+OpenSSL</em><br>
For this you can provide a logfile of your terminal session which shows
the configuration and install steps. Alternatively you can at least
provide the author with the APACI `<code>configure</code>'' command line
you used (assuming you used APACI, of course).
<p>
<li><em>In case of core dumps please include a Backtrace</em><br>
In case your Apache+mod_ssl+OpenSSL should really dumped core please attach
a stack-frame ``backtrace'' (see the next question on how to get it).
Without this information the reason for your core dump cannot be found.
So you have to provide the backtrace, please.
<p>
<li><em>A detailed description of your problem</em><br>
Don't laugh, I'm totally serious. I already got a lot of problem reports
where the people not really said what's the actual problem is. So, in your
own interest (you want the problem be solved, don't you?) include as much
details as possible, please. But start with the essentials first, of
course.
</ul>
<p>
<li><a name="ToC55"></a>
<a name="core-dumped"></a>
<strong id="faq">
I got a core dump, can you help me?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#core-dumped"><b>L</b></a>]
<p>
In general no, at least not unless you provide more details about the code
location where Apache dumped core. What is usually always required in
order to help you is a backtrace (see next question). Without this
information it is mostly impossible to find the problem and help you in
fixing it.
<p>
<li><a name="ToC56"></a>
<a name="report-backtrace"></a>
<strong id="faq">
Ok, I got a core dump but how do I get a backtrace to find out the reason for it?
</strong>
[<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#report-backtrace"><b>L</b></a>]
<p>
Follow the following steps:
<p>
<ol>
<li>Make sure you have debugging symbols available in at least
Apache and mod_ssl. On platforms where you use GCC/GDB you have to build
Apache+mod_ssl with ``<code>OPTIM="-g -ggdb3"</code>'' to achieve this. On
other platforms at least ``<code>OPTIM="-g"</code>'' is needed.
<p>
<li>Startup the server and try to produce the core-dump. For this you perhaps
want to use a directive like ``<code>CoreDumpDirectory /tmp</code>'' to
make sure that the core-dump file can be written. You then should get a
<code>/tmp/core</code> or <code>/tmp/httpd.core</code> file. When you
don't get this, try to run your server under an UID != 0 (root), because
most "current" kernels do not allow a process to dump core after it has
done a <code>setuid()</code> (unless it does an <code>exec()</code>) for
security reasons (there can be privileged information left over in
memory). Additionally you can run ``<code>/path/to/httpd -X</code>''
manually to force Apache to not fork.
<p>
<li>Analyze the core-dump. For this run ``<code>gdb /path/to/httpd
/tmp/httpd.core</code>'' or a similar command has to run. In GDB you then
just have to enter the ``<code>bt</code>'' command and, voila, you get the
backtrace. For other debuggers consult your local debugger manual. Send
this backtrace to the author.
</ol>
</ul>
<p>
<br>
<table summary="">
<tr>
<td>
<table width="600" border="0" summary="">
<tr>
<td valign="top" align="left" width="250">
<a href="ssl_howto.html" onmouseover="ro_imgOver('ro_img_prev_bot', 'previous page'); return true" onmouseout="ro_imgNormal('ro_img_prev_bot'); return true" onfocus="ro_imgOver('ro_img_prev_bot', 'previous page'); return true" onblur="ro_imgNormal('ro_img_prev_bot'); return true"><img name="ro_img_prev_bot" src="ssl_template.navbut-prev-n.gif" alt="previous page" width="70" height="18" border="0"></a><br><font color="#000000">HowTo</font>
</td>
<td valign="top" align="right" width="250">
<a href="ssl_glossary.html" onmouseover="ro_imgOver('ro_img_next_bot', 'next page'); return true" onmouseout="ro_imgNormal('ro_img_next_bot'); return true" onfocus="ro_imgOver('ro_img_next_bot', 'next page'); return true" onblur="ro_imgNormal('ro_img_next_bot'); return true"><img name="ro_img_next_bot" src="ssl_template.navbut-next-n.gif" alt="next page" width="70" height="18" border="0"></a><br><font color="#000000">Glossary</font>
</td>
</tr>
</table>
</td>
</tr>
<tr>
<td><img src="ssl_template.imgdot-1x1-000000.gif" alt="" width="600" height="2" align="bottom" border="0"></td>
</tr>
<tr>
<td><table width="598" summary="">
<tr>
<td align="left"><font face="Arial,Helvetica">
<a href="http://www.modssl.org/">mod_ssl</a> 2.8, User Manual<br>
The Apache Interface to OpenSSL
</font>
</td>
<td align="right"><font face="Arial,Helvetica">
Copyright © 1998-2001
<a href="http://www.engelschall.com/">Ralf S. Engelschall</a><br>
All Rights Reserved<br>
</font>
</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
</table>
</div>
</body>
</html>
|
