ssl_faq.wml

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

    Usually just all SSL ciphers which are supported by the
    version of OpenSSL in use (can depend on the way you built
    OpenSSL). Typically this at least includes the following:
    <p>
    <ul>
    <li>RC4 with MD5 
    <li>RC4 with MD5 (export version restricted to 40-bit key) 
    <li>RC2 with MD5 
    <li>RC2 with MD5 (export version restricted to 40-bit key) 
    <li>IDEA with MD5 
    <li>DES with MD5 
    <li>Triple-DES with MD5 
    </ul>
    <p>
    To determine the actual list of supported ciphers you can
    run the following command:
    <p>
    <code><strong>$ openssl ciphers -v</strong></code><br>

<faq ref="cipher-adh" toc="How to use Anonymous-DH ciphers">
I want to use Anonymous Diffie-Hellman (ADH) ciphers, but I always get ``no
shared cipher'' errors?
</faq>

    In order to use Anonymous Diffie-Hellman (ADH) ciphers, it is not enough
    to just put ``<code>ADH</code>'' into your <code>SSLCipherSuite</code>.
    Additionally you have to build OpenSSL with
    ``<code>-DSSL_ALLOW_ADH</code>''. Because per default OpenSSL does not
    allow ADH ciphers for security reasons. So if you are actually enabling
    these ciphers make sure you are informed about the side-effects.

<faq ref="cipher-shared" toc="Why do I get 'no shared ciphers'?">
I always just get a 'no shared ciphers' error if
I try to connect to my freshly installed server?
</faq>
  
    Either you have messed up your <code>SSLCipherSuite</code>
    directive (compare it with the pre-configured example in
    <code>httpd.conf-dist</code>) or you have choosen the DSA/DH
    algorithms instead of RSA under "<code>make certificate</code>"
    and ignored or overseen the warnings. Because if you have choosen
    DSA/DH, then your server no longer speaks RSA-based SSL ciphers
    (at least not until you also configure an additional RSA-based
    certificate/key pair). But current browsers like NS or IE only speak
    RSA ciphers. The result is the "no shared ciphers" error. To fix
    this, regenerate your server certificate/key pair and this time
    choose the RSA algorithm.

<faq ref="vhosts" toc="HTTPS and name-based vhosts">
Why can't I use SSL with name-based/non-IP-based virtual hosts?
</faq>

    The reason is very technical. Actually it's some sort of a chicken and
    egg problem: The SSL protocol layer stays below the HTTP protocol layer
    and encapsulates HTTP. When an SSL connection (HTTPS) is established
    Apache/mod_ssl has to negotiate the SSL protocol parameters with the
    client. For this mod_ssl has to consult the configuration of the virtual
    server (for instance it has to look for the cipher suite, the server
    certificate, etc.). But in order to dispatch to the correct virtual server
    Apache has to know the <code>Host</code> HTTP header field.  For this the
    HTTP request header has to be read. This cannot be done before the SSL
    handshake is finished. But the information is already needed at the SSL
    handshake phase. Bingo!

<faq ref="lock-icon" toc="The lock icon in Netscape locks very late">
When I use Basic Authentication over HTTPS the lock icon in Netscape browsers
still show the unlocked state when the dialog pops up. Does this mean the
username/password is still transmitted unencrypted?
</faq>

    No, the username/password is already transmitted encrypted.  The icon in
    Netscape browsers is just not really synchronized with the SSL/TLS layer
    (it toggles to the locked state when the first part of the actual webpage
    data is transferred which is not quite correct) and this way confuses
    people. The Basic Authentication facility is part of the HTTP layer and
    this layer is above the SSL/TLS layer in HTTPS.  And before any HTTP data
    communication takes place in HTTPS the SSL/TLS layer has already done the
    handshake phase and switched to encrypted communication. So, don't get
    confused by this icon.

