1 <?xml version='1.0' encoding='UTF-8' ?>
2 <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
3 <?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
4 <!-- $LastChangedRevision$ -->
7 Licensed to the Apache Software Foundation (ASF) under one or more
8 contributor license agreements. See the NOTICE file distributed with
9 this work for additional information regarding copyright ownership.
10 The ASF licenses this file to You under the Apache License, Version 2.0
11 (the "License"); you may not use this file except in compliance with
12 the License. You may obtain a copy of the License at
14 http://www.apache.org/licenses/LICENSE-2.0
16 Unless required by applicable law or agreed to in writing, software
17 distributed under the License is distributed on an "AS IS" BASIS,
18 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
19 See the License for the specific language governing permissions and
20 limitations under the License.
23 <manualpage metafile="ssl_howto.xml.meta">
24 <parentdocument href="./">SSL/TLS</parentdocument>
26 <title>SSL/TLS Strong Encryption: How-To</title>
30 <p>This document is intended to get you started, and get a few things
31 working. You are strongly encouraged to read the rest of the SSL
32 documentation, and arrive at a deeper understanding of the material,
33 before progressing to the advanced techniques.</p>
36 <section id="configexample">
37 <title>Basic Configuration Example</title>
39 <p>Your SSL configuration will need to contain, at minimum, the
40 following directives.</p>
42 <highlight language="config">
44 <VirtualHost *:443>
45 ServerName www.example.com
47 SSLCertificateFile "/path/to/www.example.com.cert"
48 SSLCertificateKeyFile "/path/to/www.example.com.key"
54 <section id="ciphersuites">
55 <title>Cipher Suites and Enforcing Strong Encryption</title>
58 <p>"Strong encryption" is, and has always been, a moving target. Furthermore,
59 the definition of "strong" depends on your desired use cases, your threat
60 models, and your acceptable levels of risk. The Apache HTTP Server team cannot
61 determine these things for you.</p>
62 <p>For the purposes of this document, which was last updated in mid-2016,
63 "strong encryption" refers to a TLS implementation which provides all of the
64 following, in addition to the basic confidentiality, integrity, and authenticity
65 protection that most users already expect:</p>
67 <li>Perfect Forward Secrecy, which ensures that a compromise to a server's
68 private key in the present does not compromise the confidentiality of past TLS
70 <li>Protection from known attacks on older SSL and TLS implementations, such
71 as <a href="https://en.wikipedia.org/wiki/POODLE">POODLE</a> and
72 <a href="https://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack">BEAST</a>.</li>
73 <li>Support for the strongest ciphers available to modern (and up-to-date) web
74 browsers and other HTTP clients.</li>
75 <li><strong>Rejection</strong> of clients that cannot meet these requirements.
76 In other words, "strong encryption" requires that out-of-date clients be
77 completely unable to connect to the server, to prevent them from endangering
78 their users. Whether or not this is appropriate for your situation is a decision
79 that only you can make.</li>
81 <p>Please note that strong <em>encryption</em> does not, by itself, ensure
82 strong <em>security</em>. (As an example, HTTP compression oracle attacks such
83 as <a href="https://en.wikipedia.org/wiki/BREACH_(security_exploit)">BREACH</a>
84 may require further steps to mitigate.)</p>
88 <li><a href="#onlystrong">How can I create an SSL server which accepts strong encryption only?</a></li>
89 <li><a href="#strongurl">How can I create an SSL server which accepts many types of ciphers in general, but
90 requires a strong cipher for access to a particular URL?</a></li>
93 <section id="onlystrong">
94 <title>How can I create an SSL server which accepts strong encryption
96 <p>The following configuration enables "strong encryption", as defined
97 above, and is derived from the Mozilla Foundation's
98 <a href="https://wiki.mozilla.org/Security/Server_Side_TLS">Server Side
99 TLS</a> requirements:</p>
101 <highlight language="config">
102 # "Modern" configuration, defined by the Mozilla Foundation's SSL Configuration
103 # Generator as of August 2016. This tool is available at
104 # https://mozilla.github.io/server-side-tls/ssl-config-generator/
105 SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
106 # Many ciphers defined here require a modern version (1.0.1+) of OpenSSL. Some
107 # require OpenSSL 1.1.0, which as of this writing was in pre-release.
108 SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
109 SSLHonorCipherOrder on
111 SSLSessionTickets off
115 <li>SSL 3.0 and TLS 1.0 are susceptible to known attacks on the protocol;
116 they are disabled entirely.</li>
117 <li>Disabling TLS 1.1 is (as of August 2016) mostly optional; TLS 1.2
118 provides stronger encryption options, but 1.1 is not yet known to be broken.
119 Disabling 1.1 may mitigate attacks against some broken TLS
120 implementations.</li>
121 <li>Enabling <directive module="mod_ssl">SSLHonorCipherOrder</directive>
122 ensures that the server's cipher preferences are followed instead of the
124 <li>Disabling <directive module="mod_ssl">SSLCompression</directive>
125 prevents TLS compression oracle attacks (e.g.
126 <a href="https://en.wikipedia.org/wiki/CRIME">CRIME</a>).</li>
127 <li>Disabling <directive module="mod_ssl">SSLSessionTickets</directive>
128 ensures Perfect Forward Secrecy is not compromised if the server is not
129 restarted regularly.</li>
132 <p>The exact ciphersuites supported in the
133 <directive module="mod_ssl">SSLCipherSuite</directive> line are determined
134 by your OpenSSL installation, not the server. You may need to upgrade to a
135 modern version of OpenSSL in order to use them.</p>
138 <section id="strongurl">
139 <title>How can I create an SSL server which accepts many types of ciphers
140 in general, but requires a strong cipher for access to a particular URL?</title>
141 <p>Obviously, a server-wide <directive
142 module="mod_ssl">SSLCipherSuite</directive> which restricts
143 ciphers to the strong variants, isn't the answer here. However,
144 <module>mod_ssl</module> can be reconfigured within <code>Location</code>
145 blocks, to give a per-directory solution, and can automatically force
146 a renegotiation of the SSL parameters to meet the new configuration.
147 This can be done as follows:</p>
148 <highlight language="config">
149 # be liberal in general -- use Mozilla's "Intermediate" ciphersuites (weaker
150 # ciphersuites may also be used, but will not be documented here)
151 SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
153 <Location "/strong/area">
154 # but https://hostname/strong/area/ and below requires strong ciphersuites
155 SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
160 <!-- /ciphersuites -->
162 <section id="ocspstapling">
163 <title>OCSP Stapling</title>
165 <p>The Online Certificate Status Protocol (OCSP) is a mechanism for
166 determining whether or not a server certificate has been revoked, and OCSP
167 Stapling is a special form of this in which the server, such as httpd and
168 mod_ssl, maintains current OCSP responses for its certificates and sends
169 them to clients which communicate with the server. Most certificates
170 contain the address of an OCSP responder maintained by the issuing
171 Certificate Authority, and mod_ssl can communicate with that responder to
172 obtain a signed response that can be sent to clients communicating with
175 <p>Because the client can obtain the certificate revocation status from
176 the server, without requiring an extra connection from the client to the
177 Certificate Authority, OCSP Stapling is the preferred way for the
178 revocation status to be obtained. Other benefits of eliminating the
179 communication between clients and the Certificate Authority are that the
180 client browsing history is not exposed to the Certificate Authority and
181 obtaining status is more reliable by not depending on potentially heavily
182 loaded Certificate Authority servers.</p>
184 <p>Because the response obtained by the server can be reused for all clients
185 using the same certificate during the time that the response is valid, the
186 overhead for the server is minimal.</p>
188 <p>Once general SSL support has been configured properly, enabling OCSP
189 Stapling generally requires only very minor modifications to the httpd
190 configuration — the addition of these two directives:</p>
192 <highlight language="config">
194 SSLStaplingCache "shmcb:ssl_stapling(32768)"
197 <p>These directives are placed at global scope (i.e., not within a virtual
198 host definition) wherever other global SSL configuration directives are
199 placed, such as in <code>conf/extra/httpd-ssl.conf</code> for normal
200 open source builds of httpd, <code>/etc/apache2/mods-enabled/ssl.conf</code>
201 for the Ubuntu or Debian-bundled httpd, etc.</p>
203 <p>This particular <directive>SSLStaplingCache</directive> directive requires
204 <module>mod_socache_shmcb</module> (from the <code>shmcb</code> prefix on the
205 directive's argument). This module is usually enabled already for
206 <directive>SSLSessionCache</directive> or on behalf of some module other than
207 <module>mod_ssl</module>. If you enabled an SSL session cache using a
208 mechanism other than <module>mod_socache_shmcb</module>, use that alternative
209 mechanism for <directive>SSLStaplingCache</directive> as well. For example:</p>
211 <highlight language="config">
212 SSLSessionCache "dbm:ssl_scache"
213 SSLStaplingCache "dbm:ssl_stapling"
216 <p>You can use the openssl command-line program to verify that an OCSP response
217 is sent by your server:</p>
220 $ openssl s_client -connect www.example.com:443 -status -servername www.example.com
223 ======================================
225 OCSP Response Status: successful (0x0)
226 Response Type: Basic OCSP Response
232 <p>The following sections highlight the most common situations which require
233 further modification to the configuration. Refer also to the
234 <module>mod_ssl</module> reference manual.</p>
237 <title>If more than a few SSL certificates are used for the server</title>
238 <p>OCSP responses are stored in the SSL stapling cache. While the responses
239 are typically a few hundred to a few thousand bytes in size, mod_ssl
240 supports OCSP responses up to around 10K bytes in size. With more than a
241 few certificates, the stapling cache size (32768 bytes in the example above)
242 may need to be increased. Error message AH01929 will be logged in case of
243 an error storing a response.</p>
247 <title>If the certificate does not point to an OCSP responder, or if a
248 different address must be used</title>
250 <directive module="mod_ssl">SSLStaplingForceURL</directive> directive.</p>
252 <p>You can confirm that a server certificate points to an OCSP responder
253 using the openssl command-line program, as follows:</p>
256 $ openssl x509 -in ./www.example.com.crt -text | grep 'OCSP.*http'
257 OCSP - URI:http://ocsp.example.com
260 <p>If the OCSP URI is provided and the web server can communicate to it
261 directly without using a proxy, no configuration is required. Note that
262 firewall rules that control outbound connections from the web server may
263 need to be adjusted.</p>
265 <p>If no OCSP URI is provided, contact your Certificate Authority to
266 determine if one is available; if so, configure it with
267 <directive module="mod_ssl">SSLStaplingForceURL</directive> in the virtual
268 host that uses the certificate.</p>
272 <title>If multiple SSL-enabled virtual hosts are configured and OCSP
273 Stapling should be disabled for some</title>
275 <p>Add <code>SSLUseStapling Off</code> to the virtual hosts for which OCSP
276 Stapling should be disabled.</p>
280 <title>If the OCSP responder is slow or unreliable</title>
281 <p>Several directives are available to handle timeouts and errors. Refer
282 to the documentation for the
283 <directive module="mod_ssl">SSLStaplingFakeTryLater</directive>,
284 <directive module="mod_ssl">SSLStaplingResponderTimeout</directive>, and
285 <directive module="mod_ssl">SSLStaplingReturnResponderErrors</directive>
290 <title>If mod_ssl logs error AH02217</title>
292 AH02217: ssl_stapling_init_cert: Can't retrieve issuer certificate!
294 <p>In order to support OCSP Stapling when a particular server certificate is
295 used, the certificate chain for that certificate must be configured. If it
296 was not configured as part of enabling SSL, the AH02217 error will be issued
297 when stapling is enabled, and an OCSP response will not be provided for clients
298 using the certificate.</p>
300 <p>Refer to the <directive module="mod_ssl">SSLCertificateChainFile</directive>
301 and <directive module="mod_ssl">SSLCertificateFile</directive> for instructions
302 for configuring the certificate chain.</p>
306 <!-- /ocspstapling -->
308 <section id="accesscontrol">
309 <title>Client Authentication and Access Control</title>
311 <li><a href="#allclients">How can I force clients to authenticate using certificates?</a></li>
312 <li><a href="#arbitraryclients">How can I force clients to authenticate using certificates for a
313 particular URL, but still allow arbitrary clients to access the rest of the server?</a></li>
314 <li><a href="#certauthenticate">How can I allow only clients who have certificates to access a
315 particular URL, but allow all clients to access the rest of the server?</a></li>
316 <li><a href="#intranet">How can I require HTTPS with strong ciphers, and either
317 basic authentication or client certificates, for access to part of the
318 Intranet website, for clients coming from the Internet?</a></li>
321 <section id="allclients">
322 <title>How can I force clients to authenticate using certificates?</title>
324 <p>When you know all of your users (eg, as is often the case on a corporate
325 Intranet), you can require plain certificate authentication. All you
326 need to do is to create client certificates signed by your own CA
327 certificate (<code>ca.crt</code>) and then verify the clients against this
329 <highlight language="config">
330 # require a client certificate which has to be directly
331 # signed by our CA certificate in ca.crt
332 SSLVerifyClient require
334 SSLCACertificateFile "conf/ssl.crt/ca.crt"
338 <section id="arbitraryclients">
339 <title>How can I force clients to authenticate using certificates for a
340 particular URL, but still allow arbitrary clients to access the rest of the server?</title>
342 <p>To force clients to authenticate using certificates for a particular URL,
343 you can use the per-directory reconfiguration features of
344 <module>mod_ssl</module>:</p>
346 <highlight language="config">
348 SSLCACertificateFile "conf/ssl.crt/ca.crt"
350 <Location "/secure/area">
351 SSLVerifyClient require
357 <section id="certauthenticate">
358 <title>How can I allow only clients who have certificates to access a
359 particular URL, but allow all clients to access the rest of the server?</title>
361 <p>The key to doing this is checking that part of the client certificate
362 matches what you expect. Usually this means checking all or part of the
363 Distinguished Name (DN), to see if it contains some known string.
364 There are two ways to do this, using either <module>mod_auth_basic</module> or
365 <directive module="mod_ssl">SSLRequire</directive>.</p>
367 <p>The <module>mod_auth_basic</module> method is generally required when
368 the certificates are completely arbitrary, or when their DNs have
369 no common fields (usually the organisation, etc.). In this case,
370 you should establish a password database containing <em>all</em>
371 clients allowed, as follows:</p>
373 <highlight language="config">
375 SSLCACertificateFile "conf/ssl.crt/ca.crt"
376 SSLCACertificatePath "conf/ssl.crt"
378 <Directory "/usr/local/apache2/htdocs/secure/area">
379 SSLVerifyClient require
381 SSLOptions +FakeBasicAuth
383 AuthName "Snake Oil Authentication"
385 AuthBasicProvider file
386 AuthUserFile "/usr/local/apache2/conf/httpd.passwd"
391 <p>The password used in this example is the DES encrypted string "password".
392 See the <directive module="mod_ssl">SSLOptions</directive> docs for more
395 <example><title>httpd.passwd</title><pre>
396 /C=DE/L=Munich/O=Snake Oil, Ltd./OU=Staff/CN=Foo:xxj31ZMTZzkVA
397 /C=US/L=S.F./O=Snake Oil, Ltd./OU=CA/CN=Bar:xxj31ZMTZzkVA
398 /C=US/L=L.A./O=Snake Oil, Ltd./OU=Dev/CN=Quux:xxj31ZMTZzkVA</pre>
401 <p>When your clients are all part of a common hierarchy, which is encoded
402 into the DN, you can match them more easily using <directive module="mod_ssl"
403 >SSLRequire</directive>, as follows:</p>
406 <highlight language="config">
408 SSLCACertificateFile "conf/ssl.crt/ca.crt"
409 SSLCACertificatePath "conf/ssl.crt"
411 <Directory "/usr/local/apache2/htdocs/secure/area">
412 SSLVerifyClient require
414 SSLOptions +FakeBasicAuth
416 SSLRequire %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
417 and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"}
422 <section id="intranet">
423 <title>How can I require HTTPS with strong ciphers, and either basic
424 authentication or client certificates, for access to part of the
425 Intranet website, for clients coming from the Internet? I still want to allow
426 plain HTTP access for clients on the Intranet.</title>
428 <p>These examples presume that clients on the Intranet have IPs in the range
429 192.168.1.0/24, and that the part of the Intranet website you want to allow
430 internet access to is <code>/usr/local/apache2/htdocs/subarea</code>.
431 This configuration should remain outside of your HTTPS virtual host, so
432 that it applies to both HTTPS and HTTP.</p>
434 <highlight language="config">
435 SSLCACertificateFile "conf/ssl.crt/company-ca.crt"
437 <Directory "/usr/local/apache2/htdocs">
438 # Outside the subarea only Intranet access is granted
439 Require ip 192.168.1.0/24
442 <Directory "/usr/local/apache2/htdocs/subarea">
443 # Inside the subarea any Intranet access is allowed
444 # but from the Internet only HTTPS + Strong-Cipher + Password
445 # or the alternative HTTPS + Strong-Cipher + Client-Certificate
447 # If HTTPS is used, make sure a strong cipher is used.
448 # Additionally allow client certs as alternative to basic auth.
449 SSLVerifyClient optional
451 SSLOptions +FakeBasicAuth +StrictRequire
452 SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128
454 # Force clients from the Internet to use HTTPS
456 RewriteCond "%{REMOTE_ADDR}" "!^192\.168\.1\.[0-9]+$"
457 RewriteCond "%{HTTPS}" "!=on"
458 RewriteRule "." "-" [F]
460 # Allow Network Access and/or Basic Auth
463 # Network Access Control
464 Require ip 192.168.1.0/24
466 # HTTP Basic Authentication
468 AuthName "Protected Intranet Area"
469 AuthBasicProvider file
470 AuthUserFile "conf/protected.passwd"
476 <!-- /access control -->
478 <section id="logging">
479 <title>Logging</title>
481 <p><module>mod_ssl</module> can log extremely verbose debugging information
482 to the error log, when its <directive module="core">LogLevel</directive> is
483 set to the higher trace levels. On the other hand, on a very busy server,
484 level <code>info</code> may already be too much. Remember that you can
485 configure the <directive module="core">LogLevel</directive> per module to
486 suite your needs.</p>