<div class="example"><p><code>
      NameVirtualHost 192.168.1.1:80
    </code></p></div>
    
    <p>Other workaround solutions include: </p>

    <p>Using separate IP addresses for different SSL hosts. 
    Using different port numbers for different SSL hosts.</p> 


<h3><a name="comp" id="comp">How do I get SSL compression working?</a></h3>
<p>Although SSL compression negotiation was defined in the specification
of SSLv2 and TLS, it took until May 2004 for RFC 3749 to define DEFLATE as
a negotiable standard compression method.
</p>
<p>OpenSSL 0.9.8 started to support this by default when compiled with the
<code>zlib</code> option. If both the client and the server support compression,
it will be used. However, most clients still try to initially connect with an
SSLv2 Hello. As SSLv2 did not include an array of prefered compression algorithms
in its handshake, compression cannot be negotiated with these clients.
If the client disables support for SSLv2, either an SSLv3 or TLS Hello
may be sent, depending on which SSL library is used, and compression may 
be set up. You can verify whether clients make use of SSL compression by 
logging the <code>%{SSL_COMPRESS_METHOD}x</code> variable.
</p>


<h3><a name="lockicon" id="lockicon">When I use Basic Authentication over HTTPS 
the lock icon in Netscape browsers stays unlocked when the dialog pops up. 
Does this mean the username/password is being sent unencrypted?</a></h3>
<p>No, the username/password is transmitted encrypted. The icon in
    Netscape browsers is not actually synchronized with the SSL/TLS layer.
    It only toggles to the locked state when the first part of the actual 
    webpage data is transferred, which may confuse people. The Basic 
    Authentication facility is part of the HTTP layer, which is above 
    the SSL/TLS layer in HTTPS. Before any HTTP data communication takes 
    place in HTTPS, the SSL/TLS layer has already completed its handshake 
    phase, and switched to encrypted communication. So don't be
    confused by this icon.</p>


<h3><a name="msie" id="msie">Why do I get I/O errors when connecting via 
HTTPS to an Apache+mod_ssl server with Microsoft Internet Explorer (MSIE)?</a></h3>
<p>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 in some MSIE versions. 
    You can work around these problems by forcing Apache not to use HTTP/1.1, 
    keep-alive connections or send the SSL close notify messages to MSIE clients. 
    This can be done by using the following directive in your SSL-aware 
    virtual host section:</p>
    <div class="example"><p><code>
    SetEnvIf User-Agent ".*MSIE.*" \<br />
             nokeepalive ssl-unclean-shutdown \<br />
             downgrade-1.0 force-response-1.0
    </code></p></div>
    <p>Further, some MSIE versions have problems with particular ciphers. 
    Unfortunately, it is not possible to implement a MSIE-specific 
    workaround for this, because the ciphers are needed as early as the 
    SSL handshake phase. So a MSIE-specific 
    <code class="directive"><a href="../mod/mod_setenvif.html#setenvif">SetEnvIf</a></code> won't solve these 
    problems. Instead, you will have to make more drastic
    adjustments to the global parameters. Before you decide to do
    this, make sure your clients really have problems. If not, do not 
    make these changes - they will affect <em>all</em> your clients, MSIE
    or otherwise.</p>

    <p>The next problem is that 56bit export versions of MSIE 5.x 
    browsers have a broken SSLv3 implementation, which interacts badly 
    with OpenSSL versions greater than 0.9.4. You can accept this and 
    require your clients to upgrade their browsers, you can downgrade to 
    OpenSSL 0.9.4 (not advised), or you can work around this, accepting 
    that your workaround will affect other browsers too:</p>
    <div class="example"><p><code>SSLProtocol all -SSLv3</code></p></div>
    <p>will completely disables the SSLv3 protocol and allow those 
    browsers to work. A better workaround is to disable only those 
    ciphers which cause trouble.</p>
    <div class="example"><p><code>SSLCipherSuite
    ALL:!ADH:<strong>!EXPORT56</strong>:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP</code>
    </p></div>

    <p>This also allows the broken MSIE versions to work, but only removes the
    newer 56bit TLS ciphers.</p>
    
    <p>Another problem with MSIE 5.x clients is that they refuse to connect to
    URLs of the form <code>https://12.34.56.78/</code> (where 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>
    
    <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). Connecting 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 the <code class="directive"><a href="../mod/mod_ssl.html#sslsessioncache">SSLSessionCache</a></code> directive).</p>


<h3><a name="nn" id="nn">Why do I get I/O errors, or the message "Netscape has
encountered bad data from the server", when connecting via
HTTPS to an Apache+mod_ssl server with Netscape Navigator?</a></h3>
<p>
    This usually occurs when you have created a new server certificate for
    a given domain, but had previously told your browser to always accept 
    the old server certificate. Once you clear the entry for the old 
    certificate from your browser, everything should be fine. Netscape's SSL
    implementation is correct, so when you encounter I/O errors with Netscape
    Navigator it is usually caused by the configured certificates.</p>

</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="support" id="support">mod_ssl Support</a></h2>
<ul>
<li><a href="#resources">What information resources are available in 
case of mod_ssl problems?</a></li>
<li><a href="#contact">What support contacts are available in case of 
mod_ssl problems?</a></li>
<li><a href="#reportdetails">What information should I 
provide when writing a bug report?</a></li>
<li><a href="#coredumphelp">I had a core dump, can you help me?</a></li>
<li><a href="#backtrace">How do I get a backtrace, to help find the reason
for my core dump?</a></li>
</ul>

