The following configuration enables "strong encryption", as defined above, and is derived from the Mozilla Foundation's Server Side TLS requirements:

• SSL 3.0 and TLS 1.0 are susceptible to known attacks on the protocol; they are disabled entirely.
• Disabling TLS 1.1 is (as of August 2016) mostly optional; TLS 1.2 provides stronger encryption options, but 1.1 is not yet known to be broken. Disabling 1.1 may mitigate attacks against some broken TLS implementations.
• Enabling SSLHonorCipherOrder ensures that the server's cipher preferences are followed instead of the client's.
• Disabling SSLCompression prevents TLS compression oracle attacks (e.g. CRIME).
• Disabling SSLSessionTickets ensures Perfect Forward Secrecy is not compromised if the server is not restarted regularly.

The exact ciphersuites supported in the SSLCipherSuite line are determined by your OpenSSL installation, not the server. You may need to upgrade to a modern version of OpenSSL in order to use them.

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:

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.

Refer to the SSLStaplingForceURL directive.

You can confirm that a server certificate points to an OCSP responder using the openssl command-line program, as follows:

$ openssl x509 -in ./www.example.com.crt -text | grep 'OCSP.*http'
OCSP - URI:http://ocsp.example.com

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.

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

Several directives are available to handle timeouts and errors. Refer to the documentation for the SSLStaplingFakeTryLater, SSLStaplingResponderTimeout, and SSLStaplingReturnResponderErrors directives.

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.

Refer to the SSLCertificateChainFile and SSLCertificateFile for instructions for configuring the certificate chain.

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.

To force clients to authenticate using certificates for a particular URL, you can use the per-directory reconfiguration features of mod_ssl:

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:

The password used in this example is the DES encrypted string "password". See the SSLOptions docs for more information.

/C=DE/L=Munich/O=Snake Oil, Ltd./OU=Staff/CN=Foo:xxj31ZMTZzkVA
/C=US/L=S.F./O=Snake Oil, Ltd./OU=CA/CN=Bar:xxj31ZMTZzkVA
/C=US/L=L.A./O=Snake Oil, Ltd./OU=Dev/CN=Quux:xxj31ZMTZzkVA

When your clients are all part of a common hierarchy, which is encoded into the DN, you can match them more easily using SSLRequire, 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.