ssl_faq.wml

mod_ssl-2.8.31-1.3.41.tar.gz 好用的ssl工具

#use "ssl_template.inc" title="F.A.Q." tag=faq num=6

<page_prev name="HowTo"         url="ssl_howto.html">
<page_next name="Glossary"      url="ssl_glossary.html">

#use wml::std::toc style=nbsp

<quotation width=200 author="Claude Levi-Strauss">
``The wise man doesn't give the right answers,
he poses the right questions.''
</quotation>

<p>
<table cellspacing=0 cellpadding=0 border=0>
<tr valign=bottom>
<td>

<big T>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:[e-mail]">
<code>[e-mail]</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>
&nbsp;&nbsp;
</td>
<td>

<div align=right>
<table cellspacing=0 cellpadding=5 border=0 bgcolor="#ccccff" width=350>
<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>
<toc>
</font>
</td>
</tr>
</table>
</div>

</td>
</tr>
</table>

#   container tag for layouting a question
<define-tag faq endtag=required>
<preserve ref>
<preserve toc>
<set-var %attributes>
<p>
<li><toc_h3 alt="<get-var toc>"></toc_h3>
    <a name="<get-var ref>"></a>
    <strong id="faq">%body</strong>\
    &nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.8/ssl_faq.html#<get-var ref>"><b>L</b></a>]
    <p>
<restore toc>
<restore ref>
</define-tag>


<h2>About the module</h2>

<ul>

<faq ref="history" toc="What is the history of mod_ssl?">
What is the history of mod_ssl?
</faq>

    The mod_ssl v1 package was initially created in April 1998 by <a
    href="mailto:[e-mail]">Ralf S.  Engelschall</a> via porting <a
    href="mailto:[e-mail]">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.

<faq ref="apssl-diff" toc="Apache-SSL vs. mod_ssl: differences?">
What are the functional differences between mod_ssl and Apache-SSL, from where
it is originally derived?
</faq>

    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.

<faq ref="apssl-diff" toc="mod_ssl vs. commercial alternatives?">
What are the major differences between mod_ssl and
the commercial alternatives like Raven or Stronghold?
</faq>

    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:[e-mail]">
    <code>[e-mail]</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.

<faq ref="what-version" toc="mod_ssl/Apache versions?">
How do I know which mod_ssl version is for which Apache version?
</faq>

    That's trivial: mod_ssl uses version strings of the syntax
    <em>&lt;mod_ssl-version&gt;</em>-<em>&lt;apache-version&gt;</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 ;-).

<faq ref="y2k" toc="mod_ssl and Year 2000?">
Is mod_ssl Year 2000 compliant?
</faq>

    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 &amp; 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="http://www.apache.org/docs/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 underlaying Operating System
    (either a Unix or Win32 platform) is Year 2000 compliant is a different
    question which cannot be answered here.

<faq ref="wassenaar" toc="mod_ssl and Wassenaar Arrangement?">
What about mod_ssl and the Wassenaar Arrangement?
</faq>

    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>About Installation</h2>

<ul>

<faq ref="core-dbm" toc="Core dumps for HTTPS requests?">
When I access my website the first time via HTTPS I get a core dump?
</faq>

    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).

<faq ref="core-php3" toc="Core dumps for Apache+mod_ssl+PHP3?">
My Apache dumps core when I add both mod_ssl and PHP3?
</faq>

    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.

<faq ref="dso-sym" toc="Undefined symbols on startup?">
When I startup Apache I get errors about undefined symbols like ap_global_ctx?
</faq>