ssl_faq.wml

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

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

<faq ref="mutex-perm" toc="Permission problem on SSLMutex">
When I startup Apache I get permission errors related to SSLMutex?
</faq>

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

<faq ref="mm" toc="Shared memory and process size?">
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?
</faq>

    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.

<faq ref="mmpath" toc="Shared memory and pathname?">
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?
</faq>

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

<faq ref="entropy" toc="PRNG and not enough entropy?">
When I fire up the server, mod_ssl stops with the error
"Failed to generate temporary 512 bit RSA private key", why?
And a "PRNG not seeded" error occurs if I try "make certificate".
</faq>

    Cryptographic software needs a source of unpredictable data
    to work correctly. Many open source operating systems provide
    a "randomness device" that serves this purpose (usually named
    <code>/dev/random</code>). On other systems, applications have to
    seed the OpenSSL Pseudo Random Number Generator (PRNG) manually with
    appropriate data before generating keys or performing public key
    encryption. As of version 0.9.5, the OpenSSL functions that need
    randomness report an error if the PRNG has not been seeded with
    at least 128 bits of randomness. So mod_ssl has to provide enough
    entropy to the PRNG to work correctly. For this one has to use the
    <code>SSLRandomSeed</code> directives (to solve the run-time problem)
    and create a <code>$HOME/.rnd</code> file to make sure enough
    entropy is available also for the "<code>make certificate</code>"
    step (in case the "<code>make certificate</code>" procedure is not
    able to gather enough entropy theirself by searching for system
    files).
 
</ul>

<p>
<br>
<h2>About Configuration</h2>

<ul>

<faq ref="https-parallel" toc="HTTP and HTTPS with a single server?">
Is it possible to provide HTTP and HTTPS with a single server?</strong>
</faq>

    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.

<faq ref="https-port" toc="Where is the HTTPS port?">
I know that HTTP is on port 80, but where is HTTPS?
</faq>

    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>

<faq ref="https-test" toc="How to test HTTPS manually?">
How can I speak HTTPS manually for testing purposes?
</faq>

    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>

<faq ref="hang" toc="Why does my connection hang?">
Why does the connection hang when I connect to my SSL-aware Apache server?
</faq>

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

<faq ref="hang" toc="Why do I get connection refused?">
Why do I get ``Connection Refused'' messages when trying to access my freshly
installed Apache+mod_ssl server via HTTPS?
</faq>

    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. 

<faq ref="env-vars" toc="Why are the SSL_XXX variables missing?">
In my CGI programs and SSI scripts the various documented
<code>SSL_XXX</code> variables do not exists. Why?
</faq>

    Just make sure you have ``<code>SSLOptions +StdEnvVars</code>''
    enabled for the context of your CGI/SSI requests.

<faq ref="relative-links" toc="How to switch with relative hyperlinks?">
How can I use relative hyperlinks to switch between HTTP and HTTPS?
</faq>

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

<ul>

<faq ref="what-is" toc="What are Keys, CSRs and Certs?">
What are RSA Private Keys, CSRs and Certificates?</strong>
</faq>

    The RSA private key file is a digital file that you can use to decrypt
    messages sent to you. It has a public component which you distribute (via
    your Certificate file) which allows people to encrypt those messages to
    you. A Certificate Signing Request (CSR) is a digital file which contains
    your public key and your name. You send the CSR to a Certifying Authority
    (CA) to be converted into a real Certificate. A Certificate contains your
    RSA public key, your name, the name of the CA, and is digitally signed by
    your CA.  Browsers that know the CA can verify the signature on that
    Certificate, thereby obtaining your RSA public key. That enables them to
    send messages which only you can decrypt.
    See the <a href="ssl_intro.html">Introduction</a> chapter for a general
    description of the SSL protocol.

<faq ref="startup" toc="Difference on startup?">
Seems like there is a difference on startup between the original Apache and an SSL-aware Apache?
</faq>

    Yes, in general, starting Apache with a built-in mod_ssl is just like
    starting an unencumbered Apache, except for the fact that when you have a
    pass phrase on your SSL private key file. Then a startup dialog pops up
    asking you to enter the pass phrase. 
    <p>
    To type in the pass phrase manually when starting the server can be
    problematic, for instance when starting the server from the system boot
    scripts.  As an alternative to this situation you can follow the steps
    below under ``How can I get rid of the pass-phrase dialog at Apache
    startup time?''.

