Apache Module mod_tls

TLS in a VirtualHost context ¶

Listen 443
TLSEngine 443

<VirtualHost *:443>
  ServerName example.net
  TLSCertificate file_with_certificate.pem file_with_key.pem
  ...
</VirtualHost>

The above is a minimal configuration. Instead of enabling mod_tls in every virtual host, the port for incoming TLS connections is specified.

You cannot mix virtual hosts with mod_ssl and mod_tls on the same port. It's either or. SNI and ALPN are supported. You may use several virtual hosts on the same port and a mix of protocols like http/1.1 and h2.

Feature Comparison with mod_ssl ¶

The table below gives a comparison of feature between mod_ssl and mod_tls. If a feature of mod_ssl is no listed here, it is not supported by mod_tls. The one difference, probably most relevant is the lack for client certificate support in the current version of mod_tls.

TLS Protocols ¶

mod_tls supports TLS protocol version 1.2 and 1.3. Should there ever be a version 1.4 and rustls supports it, it will be available as well.

In mod_tls, you configure the minimum version to use, never the maximum:

TLSProtocol TLSv1.3+

This allows only version 1.3 and whatever may be its successor one day when talking to your server or to a particular virtual host.

TLS Ciphers ¶

The list of TLS ciphers supported in the rustls library, can be found here. All TLS v1.3 ciphers are supported. For TLS v1.2, only ciphers that rustls considers secure are available.

mod_tls supports the following names for TLS ciphers:

1. The IANA assigned name which uses `_` to separate parts. Example: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
2. The OpenSSL name, using `-` as separator (for 1.2). Example: ECDHE-ECDSA-AES256-SHA384. Such names often appear in documentation. `mod_tls` defines them for all TLS v1.2 ciphers. For TLS v1.3 ciphers, names starting with TLS13_ are also supported.
3. The IANA assigned identifier, which is a 16-bit numeric value. Example: 0xc024. You can use this in configurations as TLS_CIPHER_0xc024.

You can configure a preference for ciphers, which means they will be used for clients that support them. If you do not configure a preference, rustls will use the one that it considers best. This is recommended.

Should you nevertheless have the need to prefer one cipher over another, you may configure it like this:

TLSCiphersPrefer ECDHE-ECDSA-AES256-SHA384
# or several
TLSCiphersPrefer ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305

If you name a cipher that is unknown, the configuration will fail. If you name a cipher is not supported by rustls (or no longer supported in an updated version of rustls for security reasons), mod_tls will log a WARNING, but continue to work.

A similar mechanism exists, if you want to disable a particular cipher:

TLSCipherSuppress ECDHE-ECDSA-AES256-SHA384

A suppressed cipher will not longer be used. If you name a cipher that is unknown, the configuration will fail. If you name a cipher is not supported by rustls (or no longer supported in an updated version of rustls for security reasons), mod_tls will log a WARNING, but continue to work.

Virtual Hosts ¶

mod_tls uses the SNI (Server Name Indicator) to select one of the configured virtual hosts that match the port being served. Should the client not provide an SNI, the first configured virtual host will be selected. If the client does provide an SNI (as all today's clients do), it must match one virtual host (ServerName or ServerAlias) or the connection will fail.

As with mod_ssl, you may specify ciphers and protocol versions for the base server (global) and/or individual virtual hosts that are selected via SNI by the client.

Listen 443
TLSEngine 443

<VirtualHost *:443>
  ServerName example1.net
  TLSCertificate example1-cert.pem
  ...
</VirtualHost>

<VirtualHost *:443>
  ServerName example2.net
  TLSCertificate example2-cert.pem
  ...
  TLSProtocol v1.3+
</VirtualHost>

The example above show different TLS settings for virtual hosts on the same port. This is supported. example1 can be contacted via all TLS versions and example2 only allows v1.3 or later.

ACME Certificates ¶

ACME certificates via mod_md are supported, just as for mod_ssl. A minimal configuration:

Listen 443
TLSEngine 443
MDomain example.net

<VirtualHost *:443>
  ServerName example.net
  ...
</VirtualHost>

OCSP Stapling ¶

mod_tls has no own implementation to retrieve OCSP information for a certificate. However, it will use such for Stapling if it is provided by mod_md. See mod_md's documentation on how to enable this.

TLS Variables ¶

Via the directive TLSOptions, several variables are placed into the environment of requests and can be inspected, for example in a CGI script.

The variable names are given by mod_ssl. Note that these are only a subset of the many variables that mod_ssl exposes.

The variable SSL_SESSION_ID is intentionally not supported as it contains sensitive information.

Client Certificates ¶

While rustls supports client certificates in principle, parts of the infrastructure to make use of these in a server are not offered.

Among these features are: revocation lists, inspection of certificate extensions and the matched issuer chain for OCSP validation. Without these, revocation of client certificates is not possible. Offering authentication without revocation is not considered an option.

Work will continue on this and client certificate support may become available in a future release.