1<html> 2<head> 3<title>mod_ssl: F.A.Q.</title> 4 5<!-- 6 Copyright (c) 1998-2001 Ralf S. Engelschall. All rights reserved. 7 8 Redistribution and use in source and binary forms, with or without 9 modification, are permitted provided that the following conditions 10 are met: 11 12 1. Redistributions of source code must retain the above 13 copyright notice, this list of conditions and the following 14 disclaimer. 15 16 2. Redistributions in binary form must reproduce the above 17 copyright notice, this list of conditions and the following 18 disclaimer in the documentation and/or other materials 19 provided with the distribution. 20 21 3. All advertising materials mentioning features or use of this 22 software must display the following acknowledgment: 23 "This product includes software developed by 24 Ralf S. Engelschall <rse@engelschall.com> for use in the 25 mod_ssl project (http://www.modssl.org/)." 26 27 4. The name "mod_ssl" must not be used to endorse or promote 28 products derived from this software without prior written 29 permission. 30 31 5. Redistributions of any form whatsoever must retain the 32 following acknowledgment: 33 "This product includes software developed by 34 Ralf S. Engelschall <rse@engelschall.com> for use in the 35 mod_ssl project (http://www.modssl.org/)." 36 37 THIS SOFTWARE IS PROVIDED BY RALF S. ENGELSCHALL ``AS IS'' AND ANY 38 EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 39 IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 40 PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL RALF S. ENGELSCHALL OR 41 HIS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 42 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT 43 NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; 44 LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 45 HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, 46 STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) 47 ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED 48 OF THE POSSIBILITY OF SUCH DAMAGE. 49--> 50<style type="text/css"><!-- 51A:link { 52 text-decoration: none; 53 color: #6666cc; 54} 55A:active { 56 text-decoration: none; 57 color: #6666cc; 58} 59A:visited { 60 text-decoration: none; 61 color: #6666cc; 62} 63#sf { 64 font-family: arial,helvetica; 65 font-variant: normal; 66 font-style: normal; 67} 68H1 { 69 font-weight: bold; 70 font-size: 24pt; 71 line-height: 24pt; 72 font-family: arial,helvetica; 73 font-variant: normal; 74 font-style: normal; 75} 76H2 { 77 font-weight: bold; 78 font-size: 18pt; 79 line-height: 18pt; 80 font-family: arial,helvetica; 81 font-variant: normal; 82 font-style: normal; 83} 84H3 { 85 font-weight: bold; 86 font-size: 14pt; 87 line-height: 14pt; 88 font-family: arial,helvetica; 89 font-variant: normal; 90 font-style: normal; 91} 92H4 { 93 font-weight: bold; 94 font-size: 12pt; 95 line-height: 12pt; 96 font-family: arial,helvetica; 97 font-variant: normal; 98 font-style: normal; 99} 100#H { 101} 102#D { 103 background-color: #f0f0f0; 104} 105#faq { 106 font-weight: bold; 107 font-size: 16pt; 108 line-height: 16pt; 109 font-family: arial,helvetica; 110 font-variant: normal; 111 font-style: normal; 112} 113#howto { 114 font-weight: bold; 115 font-size: 16pt; 116 line-height: 16pt; 117 font-family: arial,helvetica; 118 font-variant: normal; 119 font-style: normal; 120} 121#term { 122 font-weight: bold; 123 font-size: 16pt; 124 line-height: 16pt; 125 font-family: arial,helvetica; 126 font-variant: normal; 127 font-style: normal; 128} 129--></style> 130<script type="text/javascript" language="JavaScript"> 131<!-- Hiding the code 132function ro_imgNormal(imgName) { 133 if (document.images) { 134 document[imgName].src = eval(imgName + '_n.src'); 135 self.status = ''; 136 } 137} 138function ro_imgOver(imgName, descript) { 139 if (document.images) { 140 document[imgName].src = eval(imgName + '_o.src'); 141 self.status = descript; 142 } 143} 144// done hiding --> 145</script> 146<script type="text/javascript" language="JavaScript"> 147<!-- Hiding the code 148if (document.images) { 149 ro_img_prev_top_n = new Image(); 150 ro_img_prev_top_n.src = 'ssl_template.navbut-prev-n.gif'; 151 ro_img_prev_top_o = new Image(); 152 ro_img_prev_top_o.src = 'ssl_template.navbut-prev-s.gif'; 153} 154// done hiding --> 155</script> 156<script type="text/javascript" language="JavaScript"> 157<!-- Hiding the code 158if (document.images) { 159 ro_img_prev_bot_n = new Image(); 160 ro_img_prev_bot_n.src = 'ssl_template.navbut-prev-n.gif'; 161 ro_img_prev_bot_o = new Image(); 162 ro_img_prev_bot_o.src = 'ssl_template.navbut-prev-s.gif'; 163} 164// done hiding --> 165</script> 166<script type="text/javascript" language="JavaScript"> 167<!-- Hiding the code 168if (document.images) { 169 ro_img_next_top_n = new Image(); 170 ro_img_next_top_n.src = 'ssl_template.navbut-next-n.gif'; 171 ro_img_next_top_o = new Image(); 172 ro_img_next_top_o.src = 'ssl_template.navbut-next-s.gif'; 173} 174// done hiding --> 175</script> 176<script type="text/javascript" language="JavaScript"> 177<!-- Hiding the code 178if (document.images) { 179 ro_img_next_bot_n = new Image(); 180 ro_img_next_bot_n.src = 'ssl_template.navbut-next-n.gif'; 181 ro_img_next_bot_o = new Image(); 182 ro_img_next_bot_o.src = 'ssl_template.navbut-next-s.gif'; 183} 184// done hiding --> 185</script> 186</head> 187<body bgcolor="#ffffff" text="#000000" link="#333399" alink="#9999ff" vlink="#000066"> 188<div align="center"> 189<table width="600" cellspacing="0" cellpadding="0" border="0" summary=""> 190<tr> 191 <td> 192 <img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="600" height="1" align="bottom" border="0"><br> 193 <table width="600" cellspacing="0" cellpadding="0" summary=""> 194 <tr> 195 <td> 196 <table width="600" summary=""> 197 <tr> 198 <td align="left" valign="bottom"> 199 <font face="Arial,Helvetica" size="+2"><b>mod_ssl</b></font> 200 </td> 201 <td align="right"> 202 <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"> 203 </td> 204 </tr> 205 </table> 206 </td> 207 </tr> 208 <tr> 209 <td><img src="ssl_template.imgdot-1x1-000000.gif" alt="" width="600" height="2" align="bottom" border="0"></td> 210 </tr> 211 <tr> 212 <td> 213 <table width="600" border="0" summary=""> 214 <tr> 215 <td valign="top" align="left" width="250"> 216<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> 217 </td> 218 <td valign="top" align="right" width="250"> 219<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> 220 </td> 221 </tr> 222 </table> 223 </td> 224 </tr> 225 <tr> 226 <td> 227 <br> 228 <img src="ssl_template.title-faq.gif" alt="F.A.Q." width="456" height="60"> 229 </td> 230 </tr> 231 </table> 232<div align="right"> 233<table cellspacing="0" cellpadding="0" width="200" summary=""> 234<tr> 235<td> 236<em> 237``The wise man doesn't give the right answers, 238he poses the right questions.'' 239</em> 240</td> 241</tr> 242<tr> 243<td align="right"> 244<font size="-1"> 245Claude Levi-Strauss 246</font> 247</td> 248</tr> 249</table> 250</div> 251<p> 252<table cellspacing="0" cellpadding="0" border="0" summary=""> 253<tr valign="bottom"> 254<td> 255<img src="ssl_faq.gfont000.gif" alt="T" width="34" height="34" border="0" align="left"> 256his chapter is a collection of frequently asked questions (FAQ) and 257corresponding answers following the popular USENET tradition. Most of these 258questions occured on the Newsgroup <a 259href="news:comp.infosystems.www.servers.unix"> 260<code>comp.infosystems.www.servers.unix</code></a> or the mod_ssl Support 261Mailing List <a href="mailto:modssl-users@modssl.org"> 262<code>modssl-users@modssl.org</code></a>. They are collected at this place 263to avoid answering the same questions over and over. 264<p> 265Please read this chapter at least once when installing mod_ssl or at least 266search for your problem here before submitting a problem report to the 267author. 268</td> 269<td> 270 271</td> 272<td> 273<div align="right"> 274<table cellspacing="0" cellpadding="5" border="0" bgcolor="#ccccff" width="350" summary=""> 275<tr> 276<td bgcolor="#333399"> 277<font face="Arial,Helvetica" color="#ccccff"> 278<b>Table Of Contents</b> 279</font> 280</td> 281</tr> 282<tr> 283<td> 284<font face="Arial,Helvetica" size="-1"> 285 <a href="#ToC1"><strong>About the module</strong></a><br> 286 <a href="#ToC2"><strong>What is the history of mod_ssl?</strong></a><br> 287 <a href="#ToC3"><strong>Apache-SSL vs. mod_ssl: differences?</strong></a><br> 288 <a href="#ToC4"><strong>mod_ssl vs. commercial alternatives?</strong></a><br> 289 <a href="#ToC5"><strong>mod_ssl/Apache versions?</strong></a><br> 290 <a href="#ToC6"><strong>mod_ssl and Year 2000?</strong></a><br> 291 <a href="#ToC7"><strong>mod_ssl and Wassenaar Arrangement?</strong></a><br> 292 <a href="#ToC8"><strong>About Installation</strong></a><br> 293 <a href="#ToC9"><strong>Core dumps for HTTPS requests?</strong></a><br> 294 <a href="#ToC10"><strong>Core dumps for Apache+mod_ssl+PHP3?</strong></a><br> 295 <a href="#ToC11"><strong>Undefined symbols on startup?</strong></a><br> 296 <a href="#ToC12"><strong>Permission problem on SSLMutex</strong></a><br> 297 <a href="#ToC13"><strong>Shared memory and process size?</strong></a><br> 298 <a href="#ToC14"><strong>Shared memory and pathname?</strong></a><br> 299 <a href="#ToC15"><strong>PRNG and not enough entropy?</strong></a><br> 300 <a href="#ToC16"><strong>About Configuration</strong></a><br> 301 <a href="#ToC17"><strong>HTTP and HTTPS with a single server?</strong></a><br> 302 <a href="#ToC18"><strong>Where is the HTTPS port?</strong></a><br> 303 <a href="#ToC19"><strong>How to test HTTPS manually?</strong></a><br> 304 <a href="#ToC20"><strong>Why does my connection hang?</strong></a><br> 305 <a href="#ToC21"><strong>Why do I get connection refused?</strong></a><br> 306 <a href="#ToC22"><strong>Why are the SSL_XXX variables missing?</strong></a><br> 307 <a href="#ToC23"><strong>How to switch with relative hyperlinks?</strong></a><br> 308 <a href="#ToC24"><strong>About Certificates</strong></a><br> 309 <a href="#ToC25"><strong>What are Keys, CSRs and Certs?</strong></a><br> 310 <a href="#ToC26"><strong>Difference on startup?</strong></a><br> 311 <a href="#ToC27"><strong>How to create a dummy cert?</strong></a><br> 312 <a href="#ToC28"><strong>How to create a real cert?</strong></a><br> 313 <a href="#ToC29"><strong>How to create my own CA?</strong></a><br> 314 <a href="#ToC30"><strong>How to change a pass phrase?</strong></a><br> 315 <a href="#ToC31"><strong>How to remove a pass phrase?</strong></a><br> 316 <a href="#ToC32"><strong>How to verify a key/cert pair?</strong></a><br> 317 <a href="#ToC33"><strong>Bad Certificate Error?</strong></a><br> 318 <a href="#ToC34"><strong>Why does a 2048-bit key not work?</strong></a><br> 319 <a href="#ToC35"><strong>Why is client auth broken?</strong></a><br> 320 <a href="#ToC36"><strong>How to convert from PEM to DER?</strong></a><br> 321 <a href="#ToC37"><strong>Verisign and the magic getca program?</strong></a><br> 322 <a href="#ToC38"><strong>Global IDs or SGC?</strong></a><br> 323 <a href="#ToC39"><strong>Global IDs and Cert Chain?</strong></a><br> 324 <a href="#ToC40"><strong>About SSL Protocol</strong></a><br> 325 <a href="#ToC41"><strong>Random SSL errors under heavy load?</strong></a><br> 326 <a href="#ToC42"><strong>Why has the server a higher load?</strong></a><br> 327 <a href="#ToC43"><strong>Why are connections horribly slow?</strong></a><br> 328 <a href="#ToC44"><strong>Which ciphers are supported?</strong></a><br> 329 <a href="#ToC45"><strong>How to use Anonymous-DH ciphers</strong></a><br> 330 <a href="#ToC46"><strong>Why do I get 'no shared ciphers'?</strong></a><br> 331 <a href="#ToC47"><strong>HTTPS and name-based vhosts</strong></a><br> 332 <a href="#ToC48"><strong>The lock icon in Netscape locks very late</strong></a><br> 333 <a href="#ToC49"><strong>Why do I get I/O errors with MSIE clients?</strong></a><br> 334 <a href="#ToC50"><strong>Why do I get I/O errors with NS clients?</strong></a><br> 335 <a href="#ToC51"><strong>About Support</strong></a><br> 336 <a href="#ToC52"><strong>Resources in case of problems?</strong></a><br> 337 <a href="#ToC53"><strong>Support in case of problems?</strong></a><br> 338 <a href="#ToC54"><strong>How to write a problem report?</strong></a><br> 339 <a href="#ToC55"><strong>I got a core dump, can you help me?</strong></a><br> 340 <a href="#ToC56"><strong>How to get a backtrace?</strong></a><br> 341</font> 342</td> 343</tr> 344</table> 345</div> 346</td> 347</tr> 348</table> 349<h2><a name="ToC1">About the module</a></h2> 350<ul> 351<p> 352<li><a name="ToC2"></a> 353 <a name="history"></a> 354 <strong id="faq"> 355What is the history of mod_ssl? 356</strong> 357 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#history"><b>L</b></a>] 358 <p> 359 The mod_ssl v1 package was initially created in April 1998 by <a 360 href="mailto:rse@engelschall.com">Ralf S. Engelschall</a> via porting <a 361 href="mailto:ben@algroup.co.uk">Ben Laurie</a>'s <a 362 href="http://www.apache-ssl.org/">Apache-SSL</a> 1.17 source patches for 363 Apache 1.2.6 to Apache 1.3b6. Because of conflicts with Ben 364 Laurie's development cycle it then was re-assembled from scratch for 365 Apache 1.3.0 by merging the old mod_ssl 1.x with the newer Apache-SSL 366 1.18. From this point on mod_ssl lived its own life as mod_ssl v2. The 367 first publically released version was mod_ssl 2.0.0 from August 10th, 368 1998. As of this writing (August 1999) the current mod_ssl version is 2.4.0. 369 <p> 370 After one year of very active development with over 1000 working hours and 371 over 40 releases mod_ssl reached its current state. The result is an 372 already very clean source base implementing a very rich functionality. 373 The code size increased by a factor of 4 to currently a total of over 374 10.000 lines of ANSI C consisting of approx. 70% code and 30% code 375 documentation. From the original Apache-SSL code currently approx. 5% is 376 remaining only. 377<p> 378<li><a name="ToC3"></a> 379 <a name="apssl-diff"></a> 380 <strong id="faq"> 381What are the functional differences between mod_ssl and Apache-SSL, from where 382it is originally derived? 383</strong> 384 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#apssl-diff"><b>L</b></a>] 385 <p> 386 This neither can be answered in short (there were too many code changes) 387 nor can be answered at all by the author (there would immediately be flame 388 wars with no reasonable results at the end). But as you easily can guess 389 from the 5% of remaining Apache-SSL code, a lot of differences exists, 390 although user-visible backward compatibility exists for most things. 391 <p> 392 When you really want a detailed comparison you have to read the entries in 393 the large <code>CHANGES</code> file that is in the mod_ssl 394 distribution. Usually this is much too hard-core. So I recommend you to 395 either believe in the opinion and recommendations of other users (the 396 simplest approach) or do a comparison yourself (the most reasonable 397 approach). For the latter, grab distributions of mod_ssl (from <a 398 href="http://www.modssl.org/">http://www.modssl.org</a>) and Apache-SSL 399 (from <a href="http://www.apache-ssl.org/">http://www.apache-ssl.org</a>), 400 install both packages, read their documentation and try them out yourself. 401 Then choose the one which pleases you most. 402 <p> 403 A few final hints to help direct your comparison: quality of documentation 404 ("can you easily find answers and are they sufficient?"), quality of 405 source code ("is the source code reviewable so you can make sure there 406 aren't any trapdoors or inherent security risks because of bad programming 407 style?"), easy and clean installation ("can the SSL functionality easily 408 added to an Apache source tree without manual editing or patching?"), 409 clean integration into Apache ("is the SSL functionality encapsulated and 410 cleanly separated from the remaining Apache functionality?"), support for 411 Dynamic Shared Object (DSO) facility ("can the SSL functionality built as 412 a separate DSO for maximum flexibility?"), Win32 port ("is the SSL 413 functionality available also under the Win32 platform?"), amount and 414 quality of functionality ("is the provided SSL functionality and control 415 possibilities sufficient for your situation?"), quality of problem tracing 416 ("is it possible for you to easily trace down the problems via logfiles, 417 etc?"), etc. pp. 418<p> 419<li><a name="ToC4"></a> 420 <a name="apssl-diff"></a> 421 <strong id="faq"> 422What are the major differences between mod_ssl and 423the commercial alternatives like Raven or Stronghold? 424</strong> 425 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#apssl-diff"><b>L</b></a>] 426 <p> 427 In the past (until September 20th, 2000) the major difference was 428 the RSA license which one received (very cheaply in contrast to 429 a direct licensing from RSA DSI) with the commercial Apache SSL 430 products. On the other hand, one needed this license only in the US, 431 of course. So for non-US citizens this point was useless. But now 432 even for US citizens the situations changed because the RSA patent 433 expired on September 20th, 2000 and RSA DSI also placed the RSA 434 algorithm explicitly into the public domain. 435 <p> 436 Second, there is the point that one has guaranteed support from 437 the commercial vendors. On the other hand, if you monitored the 438 Open Source quality of mod_ssl and the support activities 439 found on <a href="mailto:modssl-users@modssl.org"> 440 <code>modssl-users@modssl.org</code></a>, you could ask yourself 441 whether you are really convinced that you can get better support 442 from a commercial vendor. 443 <p> 444 Third, people often think they would receive perhaps at least a 445 better technical SSL solution than mod_ssl from the commercial 446 vendors. But this is not really true, because all commercial 447 alternatives (Raven 1.4.x, Stronghold 3.x, RedHat SWS 2.x, etc.) 448 <i>are</i> actually based on mod_ssl and OpenSSL. The reason for 449 this common misunderstanding is mainly because some vendors make no 450 attempt to make it reasonably clear that their product is actually 451 mod_ssl based. So, do not think, just because the commercial 452 alternatives are usually more expensive, that you are also receiving 453 an alternative <i>technical</i> SSL solution. This is usually not 454 the case. Actually the vendor versions of Apache, mod_ssl and OpenSSL 455 often stay behind the latest free versions and perhaps this way still do not 456 include important bug and security fixes. On the other hand, 457 it sometimes occurs that a vendor version includes useful changes 458 which are not available through the official freely available 459 packages. But most vendors play fair and contribute back those 460 changes to the free software world, of course. 461 <p> 462 So, in short: There are lots of commercial versions of the popular 463 Apache+mod_ssl+OpenSSL server combination available. Every user 464 should decide carefully whether they really need to buy a commercial 465 version or whether it would not be sufficient to directly use the 466 free and official versions of the Apache, mod_ssl and OpenSSL 467 packages. 468<p> 469<li><a name="ToC5"></a> 470 <a name="what-version"></a> 471 <strong id="faq"> 472How do I know which mod_ssl version is for which Apache version? 473</strong> 474 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#what-version"><b>L</b></a>] 475 <p> 476 That's trivial: mod_ssl uses version strings of the syntax 477 <em><mod_ssl-version></em>-<em><apache-version></em>, for 478 instance <code>2.4.0-1.3.9</code>. This directly indicates that it's 479 mod_ssl version 2.4.0 for Apache version 1.3.9. And this also means you 480 <em>only</em> can apply this mod_ssl version to exactly this Apache 481 version (unless you use the <code>--force</code> option to mod_ssl's 482 <code>configure</code> command ;-). 483<p> 484<li><a name="ToC6"></a> 485 <a name="y2k"></a> 486 <strong id="faq"> 487Is mod_ssl Year 2000 compliant? 488</strong> 489 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#y2k"><b>L</b></a>] 490 <p> 491 Yes, mod_ssl is Year 2000 compliant. 492 <p> 493 Because first mod_ssl internally never stores years as two digits. 494 Instead it always uses the ANSI C & POSIX numerical data type 495 <code>time_t</code> type, which on almost all Unix platforms at the moment 496 is a <code>signed long</code> (usually 32-bits) representing seconds since 497 epoch of January 1st, 1970, 00:00 UTC. This signed value overflows in 498 early January 2038 and not in the year 2000. Second, date and time 499 presentations (for instance the variable ``<code>%{TIME_YEAR}</code>'') 500 are done with full year value instead of abbreviating to two digits. 501 <p> 502 Additionally according to a <a 503 href="http://www.apache.org/docs/FAQ.html#year2000">Year 2000 504 statement</a> from the Apache Group, the Apache webserver is Year 2000 505 compliant, too. But whether OpenSSL or the underlaying Operating System 506 (either a Unix or Win32 platform) is Year 2000 compliant is a different 507 question which cannot be answered here. 508<p> 509<li><a name="ToC7"></a> 510 <a name="wassenaar"></a> 511 <strong id="faq"> 512What about mod_ssl and the Wassenaar Arrangement? 513</strong> 514 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#wassenaar"><b>L</b></a>] 515 <p> 516 First, let us explain what <i>Wassenaar</i> and it's <i>Arrangement on 517 Export Controls for Conventional Arms and Dual-Use Goods and 518 Technologies</i> is: This is a international regime, established 1995, to 519 control trade in conventional arms and dual-use goods and technology. It 520 replaced the previous <i>CoCom</i> regime. 33 countries are signatories: 521 Argentina, Australia, Austria, Belgium, Bulgaria, Canada, Czech Republic, 522 Denmark, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Japan, 523 Luxembourg, Netherlands, New Zealand, Norway, Poland, Portugal, Republic 524 of Korea, Romania, Russian Federation, Slovak Republic, Spain, Sweden, 525 Switzerland, Turkey, Ukraine, United Kingdom and United States. For more 526 details look at <a 527 href="http://www.wassenaar.org/">http://www.wassenaar.org/</a>. 528 <p> 529 In short: The aim of the Wassenaar Arrangement is to prevent the build up 530 of military capabilities that threaten regional and international security 531 and stability. The Wassenaar Arrangement controls the export of 532 cryptography as a dual-use good, i.e., one that has both military and 533 civilian applications. However, the Wassenaar Arrangement also provides an 534 exemption from export controls for mass-market software and free software. 535 <p> 536 In the current Wassenaar ``<i>List of Dual Use Goods and Technologies And 537 Munitions</i>'', under ``<i>GENERAL SOFTWARE NOTE</i>'' (GSN) it says 538 ``<i>The Lists do not control "software" which is either: 1. [...] 2. "in 539 the public domain".</i>'' And under ``<i>DEFINITIONS OF TERMS USED IN 540 THESE LISTS</i>'' one can find the definition: ``<i>"In the public 541 domain": This means "technology" or "software" which has been made 542 available without restrictions upon its further dissemination. N.B. 543 Copyright restrictions do not remove "technology" or "software" from being 544 "in the public domain".</i>'' 545 <p> 546 So, both mod_ssl and OpenSSL are ``in the public domain'' for the purposes 547 of the Wassenaar Agreement and its ``<i>List of Dual Use Goods and 548 Technologies And Munitions List</i>''. 549 <p> 550 Additionally the Wassenaar Agreement itself has no direct consequence for 551 exporting cryptography software. What is actually allowed or forbidden to 552 be exported from the countries has still to be defined in the local laws 553 of each country. And at least according to official press releases from 554 the German BMWi (see <a 555 href="http://www.bmwi.de/presse/1998/1208prm2.html">here</a>) and the 556 Switzerland Bawi (see <a href="http://jya.com/wass-ch.htm">here</a>) there 557 will be no forthcoming export restriction for free cryptography software 558 for their countries. Remember that mod_ssl is created in Germany and 559 distributed from Switzerland. 560 <p> 561 So, mod_ssl and OpenSSL are not affected by the Wassenaar Agreement. 562</ul> 563<p> 564<br> 565<h2><a name="ToC8">About Installation</a></h2> 566<ul> 567<p> 568<li><a name="ToC9"></a> 569 <a name="core-dbm"></a> 570 <strong id="faq"> 571When I access my website the first time via HTTPS I get a core dump? 572</strong> 573 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#core-dbm"><b>L</b></a>] 574 <p> 575 There can be a lot of reasons why a core dump can occur, of course. 576 Ranging from buggy third-party modules, over buggy vendor libraries up to 577 a buggy mod_ssl version. But the above situation is often caused by old or 578 broken vendor DBM libraries. To solve it either build mod_ssl with the 579 built-in SDBM library (specify <tt>--enable-rule=SSL_SDBM</tt> at the 580 APACI command line) or switch from ``<tt>SSLSessionCache dbm:</tt>'' to the 581 newer ``<tt>SSLSessionCache shm:</tt>'' variant (after you have rebuilt 582 Apache with MM, of course). 583<p> 584<li><a name="ToC10"></a> 585 <a name="core-php3"></a> 586 <strong id="faq"> 587My Apache dumps core when I add both mod_ssl and PHP3? 588</strong> 589 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#core-php3"><b>L</b></a>] 590 <p> 591 Make sure you add mod_ssl to the Apache source tree first and then do a 592 fresh configuration and installation of PHP3. For SSL support EAPI patches 593 are required which have to change internal Apache structures. PHP3 needs 594 to know about these in order to work correctly. Always make sure that 595 <tt>-DEAPI</tt> is contained in the compiler flags when PHP3 is build. 596<p> 597<li><a name="ToC11"></a> 598 <a name="dso-sym"></a> 599 <strong id="faq"> 600When I startup Apache I get errors about undefined symbols like ap_global_ctx? 601</strong> 602 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#dso-sym"><b>L</b></a>] 603 <p> 604 This actually means you installed mod_ssl as a DSO, but without rebuilding 605 Apache with EAPI. Because EAPI is a requirement for mod_ssl, you need an 606 extra patched Apache (containing the EAPI patches) and you have to build 607 this Apache with EAPI enabled (explicitly specify 608 <tt>--enable-rule=EAPI</tt> at the APACI command line). 609<p> 610<li><a name="ToC12"></a> 611 <a name="mutex-perm"></a> 612 <strong id="faq"> 613When I startup Apache I get permission errors related to SSLMutex? 614</strong> 615 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#mutex-perm"><b>L</b></a>] 616 <p> 617 When you receive entries like ``<code>mod_ssl: Child could not open 618 SSLMutex lockfile /opt/apache/logs/ssl_mutex.18332 (System error follows) 619 [...] System: Permission denied (errno: 13)</code>'' this is usually 620 caused by to restrictive permissions on the <i>parent</i> directories. 621 Make sure that all parent directories (here <code>/opt</code>, 622 <code>/opt/apache</code> and <code>/opt/apache/logs</code>) have the x-bit 623 set at least for the UID under which Apache's children are running (see 624 the <code>User</code> directive of Apache). 625<p> 626<li><a name="ToC13"></a> 627 <a name="mm"></a> 628 <strong id="faq"> 629When I use the MM library and the shared memory cache each process grows 6301.5MB according to `top' although I specified 512000 as the cache size? 631</strong> 632 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#mm"><b>L</b></a>] 633 <p> 634 The additional 1MB are caused by the global shared memory pool EAPI 635 allocates for all modules and which is not used by mod_ssl for 636 various reasons. So the actually allocated shared memory is always 637 1MB more than what you specify on <code>SSLSessionCache</code>. 638 But don't be confused by the display of `top': although is 639 indicates that <i>each</i> process grow, this is not reality, of 640 course. Instead the additional memory consumption is shared by 641 all processes, i.e. the 1.5MB are allocated only once per Apache 642 instance and not once per Apache server process. 643<p> 644<li><a name="ToC14"></a> 645 <a name="mmpath"></a> 646 <strong id="faq"> 647Apache creates files in a directory declared by the internal 648EAPI_MM_CORE_PATH define. Is there a way to override the path using a 649configuration directive? 650</strong> 651 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#mmpath"><b>L</b></a>] 652 <p> 653 No, there is not configuration directive, because for technical 654 bootstrapping reasons, a directive not possible at all. Instead 655 use ``<code>CFLAGS='-DEAPI_MM_CORE_PATH="/path/to/wherever/"' 656 ./configure ...</code>'' when building Apache or use option 657 <b>-d</b> when starting <code>httpd</code>. 658<p> 659<li><a name="ToC15"></a> 660 <a name="entropy"></a> 661 <strong id="faq"> 662When I fire up the server, mod_ssl stops with the error 663"Failed to generate temporary 512 bit RSA private key", why? 664And a "PRNG not seeded" error occurs if I try "make certificate". 665</strong> 666 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#entropy"><b>L</b></a>] 667 <p> 668 Cryptographic software needs a source of unpredictable data 669 to work correctly. Many open source operating systems provide 670 a "randomness device" that serves this purpose (usually named 671 <code>/dev/random</code>). On other systems, applications have to 672 seed the OpenSSL Pseudo Random Number Generator (PRNG) manually with 673 appropriate data before generating keys or performing public key 674 encryption. As of version 0.9.5, the OpenSSL functions that need 675 randomness report an error if the PRNG has not been seeded with 676 at least 128 bits of randomness. So mod_ssl has to provide enough 677 entropy to the PRNG to work correctly. For this one has to use the 678 <code>SSLRandomSeed</code> directives (to solve the run-time problem) 679 and create a <code>$HOME/.rnd</code> file to make sure enough 680 entropy is available also for the "<code>make certificate</code>" 681 step (in case the "<code>make certificate</code>" procedure is not 682 able to gather enough entropy theirself by searching for system 683 files). 684</ul> 685<p> 686<br> 687<h2><a name="ToC16">About Configuration</a></h2> 688<ul> 689<p> 690<li><a name="ToC17"></a> 691 <a name="https-parallel"></a> 692 <strong id="faq"> 693Is it possible to provide HTTP and HTTPS with a single server?</strong> 694</strong> 695 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#https-parallel"><b>L</b></a>] 696 <p> 697 Yes, HTTP and HTTPS use different server ports, so there is no direct 698 conflict between them. Either run two separate server instances (one binds 699 to port 80, the other to port 443) or even use Apache's elegant virtual 700 hosting facility where you can easily create two virtual servers which 701 Apache dispatches: one responding to port 80 and speaking HTTP and one 702 responding to port 443 speaking HTTPS. 703<p> 704<li><a name="ToC18"></a> 705 <a name="https-port"></a> 706 <strong id="faq"> 707I know that HTTP is on port 80, but where is HTTPS? 708</strong> 709 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#https-port"><b>L</b></a>] 710 <p> 711 You can run HTTPS on any port, but the standards specify port 443, which 712 is where any HTTPS compliant browser will look by default. You can force 713 your browser to look on a different port by specifying it in the URL like 714 this (for port 666): <code>https://secure.server.dom:666/</code> 715<p> 716<li><a name="ToC19"></a> 717 <a name="https-test"></a> 718 <strong id="faq"> 719How can I speak HTTPS manually for testing purposes? 720</strong> 721 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#https-test"><b>L</b></a>] 722 <p> 723 While you usually just use 724 <p> 725 <code><b>$ telnet localhost 80</b></code><br> 726 <code><b>GET / HTTP/1.0</b></code> 727 <p> 728 for simple testing the HTTP protocol of Apache, it's not such easy for 729 HTTPS because of the SSL protocol between TCP and HTTP. But with the 730 help of OpenSSL's <code>s_client</code> command you can do a similar 731 check even for HTTPS: 732 <p> 733 <code><b>$ openssl s_client -connect localhost:443 -state -debug</b></code><br> 734 <code><b>GET / HTTP/1.0</b></code> 735 <p> 736 Before the actual HTTP response you receive detailed information about the 737 SSL handshake. For a more general command line client which directly 738 understands both the HTTP and HTTPS scheme, can perform GET and POST 739 methods, can use a proxy, supports byte ranges, etc. you should have a 740 look at nifty <a href="http://curl.haxx.nu/">cURL</a> 741 tool. With it you can directly check if your Apache is running fine on 742 Port 80 and 443 as following: 743 <p> 744 <code><b>$ curl http://localhost/</b></code><br> 745 <code><b>$ curl https://localhost/</b></code><br> 746<p> 747<li><a name="ToC20"></a> 748 <a name="hang"></a> 749 <strong id="faq"> 750Why does the connection hang when I connect to my SSL-aware Apache server? 751</strong> 752 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#hang"><b>L</b></a>] 753 <p> 754 Because you connected with HTTP to the HTTPS port, i.e. you used an URL of 755 the form ``<code>http://</code>'' instead of ``<code>https://</code>''. 756 This also happens the other way round when you connect via HTTPS to a HTTP 757 port, i.e. when you try to use ``<code>https://</code>'' on a server that 758 doesn't support SSL (on this port). Make sure you are connecting to a 759 virtual server that supports SSL, which is probably the IP associated with 760 your hostname, not localhost (127.0.0.1). 761<p> 762<li><a name="ToC21"></a> 763 <a name="hang"></a> 764 <strong id="faq"> 765Why do I get ``Connection Refused'' messages when trying to access my freshly 766installed Apache+mod_ssl server via HTTPS? 767</strong> 768 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#hang"><b>L</b></a>] 769 <p> 770 There can be various reasons. Some of the common mistakes is that people 771 start Apache with just ``<tt>apachectl start</tt>'' (or 772 ``<tt>httpd</tt>'') instead of ``<tt>apachectl startssl</tt>'' (or 773 ``<tt>httpd -DSSL</tt>''. Or you're configuration is not correct. At 774 least make sure that your ``<tt>Listen</tt>'' directives match your 775 ``<tt><VirtualHost></tt>'' directives. And if all fails, please do 776 yourself a favor and start over with the default configuration mod_ssl 777 provides you. 778<p> 779<li><a name="ToC22"></a> 780 <a name="env-vars"></a> 781 <strong id="faq"> 782In my CGI programs and SSI scripts the various documented 783<code>SSL_XXX</code> variables do not exists. Why? 784</strong> 785 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#env-vars"><b>L</b></a>] 786 <p> 787 Just make sure you have ``<code>SSLOptions +StdEnvVars</code>'' 788 enabled for the context of your CGI/SSI requests. 789<p> 790<li><a name="ToC23"></a> 791 <a name="relative-links"></a> 792 <strong id="faq"> 793How can I use relative hyperlinks to switch between HTTP and HTTPS? 794</strong> 795 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#relative-links"><b>L</b></a>] 796 <p> 797 Usually you have to use fully-qualified hyperlinks because 798 you have to change the URL scheme. But with the help of some URL 799 manipulations through mod_rewrite you can achieve the same effect while 800 you still can use relative URLs: 801 <pre> 802 RewriteEngine on 803 RewriteRule ^/(.*):SSL$ https://%{SERVER_NAME}/$1 [R,L] 804 RewriteRule ^/(.*):NOSSL$ http://%{SERVER_NAME}/$1 [R,L] 805 </pre> 806 This rewrite ruleset lets you use hyperlinks of the form 807 <pre> 808 <a href="document.html:SSL"> 809 </pre> 810</ul> 811<p> 812<br> 813<h2><a name="ToC24">About Certificates</a></h2> 814<ul> 815<p> 816<li><a name="ToC25"></a> 817 <a name="what-is"></a> 818 <strong id="faq"> 819What are RSA Private Keys, CSRs and Certificates?</strong> 820</strong> 821 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#what-is"><b>L</b></a>] 822 <p> 823 The RSA private key file is a digital file that you can use to decrypt 824 messages sent to you. It has a public component which you distribute (via 825 your Certificate file) which allows people to encrypt those messages to 826 you. A Certificate Signing Request (CSR) is a digital file which contains 827 your public key and your name. You send the CSR to a Certifying Authority 828 (CA) to be converted into a real Certificate. A Certificate contains your 829 RSA public key, your name, the name of the CA, and is digitally signed by 830 your CA. Browsers that know the CA can verify the signature on that 831 Certificate, thereby obtaining your RSA public key. That enables them to 832 send messages which only you can decrypt. 833 See the <a href="ssl_intro.html">Introduction</a> chapter for a general 834 description of the SSL protocol. 835<p> 836<li><a name="ToC26"></a> 837 <a name="startup"></a> 838 <strong id="faq"> 839Seems like there is a difference on startup between the original Apache and an SSL-aware Apache? 840</strong> 841 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#startup"><b>L</b></a>] 842 <p> 843 Yes, in general, starting Apache with a built-in mod_ssl is just like 844 starting an unencumbered Apache, except for the fact that when you have a 845 pass phrase on your SSL private key file. Then a startup dialog pops up 846 asking you to enter the pass phrase. 847 <p> 848 To type in the pass phrase manually when starting the server can be 849 problematic, for instance when starting the server from the system boot 850 scripts. As an alternative to this situation you can follow the steps 851 below under ``How can I get rid of the pass-phrase dialog at Apache 852 startup time?''. 853<p> 854<li><a name="ToC27"></a> 855 <a name="cert-dummy"></a> 856 <strong id="faq"> 857How can I create a dummy SSL server Certificate for testing purposes? 858</strong> 859 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#cert-dummy"><b>L</b></a>] 860 <p> 861 A Certificate does not have to be signed by a public CA. You can use your 862 private key to sign the Certificate which contains your public key. You 863 can install this Certificate into your server, and people using Netscape 864 Navigator (not MSIE) will be able to connect after clicking OK to a 865 warning dialogue. You can get MSIE to work, and your customers can 866 eliminate the dialogue, by installing that Certificate manually into their 867 browsers. 868 <p> 869 Just use the ``<code>make certificate</code>'' command at the top-level 870 directory of the Apache source tree right before installing Apache via 871 ``<code>make install</code>''. This creates a self-signed SSL Certificate 872 which expires after 30 days and isn't encrypted (which means you don't 873 need to enter a pass-phrase at Apache startup time). 874 <p> 875 BUT REMEMBER: YOU REALLY HAVE TO CREATE A REAL CERTIFICATE FOR THE LONG 876 RUN! HOW THIS IS DONE IS DESCRIBED IN THE NEXT ANSWER. 877<p> 878<li><a name="ToC28"></a> 879 <a name="cert-real"></a> 880 <strong id="faq"> 881Ok, I've got my server installed and want to create a real SSL 882server Certificate for it. How do I do it? 883</strong> 884 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#cert-real"><b>L</b></a>] 885 <p> 886 Here is a step-by-step description: 887 <p> 888 <ol> 889 <li>Make sure OpenSSL is really installed and in your <code>PATH</code>. 890 But some commands even work ok when you just run the 891 ``<code>openssl</code>'' program from within the OpenSSL source tree as 892 ``<code>./apps/openssl</code>''. 893 <p> 894 <li>Create a RSA private key for your Apache server 895 (will be Triple-DES encrypted and PEM formatted): 896 <p> 897 <code><strong>$ openssl genrsa -des3 -out server.key 1024</strong></code> 898 <p> 899 Please backup this <code>server.key</code> file and remember the 900 pass-phrase you had to enter at a secure location. 901 You can see the details of this RSA private key via the command: 902 <p> 903 <code><strong>$ openssl rsa -noout -text -in server.key</strong></code> 904 <p> 905 And you could create a decrypted PEM version (not recommended) 906 of this RSA private key via: 907 <p> 908 <code><strong>$ openssl rsa -in server.key -out server.key.unsecure</strong></code> 909 <p> 910 <li>Create a Certificate Signing Request (CSR) with the server RSA private 911 key (output will be PEM formatted): 912 <p> 913 <code><strong>$ openssl req -new -key server.key -out server.csr</strong></code> 914 <p> 915 Make sure you enter the FQDN ("Fully Qualified Domain Name") of the 916 server when OpenSSL prompts you for the "CommonName", i.e. when you 917 generate a CSR for a website which will be later accessed via 918 <code>https://www.foo.dom/</code>, enter "www.foo.dom" here. 919 You can see the details of this CSR via the command 920 <p> 921 <code><strong>$ openssl req -noout -text -in server.csr</strong></code> 922 <p> 923 <li>You now have to send this Certificate Signing Request (CSR) to 924 a Certifying Authority (CA) for signing. The result is then a real 925 Certificate which can be used for Apache. Here you have two options: 926 First you can let the CSR sign by a commercial CA like Verisign or 927 Thawte. Then you usually have to post the CSR into a web form, pay for 928 the signing and await the signed Certificate you then can store into a 929 server.crt file. For more information about commercial CAs have a look 930 at the following locations: 931 <p> 932 <ul> 933 <li> Verisign<br> 934 <a href="http://digitalid.verisign.com/server/apacheNotice.htm"> 935 http://digitalid.verisign.com/server/apacheNotice.htm 936 </a> 937 <li> Thawte Consulting<br> 938 <a href="http://www.thawte.com/certs/server/request.html"> 939 http://www.thawte.com/certs/server/request.html 940 </a> 941 <li> CertiSign Certificadora Digital Ltda.<br> 942 <a href="http://www.certisign.com.br"> 943 http://www.certisign.com.br 944 </a> 945 <li> IKS GmbH<br> 946 <a href="http://www.iks-jena.de/produkte/ca/"> 947 http://www.iks-jena.de/produkte/ca/ 948 </a> 949 <li> Uptime Commerce Ltd.<br> 950 <a href="http://www.uptimecommerce.com"> 951 http://www.uptimecommerce.com 952 </a> 953 <li> BelSign NV/SA<br> 954 <a href="http://www.belsign.be"> 955 http://www.belsign.be 956 </a> 957 </ul> 958 <p> 959 Second you can use your own CA and now have to sign the CSR yourself by 960 this CA. Read the next answer in this FAQ on how to sign a CSR with 961 your CA yourself. 962 You can see the details of the received Certificate via the command: 963 <p> 964 <code><strong>$ openssl x509 -noout -text -in server.crt</strong></code> 965 <p> 966 <li>Now you have two files: <code>server.key</code> and 967 <code>server.crt</code>. These now can be used as following inside your 968 Apache's <code>httpd.conf</code> file: 969 <pre> 970 SSLCertificateFile /path/to/this/server.crt 971 SSLCertificateKeyFile /path/to/this/server.key 972 </pre> 973 The <code>server.csr</code> file is no longer needed. 974 </ol> 975<p> 976<li><a name="ToC29"></a> 977 <a name="cert-ownca"></a> 978 <strong id="faq"> 979How can I create and use my own Certificate Authority (CA)? 980</strong> 981 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#cert-ownca"><b>L</b></a>] 982 <p> 983 The short answer is to use the <code>CA.sh</code> or <code>CA.pl</code> 984 script provided by OpenSSL. The long and manual answer is this: 985 <p> 986 <ol> 987 <li>Create a RSA private key for your CA 988 (will be Triple-DES encrypted and PEM formatted): 989 <p> 990 <code><strong>$ openssl genrsa -des3 -out ca.key 1024</strong></code> 991 <p> 992 Please backup this <code>ca.key</code> file and remember the 993 pass-phrase you currently entered at a secure location. 994 You can see the details of this RSA private key via the command 995 <p> 996 <code><strong>$ openssl rsa -noout -text -in ca.key</strong></code> 997 <p> 998 And you can create a decrypted PEM version (not recommended) of this 999 private key via: 1000 <p> 1001 <code><strong>$ openssl rsa -in ca.key -out ca.key.unsecure</strong></code> 1002 <p> 1003 <li>Create a self-signed CA Certificate (X509 structure) 1004 with the RSA key of the CA (output will be PEM formatted): 1005 <p> 1006 <code><strong>$ openssl req -new -x509 -days 365 -key ca.key -out ca.crt</strong></code> 1007 <p> 1008 You can see the details of this Certificate via the command: 1009 <p> 1010 <code><strong>$ openssl x509 -noout -text -in ca.crt</strong></code> 1011 <p> 1012 <li>Prepare a script for signing which is needed because 1013 the ``<code>openssl ca</code>'' command has some strange requirements 1014 and the default OpenSSL config doesn't allow one easily to use 1015 ``<code>openssl ca</code>'' directly. So a script named 1016 <code>sign.sh</code> is distributed with the mod_ssl distribution 1017 (subdir <code>pkg.contrib/</code>). Use this script for signing. 1018 <p> 1019 <li>Now you can use this CA to sign server CSR's in order to create real 1020 SSL Certificates for use inside an Apache webserver (assuming 1021 you already have a <code>server.csr</code> at hand): 1022 <p> 1023 <code><strong>$ ./sign.sh server.csr</strong></code> 1024 <p> 1025 This signs the server CSR and results in a <code>server.crt</code> file. 1026 </ol> 1027<p> 1028<li><a name="ToC30"></a> 1029 <a name="change-passphrase"></a> 1030 <strong id="faq"> 1031How can I change the pass-phrase on my private key file? 1032</strong> 1033 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#change-passphrase"><b>L</b></a>] 1034 <p> 1035 You simply have to read it with the old pass-phrase and write it again 1036 by specifying the new pass-phrase. You can accomplish this with the following 1037 commands: 1038 <p> 1039 <code><strong>$ openssl rsa -des3 -in server.key -out server.key.new</strong></code><br> 1040 <code><strong>$ mv server.key.new server.key</strong></code><br> 1041 <p> 1042 Here you're asked two times for a PEM pass-phrase. At the first 1043 prompt enter the old pass-phrase and at the second prompt 1044 enter the new pass-phrase. 1045<p> 1046<li><a name="ToC31"></a> 1047 <a name="remove-passphrase"></a> 1048 <strong id="faq"> 1049How can I get rid of the pass-phrase dialog at Apache startup time? 1050</strong> 1051 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#remove-passphrase"><b>L</b></a>] 1052 <p> 1053 The reason why this dialog pops up at startup and every re-start 1054 is that the RSA private key inside your server.key file is stored in 1055 encrypted format for security reasons. The pass-phrase is needed to be 1056 able to read and parse this file. When you can be sure that your server is 1057 secure enough you perform two steps: 1058 <p> 1059 <ol> 1060 <li>Remove the encryption from the RSA private key (while 1061 preserving the original file): 1062 <p> 1063 <code><strong>$ cp server.key server.key.org</strong></code><br> 1064 <code><strong>$ openssl rsa -in server.key.org -out server.key</strong></code> 1065 <p> 1066 <li>Make sure the server.key file is now only readable by root: 1067 <p> 1068 <code><strong>$ chmod 400 server.key</strong></code> 1069 </ol> 1070 <p> 1071 Now <code>server.key</code> will contain an unencrypted copy of the key. 1072 If you point your server at this file it will not prompt you for a 1073 pass-phrase. HOWEVER, if anyone gets this key they will be able to 1074 impersonate you on the net. PLEASE make sure that the permissions on that 1075 file are really such that only root or the web server user can read it 1076 (preferably get your web server to start as root but run as another 1077 server, and have the key readable only by root). 1078 <p> 1079 As an alternative approach you can use the ``<code>SSLPassPhraseDialog 1080 exec:/path/to/program</code>'' facility. But keep in mind that this is 1081 neither more nor less secure, of course. 1082<p> 1083<li><a name="ToC32"></a> 1084 <a name="verify-key"></a> 1085 <strong id="faq"> 1086How do I verify that a private key matches its Certificate? 1087</strong> 1088 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#verify-key"><b>L</b></a>] 1089 <p> 1090 The private key contains a series of numbers. Two of those numbers form 1091 the "public key", the others are part of your "private key". The "public 1092 key" bits are also embedded in your Certificate (we get them from your 1093 CSR). To check that the public key in your cert matches the public 1094 portion of your private key, you need to view the cert and the key and 1095 compare the numbers. To view the Certificate and the key run the 1096 commands: 1097 <p> 1098 <code><strong>$ openssl x509 -noout -text -in server.crt</strong></code><br> 1099 <code><strong>$ openssl rsa -noout -text -in server.key</strong></code> 1100 <p> 1101 The `modulus' and the `public exponent' portions in the key and the 1102 Certificate must match. But since the public exponent is usually 65537 1103 and it's bothering comparing long modulus you can use the following 1104 approach: 1105 <p> 1106 <code><strong>$ openssl x509 -noout -modulus -in server.crt | openssl md5</strong></code><br> 1107 <code><strong>$ openssl rsa -noout -modulus -in server.key | openssl md5</strong></code> 1108 <p> 1109 And then compare these really shorter numbers. With overwhelming 1110 probability they will differ if the keys are different. BTW, if I want to 1111 check to which key or certificate a particular CSR belongs you can compute 1112 <p> 1113 <code><strong>$ openssl req -noout -modulus -in server.csr | openssl md5</strong></code> 1114<p> 1115<li><a name="ToC33"></a> 1116 <a name="keysize1"></a> 1117 <strong id="faq"> 1118What does it mean when my connections fail with an "alert bad certificate" 1119error? 1120</strong> 1121 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#keysize1"><b>L</b></a>] 1122 <p> 1123 Usually when you see errors like ``<tt>OpenSSL: error:14094412: SSL 1124 routines:SSL3_READ_BYTES:sslv3 alert bad certificate</tt>'' in the SSL 1125 logfile, this means that the browser was unable to handle the server 1126 certificate/private-key which perhaps contain a RSA-key not equal to 1024 1127 bits. For instance Netscape Navigator 3.x is one of those browsers. 1128<p> 1129<li><a name="ToC34"></a> 1130 <a name="keysize2"></a> 1131 <strong id="faq"> 1132Why does my 2048-bit private key not work? 1133</strong> 1134 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#keysize2"><b>L</b></a>] 1135 <p> 1136 The private key sizes for SSL must be either 512 or 1024 for compatibility 1137 with certain web browsers. A keysize of 1024 bits is recommended because 1138 keys larger than 1024 bits are incompatible with some versions of Netscape 1139 Navigator and Microsoft Internet Explorer, and with other browsers that 1140 use RSA's BSAFE cryptography toolkit. 1141<p> 1142<li><a name="ToC35"></a> 1143 <a name="hash-symlinks"></a> 1144 <strong id="faq"> 1145Why is client authentication broken after upgrading from 1146SSLeay version 0.8 to 0.9? 1147</strong> 1148 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#hash-symlinks"><b>L</b></a>] 1149 <p> 1150 The CA certificates under the path you configured with 1151 <code>SSLCACertificatePath</code> are found by SSLeay through hash 1152 symlinks. These hash values are generated by the `<code>openssl x509 -noout 1153 -hash</code>' command. But the algorithm used to calculate the hash for a 1154 certificate has changed between SSLeay 0.8 and 0.9. So you have to remove 1155 all old hash symlinks and re-create new ones after upgrading. Use the 1156 <code>Makefile</code> mod_ssl placed into this directory. 1157<p> 1158<li><a name="ToC36"></a> 1159 <a name="pem-to-der"></a> 1160 <strong id="faq"> 1161How can I convert a certificate from PEM to DER format? 1162</strong> 1163 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#pem-to-der"><b>L</b></a>] 1164 <p> 1165 The default certificate format for SSLeay/OpenSSL is PEM, which actually 1166 is Base64 encoded DER with header and footer lines. For some applications 1167 (e.g. Microsoft Internet Explorer) you need the certificate in plain DER 1168 format. You can convert a PEM file <code>cert.pem</code> into the 1169 corresponding DER file <code>cert.der</code> with the following command: 1170 <code><strong>$ openssl x509 -in cert.pem -out cert.der -outform DER</strong></code> 1171<p> 1172<li><a name="ToC37"></a> 1173 <a name="verisign-getca"></a> 1174 <strong id="faq"> 1175I try to install a Verisign certificate. Why can't I find neither the 1176<code>getca</code> nor <code>getverisign</code> programs Verisign mentions? 1177</strong> 1178 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#verisign-getca"><b>L</b></a>] 1179 <p> 1180 This is because Verisign has never provided specific instructions 1181 for Apache+mod_ssl. Rather they tell you what you should do 1182 if you were using C2Net's Stronghold (a commercial Apache 1183 based server with SSL support). The only thing you have to do 1184 is to save the certificate into a file and give the name of 1185 that file to the <code>SSLCertificateFile</code> directive. 1186 Remember that you need to give the key file in as well (see 1187 <code>SSLCertificateKeyFile</code> directive). For a better 1188 CA-related overview on SSL certificate fiddling you can look at <a 1189 href="http://www.thawte.com/certs/server/keygen/mod_ssl.html"> 1190 Thawte's mod_ssl instructions</a>. 1191<p> 1192<li><a name="ToC38"></a> 1193 <a name="gid"></a> 1194 <strong id="faq"> 1195Can I use the Server Gated Cryptography (SGC) facility (aka Verisign Global 1196ID) also with mod_ssl? 1197</strong> 1198 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#gid"><b>L</b></a>] 1199 <p> 1200 Yes, mod_ssl since version 2.1 supports the SGC facility. You don't have 1201 to configure anything special for this, just use a Global ID as your 1202 server certificate. The <i>step up</i> of the clients are then 1203 automatically handled by mod_ssl under run-time. For details please read 1204 the <tt>README.GlobalID</tt> document in the mod_ssl distribution. 1205<p> 1206<li><a name="ToC39"></a> 1207 <a name="gid"></a> 1208 <strong id="faq"> 1209After I have installed my new Verisign Global ID server certificate, the 1210browsers complain that they cannot verify the server certificate? 1211</strong> 1212 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#gid"><b>L</b></a>] 1213 <p> 1214 That is because Verisign uses an intermediate CA certificate between 1215 the root CA certificate (which is installed in the browsers) and 1216 the server certificate (which you installed in the server). You 1217 should have received this additional CA certificate from Verisign. 1218 If not, complain to them. Then configure this certificate with the 1219 <code>SSLCertificateChainFile</code> directive in the server. This 1220 makes sure the intermediate CA certificate is send to the browser 1221 and this way fills the gap in the certificate chain. 1222</ul> 1223<p> 1224<br> 1225<h2><a name="ToC40">About SSL Protocol</a></h2> 1226<ul> 1227<p> 1228<li><a name="ToC41"></a> 1229 <a name="random-errors"></a> 1230 <strong id="faq"> 1231Why do I get lots of random SSL protocol errors under heavy server load? 1232</strong> 1233 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#random-errors"><b>L</b></a>] 1234 <p> 1235 There can be a number of reasons for this, but the main one 1236 is problems with the SSL session Cache specified by the 1237 <tt>SSLSessionCache</tt> directive. The DBM session cache is most 1238 likely the source of the problem, so trying the SHM session cache or 1239 no cache at all may help. 1240<p> 1241<li><a name="ToC42"></a> 1242 <a name="load"></a> 1243 <strong id="faq"> 1244Why has my webserver a higher load now that I run SSL there? 1245</strong> 1246 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#load"><b>L</b></a>] 1247 <p> 1248 Because SSL uses strong cryptographic encryption and this needs a lot of 1249 number crunching. And because when you request a webpage via HTTPS even 1250 the images are transfered encrypted. So, when you have a lot of HTTPS 1251 traffic the load increases. 1252<p> 1253<li><a name="ToC43"></a> 1254 <a name="random"></a> 1255 <strong id="faq"> 1256Often HTTPS connections to my server require up to 30 seconds for establishing 1257the connection, although sometimes it works faster? 1258</strong> 1259 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#random"><b>L</b></a>] 1260 <p> 1261 Usually this is caused by using a <code>/dev/random</code> device for 1262 <code>SSLRandomSeed</code> which is blocking in read(2) calls if not 1263 enough entropy is available. Read more about this problem in the refernce 1264 chapter under <code>SSLRandomSeed</code>. 1265<p> 1266<li><a name="ToC44"></a> 1267 <a name="ciphers"></a> 1268 <strong id="faq"> 1269What SSL Ciphers are supported by mod_ssl? 1270</strong> 1271 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#ciphers"><b>L</b></a>] 1272 <p> 1273 Usually just all SSL ciphers which are supported by the 1274 version of OpenSSL in use (can depend on the way you built 1275 OpenSSL). Typically this at least includes the following: 1276 <p> 1277 <ul> 1278 <li>RC4 with MD5 1279 <li>RC4 with MD5 (export version restricted to 40-bit key) 1280 <li>RC2 with MD5 1281 <li>RC2 with MD5 (export version restricted to 40-bit key) 1282 <li>IDEA with MD5 1283 <li>DES with MD5 1284 <li>Triple-DES with MD5 1285 </ul> 1286 <p> 1287 To determine the actual list of supported ciphers you can 1288 run the following command: 1289 <p> 1290 <code><strong>$ openssl ciphers -v</strong></code><br> 1291<p> 1292<li><a name="ToC45"></a> 1293 <a name="cipher-adh"></a> 1294 <strong id="faq"> 1295I want to use Anonymous Diffie-Hellman (ADH) ciphers, but I always get ``no 1296shared cipher'' errors? 1297</strong> 1298 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#cipher-adh"><b>L</b></a>] 1299 <p> 1300 In order to use Anonymous Diffie-Hellman (ADH) ciphers, it is not enough 1301 to just put ``<code>ADH</code>'' into your <code>SSLCipherSuite</code>. 1302 Additionally you have to build OpenSSL with 1303 ``<code>-DSSL_ALLOW_ADH</code>''. Because per default OpenSSL does not 1304 allow ADH ciphers for security reasons. So if you are actually enabling 1305 these ciphers make sure you are informed about the side-effects. 1306<p> 1307<li><a name="ToC46"></a> 1308 <a name="cipher-shared"></a> 1309 <strong id="faq"> 1310I always just get a 'no shared ciphers' error if 1311I try to connect to my freshly installed server? 1312</strong> 1313 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#cipher-shared"><b>L</b></a>] 1314 <p> 1315 Either you have messed up your <code>SSLCipherSuite</code> 1316 directive (compare it with the pre-configured example in 1317 <code>httpd.conf-dist</code>) or you have choosen the DSA/DH 1318 algorithms instead of RSA under "<code>make certificate</code>" 1319 and ignored or overseen the warnings. Because if you have choosen 1320 DSA/DH, then your server no longer speaks RSA-based SSL ciphers 1321 (at least not until you also configure an additional RSA-based 1322 certificate/key pair). But current browsers like NS or IE only speak 1323 RSA ciphers. The result is the "no shared ciphers" error. To fix 1324 this, regenerate your server certificate/key pair and this time 1325 choose the RSA algorithm. 1326<p> 1327<li><a name="ToC47"></a> 1328 <a name="vhosts"></a> 1329 <strong id="faq"> 1330Why can't I use SSL with name-based/non-IP-based virtual hosts? 1331</strong> 1332 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#vhosts"><b>L</b></a>] 1333 <p> 1334 The reason is very technical. Actually it's some sort of a chicken and 1335 egg problem: The SSL protocol layer stays below the HTTP protocol layer 1336 and encapsulates HTTP. When an SSL connection (HTTPS) is established 1337 Apache/mod_ssl has to negotiate the SSL protocol parameters with the 1338 client. For this mod_ssl has to consult the configuration of the virtual 1339 server (for instance it has to look for the cipher suite, the server 1340 certificate, etc.). But in order to dispatch to the correct virtual server 1341 Apache has to know the <code>Host</code> HTTP header field. For this the 1342 HTTP request header has to be read. This cannot be done before the SSL 1343 handshake is finished. But the information is already needed at the SSL 1344 handshake phase. Bingo! 1345<p> 1346<li><a name="ToC48"></a> 1347 <a name="lock-icon"></a> 1348 <strong id="faq"> 1349When I use Basic Authentication over HTTPS the lock icon in Netscape browsers 1350still show the unlocked state when the dialog pops up. Does this mean the 1351username/password is still transmitted unencrypted? 1352</strong> 1353 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#lock-icon"><b>L</b></a>] 1354 <p> 1355 No, the username/password is already transmitted encrypted. The icon in 1356 Netscape browsers is just not really synchronized with the SSL/TLS layer 1357 (it toggles to the locked state when the first part of the actual webpage 1358 data is transferred which is not quite correct) and this way confuses 1359 people. The Basic Authentication facility is part of the HTTP layer and 1360 this layer is above the SSL/TLS layer in HTTPS. And before any HTTP data 1361 communication takes place in HTTPS the SSL/TLS layer has already done the 1362 handshake phase and switched to encrypted communication. So, don't get 1363 confused by this icon. 1364<p> 1365<li><a name="ToC49"></a> 1366 <a name="io-ie"></a> 1367 <strong id="faq"> 1368When I connect via HTTPS to an Apache+mod_ssl+OpenSSL server with Microsoft Internet 1369Explorer (MSIE) I get various I/O errors. What is the reason? 1370</strong> 1371 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#io-ie"><b>L</b></a>] 1372 <p> 1373 The first reason is that the SSL implementation in some MSIE versions has 1374 some subtle bugs related to the HTTP keep-alive facility and the SSL close 1375 notify alerts on socket connection close. Additionally the interaction 1376 between SSL and HTTP/1.1 features are problematic with some MSIE versions, 1377 too. You've to work-around these problems by forcing 1378 Apache+mod_ssl+OpenSSL to not use HTTP/1.1, keep-alive connections or 1379 sending the SSL close notify messages to MSIE clients. This can be done by 1380 using the following directive in your SSL-aware virtual host section: 1381 <pre> 1382 SetEnvIf User-Agent ".*MSIE.*" \ 1383 <b>nokeepalive ssl-unclean-shutdown \ 1384 downgrade-1.0 force-response-1.0</b></pre> 1385 Additionally it is known some MSIE versions have also problems 1386 with particular ciphers. Unfortunately one cannot workaround these 1387 bugs only for those MSIE particular clients, because the ciphers 1388 are already used in the SSL handshake phase. So a MSIE-specific 1389 <tt>SetEnvIf</tt> doesn't work to solve these problems. Instead one 1390 has to do more drastic adjustments to the global parameters. But 1391 before you decide to do this, make sure your clients really have 1392 problems. If not, do not do this, because it affects all(!) your 1393 clients, i.e., also your non-MSIE clients. 1394 <p> 1395 The next problem is that 56bit export versions of MSIE 5.x browsers have a 1396 broken SSLv3 implementation which badly interacts with OpenSSL versions 1397 greater than 0.9.4. You can either accept this and force your clients to 1398 upgrade their browsers, or you downgrade to OpenSSL 0.9.4 (hmmm), or you 1399 can decide to workaround it by accepting the drawback that your workaround 1400 will horribly affect also other browsers: 1401 <pre> 1402 SSLProtocol all <b>-SSLv3</b></pre> 1403 This completely disables the SSLv3 protocol and lets those browsers work. 1404 But usually this is an even less acceptable workaround. A more reasonable 1405 workaround is to address the problem more closely and disable only the 1406 ciphers which cause trouble. 1407 <pre> 1408 SSLCipherSuite ALL:!ADH:<b>!EXPORT56</b>:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP</pre> 1409 This also lets the broken MSIE versions work, but only removes the 1410 newer 56bit TLS ciphers. 1411 <p> 1412 Another problem with MSIE 5.x clients is that they refuse to connect to 1413 URLs of the form <tt>https://12.34.56.78/</tt> (IP-addresses are used 1414 instead of the hostname), if the server is using the Server Gated 1415 Cryptography (SGC) facility. This can only be avoided by using the fully 1416 qualified domain name (FQDN) of the website in hyperlinks instead, because 1417 MSIE 5.x has an error in the way it handles the SGC negotiation. 1418 <p> 1419 And finally there are versions of MSIE which seem to require that 1420 an SSL session can be reused (a totally non standard-conforming 1421 behaviour, of course). Connection with those MSIE versions only work 1422 if a SSL session cache is used. So, as a work-around, make sure you 1423 are using a session cache (see <tt>SSLSessionCache</tt> directive). 1424<p> 1425<li><a name="ToC50"></a> 1426 <a name="io-ns"></a> 1427 <strong id="faq"> 1428When I connect via HTTPS to an Apache+mod_ssl server with Netscape Navigator I 1429get I/O errors and the message "Netscape has encountered bad data from the 1430server" What's the reason? 1431</strong> 1432 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#io-ns"><b>L</b></a>] 1433 <p> 1434 The problem usually is that you had created a new server certificate with 1435 the same DN, but you had told your browser to accept forever the old 1436 server certificate. Once you clear the entry in your browser for the old 1437 certificate, everything usually will work fine. Netscape's SSL 1438 implementation is correct, so when you encounter I/O errors with Netscape 1439 Navigator it is most of the time caused by the configured certificates. 1440</ul> 1441<p> 1442<br> 1443<h2><a name="ToC51">About Support</a></h2> 1444<ul> 1445<p> 1446<li><a name="ToC52"></a> 1447 <a name="resources"></a> 1448 <strong id="faq"> 1449What information resources are available in case of mod_ssl problems? 1450</strong> 1451 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#resources"><b>L</b></a>] 1452 <p> 1453The following information resources are available. 1454In case of problems you should search here first. 1455<p> 1456<ol> 1457<li><em>Answers in the User Manual's F.A.Q. List (this)</em><br> 1458 <a href="http://www.modssl.org/docs/2.8/ssl_faq.html"> 1459 http://www.modssl.org/docs/2.8/ssl_faq.html</a><br> 1460 First look inside the F.A.Q. (this text), perhaps your problem is such 1461 popular that it was already answered a lot of times in the past. 1462<p> 1463<li><em>Postings from the modssl-users Support Mailing List</em> 1464 <a href="http://www.modssl.org/support/"> 1465 http://www.modssl.org/support/</a><br> 1466 Second search for your problem in one of the existing archives of the 1467 modssl-users mailing list. Perhaps your problem popped up at least once for 1468 another user, too. 1469<p> 1470<li><em>Problem Reports in the Bug Database</em> 1471 <a href="http://www.modssl.org/support/bugdb/"> 1472 http://www.modssl.org/support/bugdb/</a><br> 1473 Third look inside the mod_ssl Bug Database. Perhaps 1474 someone else already has reported the problem. 1475</ol> 1476<p> 1477<li><a name="ToC53"></a> 1478 <a name="contact"></a> 1479 <strong id="faq"> 1480What support contacts are available in case of mod_ssl problems? 1481</strong> 1482 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#contact"><b>L</b></a>] 1483 <p> 1484The following lists all support possibilities for mod_ssl, in order of 1485preference, i.e. start in this order and do not pick the support possibility 1486you just like most, please. 1487<p> 1488<ol> 1489<li><em>Write a Problem Report into the Bug Database</em><br> 1490 <a href="http://www.modssl.org/support/bugdb/"> 1491 http://www.modssl.org/support/bugdb/</a><br> 1492 This is the preferred way of submitting your problem report, because this 1493 way it gets filed into the bug database (it cannot be lost) <em>and</em> 1494 send to the modssl-users mailing list (others see the current problems and 1495 learn from answers). 1496<p> 1497<li><em>Write a Problem Report to the modssl-users Support Mailing List</em><br> 1498 <a href="mailto:modssl-users@modssl.org"> 1499 modssl-users @ modssl.org</a><br> 1500 This is the second way of submitting your problem report. You have to 1501 subscribe to the list first, but then you can easily discuss your problem 1502 with both the author and the whole mod_ssl user community. 1503<p> 1504<li><em>Write a Problem Report to the author</em><br> 1505 <a href="mailto:rse@engelschall.com"> 1506 rse @ engelschall.com</a><br> 1507 This is the last way of submitting your problem report. Please avoid this 1508 in your own interest because the author is really a very busy men. Your 1509 mail will always be filed to one of his various mail-folders and is 1510 usually not processed as fast as a posting on modssl-users. 1511</ol> 1512<p> 1513<li><a name="ToC54"></a> 1514 <a name="report-details"></a> 1515 <strong id="faq"> 1516What information and details I've to provide to 1517the author when writing a bug report? 1518</strong> 1519 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#report-details"><b>L</b></a>] 1520 <p> 1521You have to at least always provide the following information: 1522<p> 1523<ul> 1524<li><em>Apache, mod_ssl and OpenSSL version information</em><br> 1525 The mod_ssl version you should really know. For instance, it's the version 1526 number in the distribution tarball. The Apache version can be determined 1527 by running ``<code>httpd -v</code>''. The OpenSSL version can be 1528 determined by running ``<code>openssl version</code>''. Alternatively when 1529 you have Lynx installed you can run the command ``<code>lynx -mime_header 1530 http://localhost/ | grep Server</code>'' to determine all information in a 1531 single step. 1532<p> 1533<li><em>The details on how you built and installed Apache+mod_ssl+OpenSSL</em><br> 1534 For this you can provide a logfile of your terminal session which shows 1535 the configuration and install steps. Alternatively you can at least 1536 provide the author with the APACI `<code>configure</code>'' command line 1537 you used (assuming you used APACI, of course). 1538<p> 1539<li><em>In case of core dumps please include a Backtrace</em><br> 1540 In case your Apache+mod_ssl+OpenSSL should really dumped core please attach 1541 a stack-frame ``backtrace'' (see the next question on how to get it). 1542 Without this information the reason for your core dump cannot be found. 1543 So you have to provide the backtrace, please. 1544<p> 1545<li><em>A detailed description of your problem</em><br> 1546 Don't laugh, I'm totally serious. I already got a lot of problem reports 1547 where the people not really said what's the actual problem is. So, in your 1548 own interest (you want the problem be solved, don't you?) include as much 1549 details as possible, please. But start with the essentials first, of 1550 course. 1551</ul> 1552<p> 1553<li><a name="ToC55"></a> 1554 <a name="core-dumped"></a> 1555 <strong id="faq"> 1556I got a core dump, can you help me? 1557</strong> 1558 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#core-dumped"><b>L</b></a>] 1559 <p> 1560 In general no, at least not unless you provide more details about the code 1561 location where Apache dumped core. What is usually always required in 1562 order to help you is a backtrace (see next question). Without this 1563 information it is mostly impossible to find the problem and help you in 1564 fixing it. 1565<p> 1566<li><a name="ToC56"></a> 1567 <a name="report-backtrace"></a> 1568 <strong id="faq"> 1569Ok, I got a core dump but how do I get a backtrace to find out the reason for it? 1570</strong> 1571 [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#report-backtrace"><b>L</b></a>] 1572 <p> 1573Follow the following steps: 1574<p> 1575<ol> 1576<li>Make sure you have debugging symbols available in at least 1577 Apache and mod_ssl. On platforms where you use GCC/GDB you have to build 1578 Apache+mod_ssl with ``<code>OPTIM="-g -ggdb3"</code>'' to achieve this. On 1579 other platforms at least ``<code>OPTIM="-g"</code>'' is needed. 1580<p> 1581<li>Startup the server and try to produce the core-dump. For this you perhaps 1582 want to use a directive like ``<code>CoreDumpDirectory /tmp</code>'' to 1583 make sure that the core-dump file can be written. You then should get a 1584 <code>/tmp/core</code> or <code>/tmp/httpd.core</code> file. When you 1585 don't get this, try to run your server under an UID != 0 (root), because 1586 most "current" kernels do not allow a process to dump core after it has 1587 done a <code>setuid()</code> (unless it does an <code>exec()</code>) for 1588 security reasons (there can be privileged information left over in 1589 memory). Additionally you can run ``<code>/path/to/httpd -X</code>'' 1590 manually to force Apache to not fork. 1591<p> 1592<li>Analyze the core-dump. For this run ``<code>gdb /path/to/httpd 1593 /tmp/httpd.core</code>'' or a similar command has to run. In GDB you then 1594 just have to enter the ``<code>bt</code>'' command and, voila, you get the 1595 backtrace. For other debuggers consult your local debugger manual. Send 1596 this backtrace to the author. 1597</ol> 1598</ul> 1599 <p> 1600 <br> 1601 <table summary=""> 1602 <tr> 1603 <td> 1604 <table width="600" border="0" summary=""> 1605 <tr> 1606 <td valign="top" align="left" width="250"> 1607<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> 1608 </td> 1609 <td valign="top" align="right" width="250"> 1610<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> 1611 </td> 1612 </tr> 1613 </table> 1614 </td> 1615 </tr> 1616 <tr> 1617 <td><img src="ssl_template.imgdot-1x1-000000.gif" alt="" width="600" height="2" align="bottom" border="0"></td> 1618 </tr> 1619 <tr> 1620 <td><table width="598" summary=""> 1621 <tr> 1622 <td align="left"><font face="Arial,Helvetica"> 1623 <a href="http://www.modssl.org/">mod_ssl</a> 2.8, User Manual<br> 1624 The Apache Interface to OpenSSL 1625 </font> 1626 </td> 1627 <td align="right"><font face="Arial,Helvetica"> 1628 Copyright © 1998-2001 1629 <a href="http://www.engelschall.com/">Ralf S. Engelschall</a><br> 1630 All Rights Reserved<br> 1631 </font> 1632 </td> 1633 </tr> 1634 </table> 1635 </td> 1636 </tr> 1637 </table> 1638 </td> 1639</tr> 1640</table> 1641</div> 1642</body> 1643</html> 1644