<faq ref="cert-dummy" toc="How to create a dummy cert?">
How can I create a dummy SSL server Certificate for testing purposes?
</faq>

    A Certificate does not have to be signed by a public CA. You can use your
    private key to sign the Certificate which contains your public key. You
    can install this Certificate into your server, and people using Netscape
    Navigator (not MSIE) will be able to connect after clicking OK to a
    warning dialogue. You can get MSIE to work, and your customers can
    eliminate the dialogue, by installing that Certificate manually into their
    browsers.
    <p>
    Just use the ``<code>make certificate</code>'' command at the top-level
    directory of the Apache source tree right before installing Apache via
    ``<code>make install</code>''. This creates a self-signed SSL Certificate
    which expires after 30 days and isn't encrypted (which means you don't
    need to enter a pass-phrase at Apache startup time).
    <p>
    BUT REMEMBER: YOU REALLY HAVE TO CREATE A REAL CERTIFICATE FOR THE LONG
    RUN! HOW THIS IS DONE IS DESCRIBED IN THE NEXT ANSWER.

<faq ref="cert-real" toc="How to create a real cert?">
Ok, I've got my server installed and want to create a real SSL
server Certificate for it. How do I do it?
</faq>

    Here is a step-by-step description:
    <p>
    <ol>
    <li>Make sure OpenSSL is really installed and in your <code>PATH</code>.
        But some commands even work ok when you just run the
        ``<code>openssl</code>'' program from within the OpenSSL source tree as
        ``<code>./apps/openssl</code>''.
    <p>
    <li>Create a RSA private key for your Apache server
       (will be Triple-DES encrypted and PEM formatted):

       <p>
       <code><strong>$ openssl genrsa -des3 -out server.key 1024</strong></code>

       <p>
       Please backup this <code>server.key</code> file and remember the
       pass-phrase you had to enter at a secure location.
       You can see the details of this RSA private key via the command:

       <p>
       <code><strong>$ openssl rsa -noout -text -in server.key</strong></code>

       <p>
       And you could create a decrypted PEM version (not recommended) 
       of this RSA private key via:

       <p>
       <code><strong>$ openssl rsa -in server.key -out server.key.unsecure</strong></code>

    <p>
    <li>Create a Certificate Signing Request (CSR) with the server RSA private
       key (output will be PEM formatted):
      
       <p>
       <code><strong>$ openssl req -new -key server.key -out server.csr</strong></code>

       <p>
       Make sure you enter the FQDN ("Fully Qualified Domain Name") of the
       server when OpenSSL prompts you for the "CommonName", i.e.  when you
       generate a CSR for a website which will be later accessed via
       <code>https://www.foo.dom/</code>, enter "www.foo.dom" here.
       You can see the details of this CSR via the command

       <p>
       <code><strong>$ openssl req -noout -text -in server.csr</strong></code>

    <p>
    <li>You now have to send this Certificate Signing Request (CSR) to
       a Certifying Authority (CA) for signing. The result is then a real
       Certificate which can be used for Apache. Here you have two options:

       First you can let the CSR sign by a commercial CA like Verisign or
       Thawte. Then you usually have to post the CSR into a web form, pay for
       the signing and await the signed Certificate you then can store into a
       server.crt file. For more information about commercial CAs have a look
       at the following locations:

       <p>
       <ul>
       <li>  Verisign<br>
             <a href="http://digitalid.verisign.com/server/apacheNotice.htm">
             http://digitalid.verisign.com/server/apacheNotice.htm
             </a>
       <li>  Thawte Consulting<br>
             <a href="http://www.thawte.com/certs/server/request.html">
             http://www.thawte.com/certs/server/request.html 
             </a>
       <li>  CertiSign Certificadora Digital Ltda.<br>
             <a href="http://www.certisign.com.br">
             http://www.certisign.com.br 
             </a>
       <li>  IKS GmbH<br>