Errors such as ``mod_ssl: Child could not open
SSLMutex lockfile /opt/apache/logs/ssl_mutex.18332 (System error follows)
[...] System: Permission denied (errno: 13)'' are usually
caused by overly restrictive permissions on the parent directories.
Make sure that all parent directories (here /opt,
/opt/apache and /opt/apache/logs) have the x-bit
set for, at minimum, the UID under which Apache's children are running (see
the User directive).

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
/dev/random). 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.

To prevent this error, mod_ssl has to provide
enough entropy to the PRNG to allow it to work correctly. This can
be done via the SSLRandomSeed
directive.

Yes. HTTP and HTTPS use different server ports (HTTP binds to
port 80, HTTPS to port 443), so there is no direct conflict between
them. You can either run two separate server instances bound to
these ports, or use Apache's elegant virtual hosting facility to
create two virtual servers, both served by the same instance of Apache
- one responding over HTTP to requests on port 80, and the other
responding over HTTPS to requests on port 443.

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. For
example, if your server is set up to serve pages over HTTPS on port 8080,
you can access them at https://example.com:8080/

for simple testing of Apache via HTTP, it's not so easy for
HTTPS because of the SSL protocol between TCP and HTTP. With the
help of OpenSSL's s_client command, however, you can
do a similar check via HTTPS:

Before the actual HTTP response you will receive detailed
information about the SSL handshake. For a more general command
line client which directly understands both HTTP and HTTPS, can
perform GET and POST operations, can use a proxy, supports byte
ranges, etc. you should have a look at the nifty
cURL tool. Using this, you can
check that Apache is responding correctly to requests via HTTP and
HTTPS as follows:

This can happen when you try to connect to a HTTPS server (or virtual
server) via HTTP (eg, using http://example.com/ instead of
https://example.com). It can also happen when trying to
connect via HTTPS to a HTTP server (eg, using
https://example.com/ on a server which doesn't support HTTPS,
or which supports it on a non-standard port). Make sure that you're
connecting to a (virtual) server that supports SSL.

This error can be caused by an incorrect configuration.
Please make sure that your Listen directives match your
<VirtualHost>
directives. If all else fails, please start afresh, using the default
configuration provided by mod_ssl.

Usually, to switch between HTTP and HTTPS, you have to use
fully-qualified hyperlinks (because you have to change the URL
scheme). Using mod_rewrite however, you can
manipulate relative hyperlinks, to achieve the same effect.

An 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), who will convert it into a real Certificate, by signing it.

A Certificate contains your
RSA public key, your name, the name of the CA, and is digitally signed by
the 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 Introduction chapter for a general
description of the SSL protocol.

Yes. In general, starting Apache with
mod_ssl built-in is just like starting Apache
without it. However, if you have a passphrase on your SSL private
key file, a startup dialog will pop up which asks you to enter the
pass phrase.

Having to manually enter the passphrase when starting the server
can be problematic - for example, when starting the server from the
system boot scripts. In this case, you can follow the steps
below to remove the passphrase from
your private key. Bear in mind that doing so brings additional security
risks - proceed with caution!

It is important that you are aware that this
server.key does not have any passphrase.
To add a passphrase to the key, you should run the following
command, and enter & verify the passphrase as requested.

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
https://www.foo.dom/, enter "www.foo.dom" here.
You can see the details of this CSR by using

$ openssl req -noout -text -in server.csr

You now have to send this Certificate Signing Request (CSR) to
a Certifying Authority (CA) to be signed. Once the CSR has been
signed, you will have a real Certificate, which can be used by
Apache. You can have a CSR signed by a commercial CA, or you can
create your own CA to sign it.
Commercial CAs usually ask you to post the CSR into a web form,
pay for the signing, and then send a signed Certificate, which
you can store in a server.crt file.
For details on how to create your own CA, and use this to sign
a CSR, see below.
Once your CSR has been signed, you can see the details of the
Certificate as follows:

$ openssl x509 -noout -text -in server.crt

You should now have two files: server.key and
server.crt. These can be used as follows in your
httpd.conf file:

The short answer is to use the CA.sh or CA.pl
script provided by OpenSSL. Unless you have a good reason not to,
you should use these for preference. If you cannot, you can create a
self-signed Certificate as follows:

The first time you're asked for a PEM pass-phrase, you should
enter the old pass-phrase. After that, you'll be asked again to
enter a pass-phrase - this time, use the new pass-phrase. If you
are asked to verify the pass-phrase, you'll need to enter the new
pass-phrase a second time.

The reason this dialog pops up at startup and every re-start
is that the RSA private key inside your server.key file is stored in
encrypted format for security reasons. The pass-phrase is needed to decrypt
this file, so it can be read and parsed. Removing the pass-phrase
removes a layer of security from your server - proceed with caution!