<faq ref="io-ie" toc="Why do I get I/O errors with MSIE clients?">
When I connect via HTTPS to an Apache+mod_ssl+OpenSSL server with Microsoft Internet
Explorer (MSIE) I get various I/O errors. What is the reason?
</faq>

    The first reason is that the SSL implementation in some MSIE versions has
    some subtle bugs related to the HTTP keep-alive facility and the SSL close
    notify alerts on socket connection close. Additionally the interaction
    between SSL and HTTP/1.1 features are problematic with some MSIE versions,
    too. You've to work-around these problems by forcing
    Apache+mod_ssl+OpenSSL to not use HTTP/1.1, keep-alive connections or
    sending the SSL close notify messages to MSIE clients. This can be done by
    using the following directive in your SSL-aware virtual host section:

    <pre>
    SetEnvIf User-Agent ".*MSIE.*" \\
             <b>nokeepalive ssl-unclean-shutdown \\
             downgrade-1.0 force-response-1.0</b>\
    </pre>

    Additionally it is known some MSIE versions have also problems
    with particular ciphers. Unfortunately one cannot workaround these
    bugs only for those MSIE particular clients, because the ciphers
    are already used in the SSL handshake phase. So a MSIE-specific
    <tt>SetEnvIf</tt> doesn't work to solve these problems. Instead one
    has to do more drastic adjustments to the global parameters. But
    before you decide to do this, make sure your clients really have
    problems. If not, do not do this, because it affects all(!) your
    clients, i.e., also your non-MSIE clients.
    
    <p>
    The next problem is that 56bit export versions of MSIE 5.x browsers have a
    broken SSLv3 implementation which badly interacts with OpenSSL versions
    greater than 0.9.4. You can either accept this and force your clients to
    upgrade their browsers, or you downgrade to OpenSSL 0.9.4 (hmmm), or you
    can decide to workaround it by accepting the drawback that your workaround
    will horribly affect also other browsers:
    
    <pre>
    SSLProtocol all <b>-SSLv3</b>\
    </pre>

    This completely disables the SSLv3 protocol and lets those browsers work.
    But usually this is an even less acceptable workaround. A more reasonable
    workaround is to address the problem more closely and disable only the
    ciphers which cause trouble.
    
    <pre>
    SSLCipherSuite ALL:!ADH:<b>!EXPORT56</b>:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP\
    </pre>

    This also lets the broken MSIE versions work, but only removes the
    newer 56bit TLS ciphers.
    
    <p>
    Another problem with MSIE 5.x clients is that they refuse to connect to
    URLs of the form <tt>https://12.34.56.78/</tt> (IP-addresses are used
    instead of the hostname), if the server is using the Server Gated
    Cryptography (SGC) facility. This can only be avoided by using the fully
    qualified domain name (FQDN) of the website in hyperlinks instead, because
    MSIE 5.x has an error in the way it handles the SGC negotiation.

    <p>
    And finally there are versions of MSIE which seem to require that
    an SSL session can be reused (a totally non standard-conforming
    behaviour, of course). Connection with those MSIE versions only work
    if a SSL session cache is used. So, as a work-around, make sure you
    are using a session cache (see <tt>SSLSessionCache</tt> directive).

<faq ref="io-ns" toc="Why do I get I/O errors with NS clients?">
When I connect via HTTPS to an Apache+mod_ssl server with Netscape Navigator I
get I/O errors and the message "Netscape has encountered bad data from the
server" What's the reason?
</faq>

    The problem usually is that you had created a new server certificate with
    the same DN, but you had told your browser to accept forever the old
    server certificate. Once you clear the entry in your browser for the old
    certificate, everything usually will work fine. Netscape's SSL
    implementation is correct, so when you encounter I/O errors with Netscape
    Navigator it is most of the time caused by the configured certificates.

</ul>

<p>
<br>
<h2>About Support</h2>

<ul>

<faq ref="resources" toc="Resources in case of problems?">
What information resources are available in case of mod_ssl problems?
</faq>

The following information resources are available.
In case of problems you should search here first.

<p>
<ol>
<li><em>Answers in the User Manual's F.A.Q. List (this)</em><br>
    <a href="http://www.modssl.org/docs/2.8/ssl_faq.html">
    http://www.modssl.org/docs/2.8/ssl_faq.html</a><br>
    First look inside the F.A.Q. (this text), perhaps your problem is such
    popular that it was already answered a lot of times in the past.
<p>
<li><em>Postings from the modssl-users Support Mailing List</em>
    <a href="http://www.modssl.org/support/">
    http://www.modssl.org/support/</a><br>
    Second search for your problem in one of the existing archives of the
    modssl-users mailing list.  Perhaps your problem popped up at least once for
    another user, too.
<p>
<li><em>Problem Reports in the Bug Database</em>
    <a href="http://www.modssl.org/support/bugdb/">
    http://www.modssl.org/support/bugdb/</a><br>
    Third look inside the mod_ssl Bug Database. Perhaps
    someone else already has reported the problem.
</ol>

<faq ref="contact" toc="Support in case of problems?">
What support contacts are available in case of mod_ssl problems?
</faq>

The following lists all support possibilities for mod_ssl, in order of
preference, i.e. start in this order and do not pick the support possibility
you just like most, please. 

