ssl_faq.html

apach加密模块

    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>&nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.6/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've 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>&nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.6/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>&nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.6/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>&nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.6/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>&nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.6/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>&nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.6/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>.
</ul>
<p>
<br>
<H2><a name="ToC15">About Configuration</a></H2>
<ul>
<p>
<li><a name="ToC16"></a>
    <a name="https-parallel"></a>
    <strong id="faq">Is it possible to provide HTTP and HTTPS with a single server?</strong></strong>&nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.6/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="ToC17"></a>
    <a name="https-port"></a>
    <strong id="faq">I know that HTTP is on port 80, but where is HTTPS?</strong>&nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.6/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="ToC18"></a>
    <a name="https-test"></a>
    <strong id="faq">How can I speak HTTPS manually for testing purposes?</strong>&nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.6/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="ToC19"></a>
    <a name="hang"></a>
    <strong id="faq">Why does the connection hang when I connect to my SSL-aware Apache server?</strong>&nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.6/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="ToC20"></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>&nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.6/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>&lt;VirtualHost&gt;</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="ToC21"></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>&nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.6/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="ToC22"></a>
    <a name="relative-links"></a>
    <strong id="faq">How can I use relative hyperlinks to switch between HTTP and HTTPS?</strong>&nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.6/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>
    &lt;a href="document.html:SSL"&gt
    </pre>
</ul>
<p>
<br>
<H2><a name="ToC23">About Certificates</a></H2>
<ul>
<p>
<li><a name="ToC24"></a>
    <a name="what-is"></a>
    <strong id="faq">What are RSA Private Keys, CSRs and Certificates?</strong></strong>&nbsp;&nbsp;
    [<a href="http://www.modssl.org/docs/2.6/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