Remove the encryption from the RSA private key (while
keeping a backup copy of the original file):

Now server.key contains an unencrypted copy of the key.
If you point your server at this file, it will not prompt you for a
pass-phrase. HOWEVER, if anyone gets this key they will be able to
impersonate you on the net. PLEASE make sure that the permissions on this
file are such that only root or the web server user can read it
(preferably get your web server to start as root but run as another
user, and have the key readable only by root).

As an alternative approach you can use the ``SSLPassPhraseDialog
exec:/path/to/program'' facility. Bear in mind that this is
neither more nor less secure, of course.

A private key contains a series of numbers. Two of these numbers form
the "public key", the others are part of the "private key". The "public
key" bits are included when you generate a CSR, and subsequently form
part of the associated Certificate.

To check that the public key in your Certificate matches the public
portion of your private key, you simply need to compare these numbers.
To view the Certificate and the key run the commands:

The `modulus' and the `public exponent' portions in the key and the
Certificate must match. As the public exponent is usually 65537
and it's difficult to visually check that the long modulus numbers
are the same, you can use the following approach:

This leaves you with two rather shorter numbers to compare. It is,
in theory, possible that these numbers may be the same, without the
modulus numbers being the same, but the chances of this are
overwhelmingly remote.

Should you wish to check to which key or certificate a particular
CSR belongs you can perform the same calculation on the CSR as
follows:

The default certificate format for OpenSSL is PEM, which is simply
Base64 encoded DER, with header and footer lines. For some applications
(e.g. Microsoft Internet Explorer) you need the certificate in plain DER
format. You can convert a PEM file cert.pem into the
corresponding DER file cert.der using the following command:
$ openssl x509 -in cert.pem -out cert.der -outform DER

One reason this might happen is because your server certificate is signed
by an intermediate CA. Various CAs, such as Verisign or Thawte, have started
signing certificates not with their root certificate but with intermediate
certificates.

Intermediate CA certificates lie between the root CA certificate (which is
installed in the browsers) and the server certificate (which you installed
on the server). In order for the browser to be able to traverse and verify
the trust chain from the server certificate to the root certificate it
needs need to be given the intermediate certificates. The CAs should
be able to provide you such intermediate certificate packages that can be
installed on the server.

There can be a number of reasons for this, but the main one
is problems with the SSL session Cache specified by the
SSLSessionCache directive. The DBM session
cache is the most likely source of the problem, so using the SHM session cache (or
no cache at all) may help.

SSL uses strong cryptographic encryption, which necessitates a lot of
number crunching. When you request a webpage via HTTPS, everything (even
the images) is encrypted before it is transferred. So increased HTTPS
traffic leads to load increases.

This is usually caused by a /dev/random device for
SSLRandomSeed which blocks the
read(2) call until enough entropy is available to service the
request. More information is available in the reference
manual for the SSLRandomSeed
directive.

Usually, any SSL ciphers supported by the version of OpenSSL in use,
are also supported by mod_ssl. Which ciphers are
available can depend on the way you built OpenSSL. Typically, at
least the following ciphers are supported:

RC4 with SHA1

AES with SHA1

Triple-DES with SHA1

To determine the actual list of ciphers available, you should run
the following:

Either you have made a mistake with your
SSLCipherSuite
directive (compare it with the pre-configured example in
extra/httpd-ssl.conf) or you chose to use DSA/DH
algorithms instead of RSA when you generated your private key
and ignored or overlooked the warnings. If you have chosen
DSA/DH, then your server cannot communicate using RSA-based SSL
ciphers (at least until you configure an additional RSA-based
certificate/key pair). Modern browsers like NS or IE can only
communicate over SSL using RSA ciphers. The result is the
"no shared ciphers" error. To fix this, regenerate your server
certificate/key pair, using the RSA algorithm.

The reason is very technical, and a somewhat "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 go to the correct virtual server
Apache has to know the Host HTTP header field. To do this, the
HTTP request header has to be read. This cannot be done before the SSL
handshake is finished, but the information is needed in order to
complete the SSL handshake phase. See the next question for how to
circumvent this issue.

Note that if you have a wildcard SSL certificate, or a
certificate that has multiple hostnames on it using subjectAltName
fields, you can use SSL on name-based virtual hosts without further
workarounds.

Name-Based Virtual Hosting is a very popular method of identifying
different virtual hosts. It allows you to use the same IP address and
the same port number for many different sites. When people move on to
SSL, it seems natural to assume that the same method can be used to have
lots of different SSL virtual hosts on the same server.

