<p>This chapter is a collection of frequently asked questions (FAQ) and
corresponding answers following the popular USENET tradition. Most of these
questions occurred on the Newsgroup <code><a href="news:comp.infosystems.www.servers.unix">comp.infosystems.www.servers.unix</a></code> or the mod_ssl Support
Mailing List <code><a href="mailto:modssl-users@modssl.org">modssl-users@modssl.org</a></code>. They are collected at this place
to avoid answering the same questions over and over.</p>
<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.</p>
</div>
<div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#about">About The Module</a></li>
<h2><a name="about" id="about">About The Module</a></h2>
<ul>
<li><a href="#history">What is the history of mod_ssl?</a></li>
<li><a href="#y2k">mod_ssl and Year 2000?</a></li>
<li><a href="#wassenaar">mod_ssl and Wassenaar Arrangement?</a></li>
</ul>
<h3><a name="history" id="history">What is the history of mod_ssl?</a></h3>
<p>The mod_ssl v1 package was initially created in April 1998 by <a href="mailto:rse@engelschall.com">Ralf S. Engelschall</a> via porting <a href="mailto:ben@algroup.co.uk">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 publicly 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>
<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.</p>
<p>After the US export restrictions for cryptographic software were
opened, mod_ssl was integrated into the code base of Apache V2 in 2001.</p>
<h3><a name="y2k" id="y2k">Is mod_ssl Year 2000 compliant?</a></h3>
<p>Yes, mod_ssl is Year 2000 compliant.</p>
<p>Because first mod_ssl internally never stores years as two digits.
Instead it always uses the ANSI C & 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>
<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 underlying Operating System
(either a Unix or Win32 platform) is Year 2000 compliant is a different
question which cannot be answered here.</p>
<h3><a name="wassenaar" id="wassenaar">What about mod_ssl and the Wassenaar Arrangement?</a></h3>
<p>First, let us explain what <dfn>Wassenaar</dfn> and its <dfn>Arrangement on
Export Controls for Conventional Arms and Dual-Use Goods and
Technologies</dfn> is: This is a international regime, established 1995, to
control trade in conventional arms and dual-use goods and technology. It
replaced the previous <dfn>CoCom</dfn> regime. 33 countries are signatories:
<h3><a name="verisign" id="verisign">I try to install a Verisign certificate. Why can't I find neither the
<code>getca</code> nor <code>getverisign</code> programs Verisign mentions?</a></h3>
<p>This is because Verisign has never provided specific instructions
for Apache+mod_ssl. Rather they tell you what you should do
if you were using C2Net's Stronghold (a commercial Apache
based server with SSL support). The only thing you have to do
is to save the certificate into a file and give the name of
that file to the <code>SSLCertificateFile</code> directive.
Remember that you need to give the key file in as well (see
<code>SSLCertificateKeyFile</code> directive). For a better
CA-related overview on SSL certificate fiddling you can look at <a href="http://www.thawte.com/html/SUPPORT/server/softwaredocs/modssl.html">Thawte's mod_ssl instructions</a>.</p>
<h3><a name="sgc" id="sgc">Can I use the Server Gated Cryptography (SGC) facility (aka Verisign Global
ID) also with mod_ssl?</a></h3>
<p>Yes, mod_ssl since version 2.1 supports the SGC facility. You don't have
to configure anything special for this, just use a Global ID as your
server certificate. The <em>step up</em> of the clients are then
automatically handled by mod_ssl under run-time. For details please read
the <code>README.GlobalID</code> document in the mod_ssl distribution.</p>
<h3><a name="gid" id="gid">After I have installed my new Verisign Global ID server certificate, the
browsers complain that they cannot verify the server certificate?</a></h3>
<p>That is because Verisign uses an intermediate CA certificate between
the root CA certificate (which is installed in the browsers) and
the server certificate (which you installed in the server). You
should have received this additional CA certificate from Verisign.
If not, complain to them. Then configure this certificate with the
<code>SSLCertificateChainFile</code> directive in the server. This
makes sure the intermediate CA certificate is send to the browser
and this way fills the gap in the certificate chain.</p>
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.
</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>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.
</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, 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).
</li>
<li><em>Write 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 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.
</li>
</ol>
<h3><a name="reportdetails" id="reportdetails">What information and details should I
provide when writing a bug report?</a></h3>
<p>You have to at least always provide 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 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.
</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. Alternatively you can at least
provide the <code>configure</code> command line you used.
</dd>
<dt>In case of core dumps please include a Backtrace</dt>
<dd>In case your Apache+mod_ssl+OpenSSL should really dump 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.
</dd>
<dt>A detailed description of your problem</dt>
<dd>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.
</dd>
</dl>
<h3><a name="coredumphelp" id="coredumphelp">I got 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">Ok, I got a core dump but how do I get a backtrace to find out the reason for it?</a></h3>
<p>Follow the following steps:</p>
<ol>
<li>Make sure you have debugging symbols available in at least
Apache. 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.
</li>
<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.
</li>
<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.
</li>
</ol>
</div></div>
<div class="bottomlang">
<p><span>Available Languages: </span><a href="../en/ssl/ssl_faq.html" title="English"> en </a></p>
</div><div id="footer">
<p class="apache">Copyright 1999-2004 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>
