You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by ic...@apache.org on 2021/12/10 12:20:49 UTC
svn commit: r1895755 - /httpd/httpd/trunk/docs/manual/mod/mod_tls.xml
Author: icing
Date: Fri Dec 10 12:20:49 2021
New Revision: 1895755
URL: http://svn.apache.org/viewvc?rev=1895755&view=rev
Log:
*) mod_tls: adding module documentation to our manuals.
[skip ci]
Added:
httpd/httpd/trunk/docs/manual/mod/mod_tls.xml
Added: httpd/httpd/trunk/docs/manual/mod/mod_tls.xml
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_tls.xml?rev=1895755&view=auto
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_tls.xml (added)
+++ httpd/httpd/trunk/docs/manual/mod/mod_tls.xml Fri Dec 10 12:20:49 2021
@@ -0,0 +1,629 @@
+<?xml version="1.0"?>
+<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
+<?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
+<!-- $LastChangedRevision: 1895285 $ -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<modulesynopsis metafile="mod_tls.xml.meta">
+
+ <name>mod_tls</name>
+ <description>TLS v1.2 and v1.3 implemented in memory-safe Rust via
+ the rustls library
+ </description>
+ <status>Experimental</status>
+ <sourcefile>mod_tls.c</sourcefile>
+ <identifier>tls_module</identifier>
+ <compatibility>Available in version 2.4.52 and later</compatibility>
+ <summary>
+ <p>
+ mod_tls is an alternative to <module>mod_ssl</module> for providing https to a server.
+ It's feature set is a subset, described in more detail below. It can
+ be used as a companion to <module>mod_ssl</module>, e.g. both modules can be loaded at
+ the same time.
+ </p><p>
+ mod_tls, being written in C, used the Rust implementation of TLS named
+ <a href="https://github.com/rustls/rustls">rustls</a> via its C interface
+ <a href="https://github.com/rustls/rustls-ffi">rustls-ffi</a>. This gives
+ <em>memory safe</em> cryptography and protocol handling at comparable
+ performance.
+ </p><p>
+ It can be configured for frontend and backend connections. The configuration
+ directive have been kept mostly similar to <module>mod_ssl</module> ones.
+ </p>
+ </summary>
+ <section>
+ <title>TLS in a VirtualHost context</title>
+ <highlight language="config">
+Listen 443
+TLSEngine 443
+
+<VirtualHost *:443>
+ ServerName example.net
+ TLSCertificate file_with_certificate.pem file_with_key.pem
+ ...
+</VirtualHost>
+ </highlight>
+ <p>
+ The above is a minimal configuration. Instead of enabling mod_tls
+ in every virtual host, the port for incoming TLS connections is
+ specified.
+ </p><p>
+ You cannot mix virtual hosts with <module>mod_ssl</module> 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.
+ </p>
+ </section>
+
+ <section><title>Feature Comparison with mod_ssl</title>
+ <p>
+ The table below gives a comparison of feature between
+ <module>mod_ssl</module> and mod_tls. If a feature of <module>mod_ssl</module> 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.
+ </p>
+ <table>
+ <tr><th>Feature</th><th>mod_ssl</th><th>mod_tls</th><th>Comment</th></tr>
+<tr><td>Frontend TLS</td><td>yes</td><td>yes</td><td></td></tr>
+<tr><td>Backend TLS</td><td>yes</td><td>yes</td><td></td></tr>
+<tr><td>TLS v1.3</td><td>yes*</td><td>yes</td><td>*)with recent OpenSSL</td></tr>
+<tr><td>TLS v1.2</td><td>yes</td><td>yes</td><td></td></tr>
+<tr><td>TLS v1.0</td><td>yes*</td><td>no</td><td>*)if enabled in OpenSSL</td></tr>
+<tr><td>SNI Virtual Hosts</td><td>yes</td><td>yes</td><td></td></tr>
+<tr><td>Client Certificates</td><td>yes</td><td>no</td><td></td></tr>
+<tr><td>Machine Certificates for Backend</td><td>yes</td><td>yes</td><td></td></tr>
+<tr><td>OCSP Stapling</td><td>yes</td><td>yes*</td><td>*)via mod_md</td></tr>
+<tr><td>Backend OCSP check</td><td>yes</td><td>no*</td><td>*)stapling will be verified</td></tr>
+<tr><td>TLS version to allow</td><td>min-max</td><td>min</td><td></td></tr>
+<tr><td>TLS ciphers</td><td>exclusive list</td><td>preferred/suppressed</td><td></td></tr>
+<tr><td>TLS cipher ordering</td><td>client/server</td><td>client/server</td><td></td></tr>
+<tr><td>TLS sessions</td><td>yes</td><td>yes</td><td></td></tr>
+<tr><td>SNI strictness</td><td>default no</td><td>default yes</td><td></td></tr>
+<tr><td>Option EnvVars</td><td>exhaustive</td><td>limited*</td><td>*)see var list</td></tr>
+<tr><td>Option ExportCertData</td><td>client+server</td><td>server</td><td></td></tr>
+<tr><td>Backend CA</td><td>file/dir</td><td>file</td><td></td></tr>
+<tr><td>Revocation CRLs</td><td>yes</td><td>no</td><td></td></tr>
+<tr><td>TLS Renegotiation</td><td>yes*</td><td>no</td><td>*)in TLS v1.2</td></tr>
+<tr><td>Encrypted Cert Keys</td><td>yes</td><td>no</td><td></td></tr>
+ </table>
+ <p>
+ </p>
+ </section>
+
+ <section><title>TLS Protocols</title>
+ <p>
+ mod_tls supports TLS protocol version 1.2 and 1.3. Should there ever be
+ a version 1.4 and <code>rustls</code> supports it, it will be available as well.
+ </p>
+ <p>
+ In mod_tls, you configure the <em>minimum</em> version to use, never the maximum:
+ </p>
+ <highlight language="config">
+TLSProtocol TLSv1.3+
+ </highlight>
+ <p>
+ 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.
+ </p>
+ </section>
+
+ <section><title>TLS Ciphers</title>
+ <p>
+ The list of TLS ciphers supported in the <code>rustls</code> library,
+ can be found <a href="https://docs.rs/rustls/">here</a>. All TLS v1.3
+ ciphers are supported. For TLS v1.2, only ciphers that rustls considers
+ secure are available.
+ </p><p>
+ mod_tls supports the following names for TLS ciphers:
+ </p>
+ <ol>
+ <li>
+ The <a href="https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4">IANA assigned name</a>
+ which uses `_` to separate parts. Example: <code>TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384</code>
+ </li>
+ <li>
+ The OpenSSL name, using `-` as separator (for 1.2). Example: <code>ECDHE-ECDSA-AES256-SHA384</code>.
+ Such names often appear in documentation. `mod_tls` defines them for all TLS v1.2 ciphers.
+ For TLS v1.3 ciphers, names starting with <code>TLS13_</code> are also supported.
+ </li>
+ <li>
+ The <a href="https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4">IANA assigned identifier</a>,
+ which is a 16-bit numeric value. Example: <code>0xc024</code>.
+ You can use this in configurations as <code>TLS_CIPHER_0xc024</code>.
+ </li>
+ </ol>
+ <p>
+ 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, <code>rustls</code>
+ will use the one that it considers best. This is recommended.
+ </p>
+ <p>
+ Should you nevertheless have the need to prefer one cipher over another, you
+ may configure it like this:
+ </p>
+ <highlight language="config">
+TLSCiphersPrefer ECDHE-ECDSA-AES256-SHA384
+# or several
+TLSCiphersPrefer ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305
+ </highlight>
+ <p>
+ If you name a cipher that is unknown, the configuration will fail.
+ If you name a cipher is not supported by <code>rustls</code> (or no
+ longer supported in an updated version of <code>rustls</code> for security
+ reasons), mod_tls will log a <code>WARNING</code>, but continue to work.
+ </p>
+ <p>
+ A similar mechanism exists, if you want to disable a particular cipher:
+ </p>
+ <highlight language="config">
+TLSCipherSuppress ECDHE-ECDSA-AES256-SHA384
+ </highlight>
+ <p>
+ 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 <code>rustls</code> (or no
+ longer supported in an updated version of <code>rustls</code> for security
+ reasons), mod_tls will log a <code>WARNING</code>, but continue to work.
+ </p>
+ </section>
+
+ <section><title>Virtual Hosts</title>
+ <p>
+ 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 <em>first</em> configured
+ virtual host will be selected. If the client <em>does</em> provide
+ an SNI (as all today's clients do), it <em>must</em> match one
+ virtual host (<code>ServerName</code> or <code>ServerAlias</code>)
+ or the connection will fail.
+ </p>
+ <p>
+ As with <module>mod_ssl</module>, 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.
+ </p>
+ <highlight language="config">
+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>
+ </highlight>
+ <p>
+ The example above show different TLS settings for virtual hosts on the
+ same port. This is supported. <code>example1</code> can be contacted via
+ all TLS versions and <code>example2</code> only allows v1.3 or later.
+ </p>
+ </section>
+
+ <section><title>ACME Certificates</title>
+ <p>
+ ACME certificates via <module>mod_md</module> are supported, just as
+ for <module>mod_ssl</module>. A minimal configuration:
+ </p>
+ <highlight language="config">
+Listen 443
+TLSEngine 443
+MDomain example.net
+
+<VirtualHost *:443>
+ ServerName example.net
+ ...
+</VirtualHost>
+ </highlight>
+ </section>
+
+ <section><title>OCSP Stapling</title>
+ <p>
+ 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 <module>mod_md</module>. See <module>mod_md</module>'s documentation
+ on how to enable this.
+ </p>
+ </section>
+
+ <section><title>TLS Variables</title>
+ <p>
+ Via the directive <code>TLSOptions</code>, several variables
+ are placed into the environment of requests and can be inspected, for
+ example in a CGI script.
+ </p>
+ <p>
+ The variable names are given by <module>mod_ssl</module>. Note that these
+ are only a subset of the many variables that mod_ssl exposes.
+ </p>
+ <table>
+ <tr><th>Variable</th><th>TLSOption</th><th>Description</th></tr>
+ <tr><td>SSL_TLS_SNI</td><td>*</td><td>the server name indicator (SNI) send by the client</td></tr>
+ <tr><td>SSL_PROTOCOL</td><td>*</td><td>the TLS protocol negotiated</td></tr>
+ <tr><td>SSL_CIPHER</td><td>*</td><td>the name of the TLS cipher negotiated</td></tr>
+ <tr><td>SSL_VERSION_INTERFACE</td><td>StdEnvVars</td><td>the module version</td></tr>
+ <tr><td>SSL_VERSION_LIBRARY</td><td>StdEnvVars</td><td>the rustls-ffi version</td></tr>
+ <tr><td>SSL_SECURE_RENEG</td><td>StdEnvVars</td><td>always `false`</td></tr>
+ <tr><td>SSL_COMPRESS_METHOD</td><td>StdEnvVars</td><td>always `false`</td></tr>
+ <tr><td>SSL_CIPHER_EXPORT</td><td>StdEnvVars</td><td>always `false`</td></tr>
+ <tr><td>SSL_CLIENT_VERIFY</td><td>StdEnvVars</td><td>always `false`</td></tr>
+ <tr><td>SSL_SESSION_RESUMED</td><td>StdEnvVars</td><td>either `Resumed` if a known TLS session id was presented by the client or `Initial` otherwise</td></tr>
+ <tr><td>SSL_SERVER_CERT</td><td>ExportCertData</td><td>the selected server certificate in PEM format</td></tr>
+ </table>
+ <p>
+ The variable <code>SSL_SESSION_ID</code> is intentionally not supported as
+ it contains sensitive information.
+ </p>
+ </section>
+
+ <section><title>Client Certificates</title>
+ <p>
+ While <code>rustls</code> supports client certificates in principle, parts
+ of the infrastructure to make <em>use</em> of these in a server are not
+ offered.
+ </p>
+ <p>
+ 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.
+ </p>
+ <p>
+ Work will continue on this and client certificate support may become
+ available in a future release.
+ </p>
+ </section>
+
+ <directivesynopsis>
+ <name>TLSEngine</name>
+ <description>defines on which address+port the module shall handle incoming connections.</description>
+ <syntax>TLSEngine [address:]port</syntax>
+ <contextlist>
+ <context>server config</context>
+ </contextlist>
+ <usage>
+ <p>
+ This is set on a global level, not in individual `VirtualHost`s.
+ It will affect all `VirtualHost` that match the specified address/port.
+ You can use `TLSEngine` several times to use more than one address/port.
+ </p><p>
+ </p>
+ <example><title>Example</title>
+ <highlight language="config">
+ TLSEngine 443
+ </highlight>
+ </example>
+ <p>
+ The example tells mod_tls to handle incoming connection on port 443 for
+ all listeners.
+ </p>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>TLSCertificate</name>
+ <description>adds a certificate and key (PEM encoded) to a server/virtual host.</description>
+ <syntax>TLSCertificate cert_file [key_file]</syntax>
+ <contextlist>
+ <context>server config</context>
+ <context>virtual host</context>
+ </contextlist>
+ <usage>
+ <p>
+ If you do not specify a separate key file, the key is assumed to also be
+ found in the first file. You may add more than one certificate to a
+ server/virtual host. The first certificate suitable for a client is then chosen.
+ </p><p>
+ The path can be specified relative to the server root.
+ </p>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>TLSProtocol</name>
+ <description>specifies the minimum version of the TLS protocol to use.</description>
+ <syntax>TLSProtocol version+</syntax>
+ <contextlist>
+ <context>server config</context>
+ <context>virtual host</context>
+ </contextlist>
+ <usage>
+ <p>
+ The default is `v1.2+`. Settings this to `v1.3+` would disable TLSv1.2.
+ </p>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>TLSCiphersPrefer</name>
+ <description>defines ciphers that are preferred.</description>
+ <syntax>TLSCiphersPrefer cipher(-list)</syntax>
+ <contextlist>
+ <context>server config</context>
+ <context>virtual host</context>
+ </contextlist>
+ <usage>
+ <p>
+ This will not disable any ciphers supported by `rustls`. If you
+ specify a cipher that is completely unknown, the configuration will
+ fail. If you specify a cipher that is known but not supported by `rustls`,
+ a warning will be logged but the server will continue.
+ </p><p>
+ </p>
+ <example><title>Example</title>
+ <highlight language="config">
+TLSCiphersPrefer ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305
+ </highlight>
+ </example>
+ <p>
+ The example gives 2 ciphers preference over others, in the
+ order they are mentioned.
+ </p>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>TLSCiphersSuppress</name>
+ <description>defines ciphers that are not to be used.</description>
+ <syntax>TLSCiphersSuppress cipher(-list)</syntax>
+ <contextlist>
+ <context>server config</context>
+ <context>virtual host</context>
+ </contextlist>
+ <usage>
+ <p>
+ This will not disable any unmentioned ciphers supported by `rustls`.
+ If you specify a cipher that is completely unknown, the configuration will fail.
+ If you specify a cipher that is known but not supported by `rustls`,
+ a warning will be logged but the server will continue.
+ </p><p>
+ </p>
+ <example><title>Example</title>
+ <highlight language="config">
+TLSCiphersSuppress ECDHE-ECDSA-CHACHA20-POLY1305
+ </highlight>
+ </example>
+ <p>
+ The example removes a cipher for use in connections.
+ </p>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>TLSHonorClientOrder</name>
+ <description></description>
+ <syntax>TLSHonorClientOrder on|off</syntax>
+ <contextlist>
+ <context>server config</context>
+ <context>virtual host</context>
+ </contextlist>
+ <usage>
+ <p>
+ TLSHonorClientOrder determines if the order of ciphers
+ supported by the client is honored. This is `on` by default.
+ </p><p>
+ </p>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>TLSOptions</name>
+ <description>enables SSL variables for requests.</description>
+ <syntax>TLSOptions [+|-]option</syntax>
+ <contextlist>
+ <context>server config</context>
+ <context>virtual host</context>
+ <context>directory</context>
+ <context>.htaccess</context>
+ </contextlist>
+ <usage>
+ <p>
+ TLSOptions is analog to `SSLOptions` in <module>mod_ssl</module>.
+ It can be set per directory/location and `option` can be:
+ </p>
+ <ul>
+ <li>`StdEnvVars`: adds more variables to the requests environment,
+ as forwarded for example to CGI processing and other applications.
+ </li>
+ <li>`ExportCertData`: adds certificate related variables to the request environment.
+ </li>
+ <li>`Defaults`: resets all options to their default values.</li>
+ </ul>
+ <p>
+ Adding variables to a request environment adds overhead, especially
+ when certificates need to be inspected and fields extracted.
+ Therefore most variables are not set by default.
+ </p>
+ <p>
+ You can configure `TLSOptions` per location or generally on a
+ server/virtual host. Prefixing an option with `-` disables this
+ option while leaving others unchanged.
+ A `+` prefix is the same as writing the option without one.
+ </p>
+ <p>
+ The `Defaults` value can be used to reset any options that are
+ inherited from other locations or the virtual host/server.
+ </p>
+ <example><title>Example</title>
+ <highlight language="config">
+<Location /myplace/app>
+ TLSOptions Defaults StdEnvVars
+ ...
+</Location>
+ </highlight>
+ </example>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>TLSProxyEngine</name>
+ <description>enables TLS for backend connections.</description>
+ <syntax>TLSProxyEngine on|off</syntax>
+ <contextlist>
+ <context>server config</context>
+ <context>virtual host</context>
+ <context>proxy section</context>
+ </contextlist>
+ <usage>
+ <p>
+ `TLSProxyEngine on|off` is analog to `SSLProxyEngine` in <module>mod_ssl</module>.
+ </p><p>
+ This can be used in a server/virtual host or `<Proxy>` section to
+ enable the module for outgoing connections using `mod_proxy`.
+ </p>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>TLSProxyCA</name>
+ <description>sets the root certificates to validate the backend server with.</description>
+ <syntax>TLSProxyCA file.pem</syntax>
+ <contextlist>
+ <context>server config</context>
+ <context>virtual host</context>
+ <context>proxy section</context>
+ </contextlist>
+ <usage>
+ <p>
+ `TLSProxyEngine on|off` is analog to `SSLProxyCACertificatePath` in <module>mod_ssl</module>.
+ </p>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>TLSProxyProtocol</name>
+ <description>specifies the minimum version of the TLS protocol to use in proxy connections.</description>
+ <syntax>TLSProxyProtocol version+</syntax>
+ <contextlist>
+ <context>server config</context>
+ <context>virtual host</context>
+ <context>proxy section</context>
+ </contextlist>
+ <usage>
+ <p>
+ The default is `v1.2+`. Settings this to `v1.3+` would disable TLSv1.2.
+ </p>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>TLSProxyCipherPrefer</name>
+ <description>defines ciphers that are preferred for a proxy connection.</description>
+ <syntax>TLSProxyCipherPrefer cipher(-list)</syntax>
+ <contextlist>
+ <context>server config</context>
+ <context>virtual host</context>
+ <context>proxy section</context>
+ </contextlist>
+ <usage>
+ <p>
+ This will not disable any ciphers supported by `rustls`.
+ If you specify a cipher that is completely unknown, the configuration will fail.
+ If you specify a cipher that is known but not supported by `rustls`,
+ a warning will be logged but the server will continue.
+ </p>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>TLSProxyCipherSuppress</name>
+ <description>defines ciphers that are not to be used for a proxy connection.</description>
+ <syntax>TLSProxyCipherSuppress cipher(-list)</syntax>
+ <contextlist>
+ <context>server config</context>
+ <context>virtual host</context>
+ <context>proxy section</context>
+ </contextlist>
+ <usage>
+ <p>
+ This will not disable any unmentioned ciphers supported by `rustls`.
+ If you specify a cipher that is completely unknown, the configuration will fail.
+ If you specify a cipher that is known but not supported by `rustls`,
+ a warning will be logged but the server will continue.
+ </p>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>TLSProxyMachineCertificate</name>
+ <description>adds a certificate and key file (PEM encoded) to a proxy setup.</description>
+ <syntax>TLSProxyMachineCertificate cert_file [key_file]</syntax>
+ <contextlist>
+ <context>server config</context>
+ <context>virtual host</context>
+ <context>proxy section</context>
+ </contextlist>
+ <usage>
+ <p>
+ The certificate is used to authenticate against a proxied backend server.
+ </p><p>
+ If you do not specify a separate key file, the key is assumed to also be
+ found in the first file. You may add more than one certificate to a proxy
+ setup. The first certificate suitable for a proxy connection to a backend
+ is then chosen by <code>rustls</code>.
+ </p>
+ <p>
+ The path can be specified relative to the server root.
+ </p>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>TLSStrictSNI</name>
+ <description>enforces exact matches of client server indicators (SNI) against host names.</description>
+ <syntax>TLSStrictSNI on|off</syntax>
+ <contextlist>
+ <context>server config</context>
+ </contextlist>
+ <usage>
+ <p>
+ Client connections using SNI will be unsuccessful if no match is found. This is `on` by default.
+ </p>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>TLSSessionCache</name>
+ <description>specifies the cache for TLS session resumption.</description>
+ <syntax>TLSSessionCache cache-spec</syntax>
+ <contextlist>
+ <context>server config</context>
+ </contextlist>
+ <usage>
+ <p>
+ This uses a cache on the server side to allow clients to resume connections.
+ </p><p>
+ You can set this to `none` or define a cache as in the `SSLSessionCache`
+ directive of <module>mod_ssl</module>.
+ </p><p>
+ If not configured, `mod_tls` will try to create a shared memory cache on its own,
+ using `shmcb:tls/session-cache` as specification.
+ Should that fail, a warning is logged, but the server continues.
+ </p>
+ </usage>
+ </directivesynopsis>
+
+</modulesynopsis>