<h3><a name="resources" id="resources">What information resources are available in case of mod_ssl problems?</a></h3>
<p>The following information resources are available.
    In case of problems you should search here first.</p>

    <dl>
    <dt>Answers in the User Manual's F.A.Q. List (this)</dt>
    <dd><a href="http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html">
	http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html</a><br />
	First check the F.A.Q. (this text). If your problem is a common
	one, it may have been answered several times before, and been included
	in this doc.
    </dd>
    <dt>Postings from the modssl-users Support Mailing List
        <a href="http://www.modssl.org/support/">http://www.modssl.org/support/</a></dt>
    <dd>Search for your problem in the archives of the modssl-users mailing list. 
	You're probably not the first person to have had this problem!
    </dd>
    </dl>


<h3><a name="contact" id="contact">What support contacts are available in case 
of mod_ssl problems?</a></h3>
 <p>The following lists all support possibilities for mod_ssl, in order of
	 preference. Please go through these possibilities 
	 <em>in this order</em> - don't just pick the one you like the look of. </p>
    <ol>
    <li><em>Send a Problem Report to the modssl-users Support Mailing List</em><br />
        <a href="mailto:modssl-users@modssl.org">
        modssl-users@modssl.org</a><br />
        This is the preferred way of submitting your problem report, because this way,
	others can see the problem, and learn from any answers. You must subscribe to 
        the list first, but you can then easily discuss your problem with both the 
	author and the whole mod_ssl user community.
        </li>

    <li><em>Send a Problem Report to the Apache httpd Users Support Mailing List</em><br />
        <a href="mailto:users@httpd.apache.org">
        users@httpd.apache.org</a><br />
        This is the second way of submitting your problem report. Again, you must
        subscribe to the list first, but you can then easily discuss your problem
        with the whole Apache httpd user community.
    </li>

    <li><em>Write a Problem Report in the Bug Database</em><br />
	<a href="http://httpd.apache.org/bug_report.html">
	http://httpd.apache.org/bug_report.html</a><br />
        This is the last way of submitting your problem report. You should only
	do this if you've already posted to the mailing lists, and had no success.
	Please follow the instructions on the above page <em>carefully</em>.
    </li>
    </ol>


<h3><a name="reportdetails" id="reportdetails">What information should I
provide when writing a bug report?</a></h3>
<p>You should always provide at least the following information:</p>

    <dl>
    <dt>Apache and OpenSSL version information</dt>
    <dd>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, if
        you have Lynx installed, you can run the command <code>lynx -mime_header
        http://localhost/ | grep Server</code> to gather this information in a
        single step.
    </dd>

    <dt>The details on how you built and installed Apache+mod_ssl+OpenSSL</dt>
    <dd>For this you can provide a logfile of your terminal session which shows
    the configuration and install steps. If this is not possible, you 
    should at least provide the <code class="program"><a href="../programs/configure.html">configure</a></code> command line you used.
    </dd>

    <dt>In case of core dumps please include a Backtrace</dt>
    <dd>If your Apache+mod_ssl+OpenSSL dumps its core, please attach
    a stack-frame ``backtrace'' (see <a href="#backtrace">below</a> 
    for information on how to get this). Without this information, the 
    reason for your core dump cannot be found
    </dd>
    
    <dt>A detailed description of your problem</dt>
    <dd>Don't laugh, we really mean it! Many problem reports don't 
    include a description of what the actual problem is. Without this,
    it's very difficult for anyone to help you. So, it's in your own 
    interest (you want the problem be solved, don't you?) to include as 
    much detail as possible, please. Of course, you should still include
    all the essentials above too.
    </dd>
    </dl>


<h3><a name="coredumphelp" id="coredumphelp">I had a core dump, can you help me?</a></h3>
<p>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.</p>


<h3><a name="backtrace" id="backtrace">How do I get a backtrace, to help find 
the reason for my core dump?</a></h3>
<p>Following are the steps you will need to complete, to get a backtrace:</p>
    <ol>
    <li>Make sure you have debugging symbols available, at least
        in Apache. On platforms where you use GCC/GDB, you will have to build
        Apache+mod_ssl with ``<code>OPTIM="-g -ggdb3"</code>'' to get this. On
        other platforms at least ``<code>OPTIM="-g"</code>'' is needed.
    </li>

    <li>Start the server and try to reproduce the core-dump. For this you may
        want to use a directive like ``<code>CoreDumpDirectory /tmp</code>'' to
	make sure that the core-dump file can be written. This should result
	in a <code>/tmp/core</code> or <code>/tmp/httpd.core</code> file. If you
        don't get one of these, try running your server under a non-root UID. 
        Many modern 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). If necessary, you can run <code>/path/to/httpd -X</code>
        manually to force Apache to not fork.
    </li>

    <li>Analyze the core-dump. For this, run <code>gdb /path/to/httpd
        /tmp/httpd.core</code> or a similar command. In GDB, all you 
	have to do then is to enter <code>bt</code>, and voila, you get the
        backtrace. For other debuggers consult your local debugger manual. 
    </li>
    </ol>

</div></div>
<div class="bottomlang">
<p><span>Available Languages: </span><a href="../en/ssl/ssl_faq.html" title="English">&nbsp;en&nbsp;</a></p>
</div><div id="footer">
<p class="apache">Copyright 2006 The Apache Software Foundation.<br />Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
<p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossary</a> | <a href="../sitemap.html">Sitemap</a></p></div>
</body></html>