Setting up SSL connections on Apache 2

Safe Service

New Host

For Apache to respond to HTTPS requests, you need a new virtual host. Listing 1 gives an example. (See also the box labeled "Server Name Identification.") After setting the server name and document root, SSLEngine **On enables encryption. The document root directory is something you should choose carefully: If it is identical to the globally set document root directory, visitors can view the local sites via both secured and an unsecured connections (which is usually the case if you leave out the DocumentRoot directive on the SSL host). One should therefore use different document roots, where possible, or restrict access to the relevant parts of the website using a tool such as the Rewrite module.

Listing 1

Virtual host TLS

01 <VirtualHost *:443>
02    ServerName
03    DocumentRoot "/var/www"
05    SSLEngine on
06    SSLCertificateFile    /etc/apache2/ssl/zertifikat.pem
07    SSLCertificateKeyFile /etc/apache2/ssl/privatekey.pem
09    <Directory "/var/www">
10        Options Indexes FollowSymLinks
11    </Directory>
13    CustomLog /var/log/apache2/ssl_request_log   ssl_combined
14    ErrorLog /var/log/apache2/ssl_error_log
15    TransferLog /var/log/apache2/ssl_access_log
16 </VirtualHost>

Server Name Identification

Since the domain name is an integral part of the certificate, you can actually only use one certificate per IP address. In other words, you would have to assign a separate IP address for every (sub-)domain. A method called Server Name Indication (SNI) removes this need. Before the start of the encryption (in the client hello, see the "Tap-Proof" box), the browser sends the URL it wants to access. All current major browsers support SNI; Apache has supported the method since version 2.2.12 – provided you have OpenSSL version 0.9.8i or newer in use. If this is true of your own Apache installation, you can provide your own certificate in any <VirtualHost> container.

SSLCertificateFile points to the location of the certificate; SSLCertificateKeyFile reveals the file containing the private key. If a certificate is used, in which the private key is embedded, you can leave out SSLCertificateKeyFile. For security reasons, however, you should always outsource the private key to a separate file.

Access attempts via SSL are logged in /var/log/apache2/ssl_request_log. Error messages are sent to the ssl_error_log, and ssl_access_log collects all requests. Access to the pages of the domain is managed, as usual, by a Directory section.

Listing 1 is best stored in a separate configuration file. The directory in which it belongs again depends on the Apache installation. Debian admins put it under /etc/apache2/sites-available and name it after the ServerName. Then you need to enable the file explicitly with a2ensite, replacing with the name of the new configuration file. For openSUSE, the file in Listing 1 needs the extension .conf and resides in /etc/apache2/vhosts.d. CentOS and the Windows binary package for Apache include a sample configuration for a virtual host, which can be easily adjusted to match Listing 1. In CentOS, you can find the sample configuration in /etc/httpd/conf.d/ssl.conf; on Windows it is in httpd-ssl.conf, below the configure\extra folder of the Apache installation.

Passphrase to Start

Finally, you have to restart Apache again; if you are using Debian, use this: /etc/init.d/apache2 restart. Apache prompts you for the passphrase for the private key. You can only prevent this prompt by removing the encryption. If multiple SSL-secured virtual hosts are used, Apache attempts to use the passphrase for all the other private keys. Ideally, you only have to type in a passphrase once.

Now, when a user accesses the encrypted site – in the previous examples – the browser warns them about the self-signed certificate, which might not be secure (Figure 3). Users can decide whether to classify the certificate manually as trusted, then encrypted communications can start.

Figure 3: Self-signed certificates prompt a warning from browsers.

Spoiled for Choice

In addition to the three SSL directives in Listing 1, Apache knows a few more. SSLCipherSuite is particularly interesting. The SSLCipherSuite directive specifies which encryption algorithms the server accepts for the SSL handshake. The directive is followed by a colon-separated list of possible algorithms. You have to specify, in each case, at least one algorithm for the key exchange, authentication, encryption, and integrity checking. An example of such a selection would be:


Each algorithm is abbreviated; RC4 is, for example, the RC4 algorithm. The algorithm abbreviations are given in Table 1. To avoid typing your fingers to the bone, you can rely on abbreviations or aliases. For example, SSLv2 means all algorithms supported by the SSL2 protocol; ALL means all possible algorithms. Other aliases are listed in Table 2. "Exportable" refers to the export restrictions of the United States, which dictate that particularly strong encryption methods cannot be exported. EXP thus contains only methods with low key lengths.

Table 1

Possible Algorithms for SSLCipherSuite

