SSL/TLS Strong Encryption: How-To

This document is intended to get you started, and get a few things
working. You are strongly encouraged to read the rest of the SSL
documentation, and arrive at a deeper understanding of the material,
before progressing to the advanced techniques.

Obviously, a server-wide SSLCipherSuite which restricts
ciphers to the strong variants, isn't the answer here. However,
mod_ssl can be reconfigured within Location
blocks, to give a per-directory solution, and can automatically force
a renegotiation of the SSL parameters to meet the new configuration.
This can be done as follows:

The Online Certificate Status Protocol (OCSP) is a mechanism for
determining whether or not a server certificate has been revoked, and OCSP
Stapling is a special form of this in which the server, such as httpd and
mod_ssl, maintains current OCSP responses for its certificates and sends
them to clients which communicate with the server. Most certificates
contain the address of an OCSP responder maintained by the issuing
Certificate Authority, and mod_ssl can communicate with that responder to
obtain a signed response that can be sent to clients communicating with
the server.

Because the client can obtain the certificate revocation status from
the server, without requiring an extra connection from the client to the
Certificate Authority, OCSP Stapling is the preferred way for the
revocation status to be obtained. Other benefits of eliminating the
communication between clients and the Certificate Authority are that the
client browsing history is not exposed to the Certificate Authority and
obtaining status is more reliable by not depending on potentially heavily
loaded Certificate Authority servers.

Because the response obtained by the server can be reused for all clients
using the same certificate during the time that the response is valid, the
overhead for the server is minimal.

Once general SSL support has been configured properly, enabling OCSP
Stapling generally requires only very minor modifications to the httpd
configuration — the addition of these two directives:

SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"

These directives are placed at global scope (i.e., not within a virtual
host definition) wherever other global SSL configuration directives are
placed, such as in conf/extra/httpd-ssl.conf for normal
open source builds of httpd, /etc/apache2/mods-enabled/ssl.conf
for the Ubuntu or Debian-bundled httpd, etc.

The path on the SSLStaplingCache directive
(e.g., logs/) should match the one on the
SSLSessionCache directive. This path is relative
to ServerRoot.

This particular SSLStaplingCache directive requires
mod_socache_shmcb (from the shmcb prefix on the
directive's argument). This module is usually enabled already for
SSLSessionCache or on behalf of some module other than
mod_ssl. If you enabled an SSL session cache using a
mechanism other than mod_socache_shmcb, use that alternative
mechanism for SSLStaplingCache as well. For example:

The following sections highlight the most common situations which require
further modification to the configuration. Refer also to the
mod_ssl reference manual.

If more than a few SSL certificates are used for the server

OCSP responses are stored in the SSL stapling cache. While the responses
are typically a few hundred to a few thousand bytes in size, mod_ssl
supports OCSP responses up to around 10K bytes in size. With more than a
few certificates, the stapling cache size (32768 bytes in the example above)
may need to be increased. Error message AH01929 will be logged in case of
an error storing a response.

If the certificate does not point to an OCSP responder, or if a
different address must be used

If the OCSP URI is provided and the web server can communicate to it
directly without using a proxy, no configuration is required. Note that
firewall rules that control outbound connections from the web server may
need to be adjusted.

If no OCSP URI is provided, contact your Certificate Authority to
determine if one is available; if so, configure it with
SSLStaplingForceURL in the virtual
host that uses the certificate.

If multiple SSL-enabled virtual hosts are configured and OCSP
Stapling should be disabled for some

Add SSLUseStapling Off to the virtual hosts for which OCSP
Stapling should be disabled.

If mod_ssl logs error AH02217

AH02217: ssl_stapling_init_cert: Can't retrieve issuer certificate!

In order to support OCSP Stapling when a particular server certificate is
used, the certificate chain for that certificate must be configured. If it
was not configured as part of enabling SSL, the AH02217 error will be issued
when stapling is enabled, and an OCSP response will not be provided for clients
using the certificate.

When you know all of your users (eg, as is often the case on a corporate
Intranet), you can require plain certificate authentication. All you
need to do is to create client certificates signed by your own CA
certificate (ca.crt) and then verify the clients against this
certificate.

# require a client certificate which has to be directly
# signed by our CA certificate in ca.crt
SSLVerifyClient require
SSLVerifyDepth 1
SSLCACertificateFile "conf/ssl.crt/ca.crt"

The key to doing this is checking that part of the client certificate
matches what you expect. Usually this means checking all or part of the
Distinguished Name (DN), to see if it contains some known string.
There are two ways to do this, using either mod_auth_basic or
SSLRequire.

The mod_auth_basic method is generally required when
the certificates are completely arbitrary, or when their DNs have
no common fields (usually the organisation, etc.). In this case,
you should establish a password database containing all
clients allowed, as follows:

These examples presume that clients on the Intranet have IPs in the range
192.168.1.0/24, and that the part of the Intranet website you want to allow
internet access to is /usr/local/apache2/htdocs/subarea.
This configuration should remain outside of your HTTPS virtual host, so
that it applies to both HTTPS and HTTP.

mod_ssl can log extremely verbose debugging information
to the error log, when its LogLevel is
set to the higher trace levels. On the other hand, on a very busy server,
level info may already be too much. Remember that you can
configure the LogLevel per module to
suite your needs.

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.