<p>
<ol>
<li><em>Write a Problem Report into the Bug Database</em><br>
    <a href="http://www.modssl.org/support/bugdb/">
    http://www.modssl.org/support/bugdb/</a><br>
    This is the preferred way of submitting your problem report, because this
    way it gets filed into the bug database (it cannot be lost) <em>and</em>
    send to the modssl-users mailing list (others see the current problems and
    learn from answers).
<p>
<li><em>Write a Problem Report to the modssl-users Support Mailing List</em><br>
    <a href="mailto:[e-mail]">
    modssl-users&nbsp;@&nbsp;modssl.org</a><br>
    This is the second way of submitting your problem report. You have to
    subscribe to the list first, but then you can easily discuss your problem
    with both the author and the whole mod_ssl user community.
<p>
<li><em>Write a Problem Report to the author</em><br>
    <a href="mailto:[e-mail]">
    rse&nbsp;@&nbsp;engelschall.com</a><br>
    This is the last way of submitting your problem report.  Please avoid this
    in your own interest because the author is really a very busy men. Your
    mail will always be filed to one of his various mail-folders and is
    usually not processed as fast as a posting on modssl-users.
</ol>

<faq ref="report-details" toc="How to write a problem report?">
What information and details I've to provide to
the author when writing a bug report?
</faq>

You have to at least always provide the following information:

<p>
<ul>
<li><em>Apache, mod_ssl and OpenSSL version information</em><br>
    The mod_ssl version you should really know. For instance, it's the version
    number in the distribution tarball.  The Apache version can be determined
    by running ``<code>httpd -v</code>''.  The OpenSSL version can be
    determined by running ``<code>openssl version</code>''.  Alternatively when
    you have Lynx installed you can run the command ``<code>lynx -mime_header
    http://localhost/ | grep Server</code>'' to determine all information in a
    single step.
<p>
<li><em>The details on how you built and installed Apache+mod_ssl+OpenSSL</em><br>
    For this you can provide a logfile of your terminal session which shows
    the configuration and install steps. Alternatively you can at least
    provide the author with the APACI `<code>configure</code>'' command line
    you used (assuming you used APACI, of course).

<p>
<li><em>In case of core dumps please include a Backtrace</em><br>
    In case your Apache+mod_ssl+OpenSSL should really dumped core please attach
    a stack-frame ``backtrace'' (see the next question on how to get it).
    Without this information the reason for your core dump cannot be found.
    So you have to provide the backtrace, please.
<p>
<li><em>A detailed description of your problem</em><br>
    Don't laugh, I'm totally serious. I already got a lot of problem reports
    where the people not really said what's the actual problem is. So, in your
    own interest (you want the problem be solved, don't you?) include as much
    details as possible, please. But start with the essentials first, of
    course.
</ul>

<faq ref="core-dumped" toc="I got a core dump, can you help me?">
I got a core dump, can you help me?
</faq>

    In general no, at least not unless you provide more details about the code
    location where Apache dumped core. What is usually always required in
    order to help you is a backtrace (see next question). Without this
    information it is mostly impossible to find the problem and help you in
    fixing it.

<faq ref="report-backtrace" toc="How to get a backtrace?">
Ok, I got a core dump but how do I get a backtrace to find out the reason for it?
</faq>

Follow the following steps:

<p>
<ol>
<li>Make sure you have debugging symbols available in at least
    Apache and mod_ssl. On platforms where you use GCC/GDB you have to build
    Apache+mod_ssl with ``<code>OPTIM="-g -ggdb3"</code>'' to achieve this. On
    other platforms at least ``<code>OPTIM="-g"</code>'' is needed.
<p>
<li>Startup the server and try to produce the core-dump. For this you perhaps
    want to use a directive like ``<code>CoreDumpDirectory /tmp</code>'' to
    make sure that the core-dump file can be written. You then should get a
    <code>/tmp/core</code> or <code>/tmp/httpd.core</code> file. When you
    don't get this, try to run your server under an UID != 0 (root), because
    most "current" kernels do not allow a process to dump core after it has
    done a <code>setuid()</code> (unless it does an <code>exec()</code>) for
    security reasons (there can be privileged information left over in
    memory).  Additionally you can run ``<code>/path/to/httpd -X</code>''
    manually to force Apache to not fork.
<p>
<li>Analyze the core-dump. For this run ``<code>gdb /path/to/httpd
    /tmp/httpd.core</code>'' or a similar command has to run. In GDB you then
    just have to enter the ``<code>bt</code>'' command and, voila, you get the
    backtrace. For other debuggers consult your local debugger manual.  Send
    this backtrace to the author.
</ol>

</ul>