Abbreviation Meaning
Algorithms for key exchange
kDHr Diffie-Hellman with RSA key
kDHd Diffie-Hellman with DSA key
kEDH Ephemeral Diffie-Hellman (temporary key without certificate)
kSRP Key exchange via Secure Remote Password (SRP)
Authentication algorithms
aNULL No authentication
ADH Diffie-Hellman
Encryption algorithms
eNULL No encryption
3DES Triple DES
Algorithms for integrity checking (MAC digest algorithm)
SHA256 SHA256
SHA384 SHA384

Table 2

Aliases for SSLCipherSuite

Abbreviation Meaning
SSLv3 All algorithms supported by SSL 3.0
TLSv1 All algorithms supported by TLS 1.0
EXP All exportable algorithms
EXPORT40 Exportable algorithms with 40 bits
EXPORT56 Exportable algorithms with 56 bits
LOW Weak but not exportable algorithms (single DES)
MEDIUM All algorithms with 128 bits
HIGH All algorithms that use triple DES
RSA All algorithms that use an RSA key exchange
DH All algorithms that use a Diffie-Hellman key exchange
EDH All algorithms that use a key exchange with ephemeral Diffie-Hellman
ECDH Key exchange using Elliptic Curve Diffie-Hellman
ADH All algorithms that use an anonymous Diffie-Hellman key exchange
AECDH All algorithms that use a key exchange with Elliptic Curve Diffie-Hellman
SRP All algorithms that use a key exchange with the Secure Remote Password (SRP)
DSS All algorithms that use a DSS authentication
ECDSA All algorithms that use an ECDSA authentication
NULL All algorithms that do not use authentication

Finally, you can prefer or exclude certain algorithms. This is shown by special characters + , - and !, which are prefixed to the shortcuts. The ! prohibits an algorithm, so the !ADH entry in the preceding example thus excludes all algorithms that use Anonymous Diffie-Hellman. The minus sign - also removes an algorithm, but you can add it to the chain again later. Using the plus sign, you can explicitly set an algorithm at the corresponding position in the list and thus influence the order. In the above example, the web server would prefer the algorithms from the HIGH group before those from the MEDIUM group. Finally, you can also select multiple cipher suites by adding a + between abbreviations. In the above example, RC4+RSA would enable all possible cipher suites that include RC4 and RSA. The example is also the default in Apache 2.2. Apache 2.4, however, accepts the default settings of OpenSSL.

What combinations of algorithms are possible in a setting is revealed by the openssl ciphers-v command. Just add the tail of options to be examined to the command:

openssl ciphers -v 'ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP'

The result is a table like Figure 4. The first column lists the names of the cipher suites; the second column states the SSL standard. Also included are algorithms for the key exchange, authentication, encryption, and integrity checking.

Figure 4: The possible combinations of algorithms, as shown by openssl.

The major browsers normally prefer secure algorithms, currently mainly AES, which are computationally more expensive. Administrators who rely instead on faster, simpler methods live dangerously: RC4 recently hit the headlines. The "TLS" article elsewhere in this issue reveals more problems with TLS. You should not overrule the secure method proposed by the client with your own SSLCipherSuite. You can speed up encoding by deploying OpenSSL crypto hardware. But this assumes that OpenSSL was built with engine support (Figure 5), which is the case from OpenSSL 0.9.7 onward. To discover the available hardware accelerators, type:

Figure 5: On this Core i7 running openSUSE 12.3, there is only one crypto device for hardware accelerated encryption.
openssl engine

Choose one of the accelerators and add the name in the parentheses after the SSLCryptoDevice directive, as in:

SSLCryptoDevice rsax

Additionally, you can set up a cache for the session data:

SSLSessionCache dbm:/tmp/cachefile

In this case, Apache would use the DBM file /tmp/cachefile.

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • What's left of TLS
    Numerous attacks have rocked the security of SSL/TLS encryption in recent years. Newer standards would remedy this, but they are not widely used.
  • Automatic data encryption and decryption with Clevis and Tang
    Encrypting hard disk partitions during the installation of an operating system is standard procedure. When booting the computer, you then need to enter a matching passphrase to unlock the hard drive. We show you how to automate this process and link it to a policy.
  • TLS 1.3 and the return of common sense
    After a decade in service, TLS 1.2 is showing many signs of aging. Its immediate successor, TLS 1.3, has earned the approval of the IETF. Some major changes are on the way.
  • Safe Files

    Encrypting your data is becoming increasingly important, but you don’t always have to use an encrypted filesystem. Sometimes just encrypting files is enough.

  • SHA-3 – The New Hash Standard

    NIST has chosen the Keccak algorithm as the new cryptographic hash standard, but in real life, many users are still waiting to move to its predecessor, SHA-2.

comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs

Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>


		<div class=