GCS Amplitude
GCS Amplitude

SSL/TLS Strong Encryption: How-To

be liberal in general SSLCipherSuite ALL:!aNULL:RC4+RSA:+HIGH:+MEDIUM:+LOW:+EXP:+eNULL

but https://hostname/strong/area/ and below

requires strong ciphers SSLCipherSuite HIGH:!aNULL:!MD5

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

Outside the subarea only Intranet access is granted Require ip 192.168.1.0/24

Inside the subarea any Intranet access is allowed

but from the Internet only HTTPS + Strong-Cipher + Password

or the alternative HTTPS + Strong-Cipher + Client-Certificate

If HTTPS is used, make sure a strong cipher is used

Additionally allow client certs as alternative to basic auth. SSLVerifyClient optional SSLVerifyDepth 1 SSLOptions +FakeBasicAuth +StrictRequire SSLRequire %{SSL_CIPHER_USEKEYSIZE}

Force clients from the Internet to use HTTPS RewriteEngine on RewriteCond %{REMOTE_ADDR} !^192\.168\.1\.[0-9]+$ RewriteCond %{HTTPS} !=on RewriteRule . - [F]

Allow Network Access and/or Basic Auth Satisfy any

Network Access Control Require ip 192.168.1.0/24

HTTP Basic Authentication AuthType basic AuthName "Protected Intranet Area" AuthBasicProvider file AuthUserFile conf/protected.passwd Require valid-user

This documented 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.

Your SSL configuration will need to contain, at minimum, the following directives.

LoadModule sslmodule modules/modssl.so Listen 443 ServerName www.example.com SSLEngine on SSLCertificateFile /path/to/www.example.com.cert SSLCertificateKeyFile /path/to/www.example.com.key

While with the following configuration you specify a preference for specific speed-optimized ciphers (which will be selected by mod_ssl, provided that they are supported by the client):

SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:!aNULL:!MD5 SSLHonorCipherOrder on

Obviously, a server-wide

which restricts ciphers to the strong variants, isn't the answer here. However, SSLCipherSuite

can be reconfigured within mod_sslLocation

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:

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

SSLVerifyClient none SSLCACertificateFile conf/ssl.crt/ca.crt SSLVerifyClient require SSLVerifyDepth 1

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

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 modauthbasicall clients allowed, as follows:

SSLVerifyClient none SSLCACertificateFile conf/ssl.crt/ca.crt SSLCACertificatePath conf/ssl.crt SSLVerifyClient require SSLVerifyDepth 5 SSLOptions +FakeBasicAuth SSLRequireSSL AuthName "Snake Oil Authentication" AuthType Basic AuthBasicProvider file AuthUserFile /usr/local/apache2/conf/httpd.passwd Require valid-user

docs for more information.SSLOptions

/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

SSLVerifyClient none SSLCACertificateFile conf/ssl.crt/ca.crt SSLCACertificatePath conf/ssl.crt SSLVerifyClient require SSLVerifyDepth 5 SSLOptions +FakeBasicAuth SSLRequireSSL SSLRequire %{SSLCLIENTSDNO} eq "Snake Oil, Ltd." \ and %{SSLCLIENTSDNOU} in {"Staff", "CA", "Dev"}

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.

SSLCACertificateFile conf/ssl.crt/company-ca.crt # Outside the subarea only Intranet access is granted Require ip 192.168.1.0/24 # Inside the subarea any Intranet access is allowed # but from the Internet only HTTPS + Strong-Cipher + Password # or the alternative HTTPS + Strong-Cipher + Client-Certificate # If HTTPS is used, make sure a strong cipher is used. # Additionally allow client certs as alternative to basic auth. SSLVerifyClient optional SSLVerifyDepth 1 SSLOptions +FakeBasicAuth +StrictRequire SSLRequire %{SSLCIPHERUSEKEYSIZE} >= 128 # Force clients from the Internet to use HTTPS RewriteEngine on RewriteCond %{REMOTE_ADDR} !^192\.168\.1\.[0-9]+$ RewriteCond %{HTTPS} !=on RewriteRule . - [F] # Allow Network Access and/or Basic Auth Satisfy any # Network Access Control Require ip 192.168.1.0/24 # HTTP Basic Authentication AuthType basic AuthName "Protected Intranet Area" AuthBasicProvider file AuthUserFile conf/protected.passwd Require valid-user

Modules | Directives | FAQ | Glossary | Sitemap

Apache HTTP Server Version 2.4

SSL/TLS Strong Encryption: How-To

Available Languages: en | fr

Cipher Suites and Enforcing Strong Security

The following enables only the strongest ciphers:

Client Authentication and Access Control

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.

Logging

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.