It is possible, but only if using a 2.2.12 or later web server,
built with 0.9.8j or later OpenSSL. This is because it requires a
feature that only the most recent revisions of the SSL
specification added, called Server Name Indication (SNI).

Note that if you have a wildcard SSL certificate, or a
certificate that has multiple hostnames on it using subjectAltName
fields, you can use SSL on name-based virtual hosts without further
workarounds.

The reason is that the SSL protocol is a separate layer which
encapsulates the HTTP protocol. So the SSL session is a separate
transaction, that takes place before the HTTP session has begun.
The server receives an SSL request on IP address X and port Y
(usually 443). Since the SSL request did not contain any Host:
field, the server had no way to decide which SSL virtual host to use.
Usually, it just used the first one it found which matched the
port and IP address specified.

If you are using a version of the web server and OpenSSL that
support SNI, though, and the client's browser also supports SNI,
then the hostname is included in the original SSL request, and the
web server can select the correct SSL virtual host.

You can, of course, use Name-Based Virtual Hosting to identify many
non-SSL virtual hosts (all on port 80, for example) and then
have a single SSL virtual host (on port 443). But if you do this,
you must make sure to put the non-SSL port number on the NameVirtualHost
directive, e.g.

NameVirtualHost 192.168.1.1:80

Other workaround solutions include:

Using separate IP addresses for different SSL hosts.
Using different port numbers for different SSL hosts.

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.

OpenSSL 0.9.8 started to support this by default when compiled with the
zlib 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 preferred 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 %{SSL_COMPRESS_METHOD}x variable.

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.

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:

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
SetEnvIf 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 all your clients, MSIE
or otherwise.

TLS-SRP (Secure Remote Password key exchange for TLS, specified in RFC 5054)
can supplement or replace certificates in authenticating an SSL connection.
To use TLS-SRP, set the
SSLSRPVerifierFile directive to
point to an OpenSSL SRP verifier file. To create the verifier file, use the
openssl tool:

openssl srp -srpvfile passwd.srpv -add username

After creating this file, specify it in the SSL server configuration:

SSLSRPVerifierFile /path/to/passwd.srpv

To force clients to use non-certificate TLS-SRP cipher suites, use the
following directive:

Beginning with version 2.4.7,
mod_ssl will use DH parameters which include primes
with lengths of more than 1024 bits. Java 7 and earlier limit their
support for DH prime sizes to a maximum of 1024 bits, however.

If your Java-based client aborts with exceptions such as
java.lang.RuntimeException: Could not generate DH keypair and
java.security.InvalidAlgorithmParameterException: Prime size must be
multiple of 64, and can only range from 512 to 1024 (inclusive),
and httpd logs tlsv1 alert internal error (SSL alert number 80)
(at LogLevelinfo
or higher), you can either rearrange mod_ssl's cipher list with
SSLCipherSuite
(possibly in conjunction with SSLHonorCipherOrder),
or you can use the SSLCertificateFile
directive to configure custom DH parameters with a 1024-bit prime, which
will always have precedence over any of the built-in DH parameters.

To generate custom DH parameters, use the openssl dhparam
command. Alternatively, you can append the following standard 1024-bit DH
parameters from RFC 2409,
section 6.2 to the respective
SSLCertificateFile file:

The following lists all support possibilities for mod_ssl, in order of
preference. Please go through these possibilities
in this order - don't just pick the one you like the look of.

Send a Problem Report to the Apache httpd Users Support Mailing List
users@httpd.apache.org
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.

Write a Problem Report in the Bug Database
http://httpd.apache.org/bug_report.html
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 carefully.

The Apache version can be determined
by running httpd -v. The OpenSSL version can be
determined by running openssl version. Alternatively, if
you have Lynx installed, you can run the command lynx -mime_header
http://localhost/ | grep Server to gather this information in a
single step.

The details on how you built and installed Apache httpd and OpenSSL

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 configure command line you used.

In case of core dumps please include a Backtrace

If your Apache httpd dumps its core, please attach
a stack-frame ``backtrace'' (see below
for information on how to get this). This information is required
in order to find a reason for your core dump.

A detailed description of your problem

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.

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.

Following are the steps you will need to complete, to get a backtrace:

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 ``OPTIM="-g -ggdb3"'' to get this. On
other platforms at least ``OPTIM="-g"'' is needed.

Start the server and try to reproduce the core-dump. For this you may
want to use a directive like ``CoreDumpDirectory /tmp'' to
make sure that the core-dump file can be written. This should result
in a /tmp/core or /tmp/httpd.core 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 setuid() (unless it does an exec()) for
security reasons (there can be privileged information left over in
memory). If necessary, you can run /path/to/httpd -X
manually to force Apache to not fork.

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

Notice:This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.