mirror of
https://github.com/apache/httpd.git
synced 2025-08-13 14:40:20 +00:00
8ffa19a1f7
- Using OCSP stapling information to trigger certificate renewals. Proposed by @frasertweedale. - Added directive `MDCheckInterval` to control how often the server checks for detected revocations. Added proposals for configurations in the README.md chapter "Revocations". - OCSP stapling: accept OCSP responses without a `nextUpdate` entry which is allowed in RFC 6960. Treat those as having an update interval of 12 hours. Added by @frasertweedale. - Adapt OpenSSL usage to changes in their API. By Yann Ylavic. Test Updates - workarounds for using Pebble v2.5 - disable EAB tests for Pebble since v2.5 no longer supports HS256 FWT for EAB keys - some stability improvemnets in error/warning checks git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1916861 13f79535-47bb-0310-9956-ffa450edef68
1541 lines
71 KiB
XML
1541 lines
71 KiB
XML
<?xml version="1.0"?>
|
|
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
|
|
<?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
|
|
<!-- $LastChangedRevision$ -->
|
|
|
|
<!--
|
|
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_md.xml.meta">
|
|
|
|
<name>mod_md</name>
|
|
<description>Managing domains across virtual hosts, certificate provisioning
|
|
via the ACME protocol
|
|
</description>
|
|
<status>Experimental</status>
|
|
<sourcefile>mod_md.c</sourcefile>
|
|
<identifier>md_module</identifier>
|
|
<compatibility>Available in version 2.4.30 and later</compatibility>
|
|
<summary>
|
|
<p>
|
|
This module manages common properties of domains for one or more virtual hosts.
|
|
Its serves two main purposes: for one, supervise/renew TLS certificates via the
|
|
ACME protocol (<a href="https://tools.ietf.org/html/rfc8555">RFC 8555</a>).
|
|
Certificates will be renewed by the module ahead of their expiration to account
|
|
for disruption in internet services. There are ways to monitor the status of all
|
|
certififcates managed this way and configurations that will run your own
|
|
notification commands on renewal, expiration and errors.
|
|
</p><p>
|
|
Second, mod_md offers an alternate OCSP Stapling implementation. This works with
|
|
managed certificates as well as with certificates you configure yourself. OCSP
|
|
Stapling is a necessary component for any https: site, influencing page load
|
|
times and, depending on other setups, page availability. More in the
|
|
stapling section below.
|
|
</p><p>
|
|
The default ACME Authority for managing certificates is
|
|
<a href="https://letsencrypt.org/">Let's Encrypt</a>, but it is possible
|
|
to configure another CA that supports the protocol.
|
|
</p>
|
|
|
|
<p>Simple configuration example:</p>
|
|
|
|
<note><title>TLS in a VirtualHost context</title>
|
|
<highlight language="config">
|
|
MDomain example.org
|
|
|
|
<VirtualHost *:443>
|
|
ServerName example.org
|
|
DocumentRoot htdocs/a
|
|
|
|
SSLEngine on
|
|
# no certificates specification
|
|
</VirtualHost>
|
|
</highlight>
|
|
<p>
|
|
This setup will, on server start, contact
|
|
<a href="https://letsencrypt.org/">Let's Encrypt</a>
|
|
to request a certificate for the domain. If Let's Encrypt can verify the ownership
|
|
of the domain, the module will retrieve the certificate and its chain, store it
|
|
in the local file system (see <directive module="mod_md">MDStoreDir</directive>)
|
|
and provide it, on next restart, to <module>mod_ssl</module>.
|
|
</p><p>
|
|
This happens while the server is already running. All other hosts will continue
|
|
to work as before. While a certificate is not available, requests for the managed
|
|
domain will be answered with a '503 Service Unavailable'.
|
|
</p>
|
|
</note>
|
|
|
|
<note><title>Prerequisites</title>
|
|
<p>
|
|
This module requires <module>mod_watchdog</module> to be loaded as well.
|
|
</p><p>
|
|
Certificate sign-up and renewal with Let's Encrypt requires your server to be
|
|
reachable on port 80 (http:) and/or port 443 (https:) from the public internet.
|
|
(Unless your server is configured to use DNS for challenges - more on that under
|
|
'wildcard certificates')
|
|
</p><p>
|
|
The module will select from the methods offered by Let's Encrypt. Usually LE offers
|
|
challenges on both ports and DNS and Apache chooses a method available.
|
|
</p><p>
|
|
To determine which one is available, the module looks at the ports
|
|
Apache httpd listens on. If those include port 80, it assumes that the
|
|
http: challenge (named http-01) is available. If the server listens
|
|
on port 443, the https: challenge (named tls-alpn-01) is also added to
|
|
the list. (And if <directive module="mod_md">MDChallengeDns01</directive>
|
|
is configured, the challenge dns-01 is added as well.)
|
|
</p><p>
|
|
If your setup is not so straight forward, there are two methods available
|
|
to influence this. First, look at <directive module="mod_md">MDPortMap</directive>
|
|
if the server is behind a portmapper, such as a firewall. Second, you may
|
|
override the module's guesswork completely by configuring
|
|
<directive module="mod_md">MDCAChallenges</directive> directly.
|
|
</p>
|
|
</note>
|
|
|
|
<note><title>https: Challenges</title>
|
|
<p>
|
|
For domain verification via the TLS protocol `tls-alpn-01` is the name
|
|
of the challenge type. It requires the Apache server to listen on port 443
|
|
(see <directive module="mod_md">MDPortMap</directive> if you map that port
|
|
to something else).
|
|
</p><p>
|
|
Let's Encrypt will open a TLS connection to Apache using the special indicator
|
|
`acme-tls/1` (this indication part of TLS is called ALPN, therefore the name
|
|
of the challenge. ALPN is also used by browsers to request a HTTP/2 connection).
|
|
</p><p>
|
|
As with the HTTP/2 protocol, to allow this, you configure:
|
|
</p>
|
|
<highlight language="config">
|
|
Protocols h2 http/1.1 acme-tls/1
|
|
</highlight>
|
|
<p>
|
|
And the `tls-alpn-01` challenge type is available.
|
|
</p>
|
|
</note>
|
|
|
|
<note><title>Wildcard Certificates</title>
|
|
<p>
|
|
Wildcard certificates are possible, but not straight-forward to use out of
|
|
the box. Let's Encrypt requires the `dns-01` challenge verification
|
|
for those. No other is considered good enough.
|
|
</p><p>
|
|
The difficulty here is that Apache cannot do that on its own. As the name implies, `dns-01`
|
|
requires you to show some specific DNS records for your domain that contain
|
|
some challenge data. So you need to _write_ your domain's DNS records.
|
|
</p><p>
|
|
If you know how to do that, you can integrated this with mod_md. Let's
|
|
say you have a script for that in `/usr/bin/acme-setup-dns` you configure
|
|
Apache with:
|
|
</p>
|
|
<highlight language="config">
|
|
MDChallengeDns01 /usr/bin/acme-setup-dns
|
|
</highlight>
|
|
<p>
|
|
and Apache will call this script when it needs to setup/teardown a DNS challenge
|
|
record for a domain.
|
|
</p><p>
|
|
Assuming you want a certificate for `*.mydomain.com`, mod_md will call:
|
|
</p>
|
|
<highlight language="config">
|
|
/usr/bin/acme-setup-dns setup mydomain.com challenge-data
|
|
# this needs to remove all existing DNS TXT records for
|
|
# _acme-challenge.mydomain.com and create a new one with
|
|
# content "challenge-data"
|
|
</highlight>
|
|
<p>
|
|
and afterwards it will call
|
|
</p>
|
|
<highlight language="config">
|
|
/usr/bin/acme-setup-dns teardown mydomain.com
|
|
# this needs to remove all existing DNS TXT records for
|
|
# _acme-challenge.mydomain.com
|
|
</highlight>
|
|
</note>
|
|
|
|
<note><title>Monitoring</title>
|
|
<p>
|
|
Apache has a standard module for monitoring: <module>mod_status</module>.
|
|
mod_md contributes a section and makes monitoring your
|
|
domains easy.
|
|
</p><p>
|
|
You see all your MDs listed alphabetically, the domain names they contain,
|
|
an overall status, expiration times and specific settings. The settings
|
|
show your selection of renewal times (or the default), the CA that is used,
|
|
etc.
|
|
</p><p>
|
|
The 'Renewal' column will show activity and error descriptions for certificate
|
|
renewals. This should make life easier for people to find out if everything
|
|
is all right or what went wrong.
|
|
</p><p>
|
|
If there is an error with an MD it will be shown here as well. This let's
|
|
you assess problems without digging through your server logs.
|
|
</p><p>
|
|
There is also a new 'md-status' handler available to give you the MD information
|
|
from 'server-status' in JSON format. You configure it as
|
|
</p>
|
|
<highlight language="config">
|
|
<Location "/md-status">
|
|
SetHandler md-status
|
|
</Location>
|
|
</highlight>
|
|
<p>
|
|
on your server. As with 'server-status' you will want to add
|
|
authorization for this.
|
|
</p><p>
|
|
If you just want to check the JSON status of a specific domain, simply append
|
|
that to your status url:
|
|
</p>
|
|
<highlight language="config">
|
|
> curl https://<yourhost>/md-status/another-domain.org
|
|
{
|
|
"name": "another-domain.org",
|
|
"domains": [
|
|
"another-domain.org",
|
|
"www.another-domain.org"
|
|
],
|
|
...
|
|
</highlight>
|
|
<p>
|
|
This JSON status also shows a log of activities when domains are renewed:
|
|
</p>
|
|
<highlight language="config">
|
|
{
|
|
"when": "Wed, 19 Jun 2019 14:45:58 GMT",
|
|
"type": "progress", "detail": "The certificate for the managed domain has been renewed successfully and can be used. A graceful server restart now is recommended."
|
|
},{
|
|
"when": "Wed, 19 Jun 2019 14:45:58 GMT",
|
|
"type": "progress", "detail": "Retrieving certificate chain for test-901-003-1560955549.org"
|
|
},{
|
|
"when": "Wed, 19 Jun 2019 14:45:58 GMT",
|
|
"type": "progress", "detail": "Waiting for finalized order to become valid"
|
|
},{
|
|
"when": "Wed, 19 Jun 2019 14:45:50 GMT",
|
|
"type": "progress", "detail": "Submitting CSR to CA for test-901-003-1560955549.org"
|
|
},
|
|
...
|
|
</highlight>
|
|
<p>
|
|
You will also find this information in the file `job.json` in your staging and,
|
|
when activated, domains directory. This allows you to inspect these at
|
|
any later point in time as well.
|
|
</p><p>
|
|
In addition, there is <directive module="mod_md">MDCertificateStatus</directive> which
|
|
gives access to relevant certificate information in JSON format.
|
|
</p>
|
|
</note>
|
|
|
|
<note><title>Stapling</title>
|
|
<p>
|
|
If you want to try the stapling in one Managed Domain alone at first,
|
|
configure:
|
|
</p>
|
|
<highlight language="config">
|
|
<MDomain mydomain.net>
|
|
MDStapling on
|
|
</MDomain>
|
|
</highlight>
|
|
<p>
|
|
and use the 'server-status' and/or <directive module="mod_md">MDMessageCmd</directive> to see how it operates. You will
|
|
see if Stapling information is there, how long it is valid, from where it came and
|
|
when it will be refreshed.
|
|
</p><p>
|
|
If this all works to your satisfaction, you can switch it on for all your
|
|
certificates or just your managed ones.
|
|
</p><p>
|
|
The existing stapling implementation by mod_ssl is used by many sites
|
|
for years. There are two main differences between the mod_ssl and mod_md
|
|
one:
|
|
</p>
|
|
<ol>
|
|
<li>On demand vs. scheduled: mod_ssl retrieves the stapling information
|
|
when it is requested, e.g. on a new connection. mod_md retrieves it
|
|
right at server start and after 2/3rds of its lifetime.</li>
|
|
<li>In memory vs. persisted: mod_ssl <em>can</em> persist this
|
|
information, but most example configurations use a memory cache. mod_md
|
|
always stores in the file system.</li>
|
|
</ol>
|
|
<p>
|
|
If you are unlucky and restart your server during an outage of your CA's
|
|
OCSP service, your users may no longer reach your sites. Without persistence
|
|
your server cannot provide the client with the data and the client browser
|
|
cannot get it as well, since the OCSP service is not responding.
|
|
</p><p>
|
|
The implementation in mod_md will have persisted it, load it again after
|
|
restart and have it available for incoming connections. A day or two before
|
|
this information expires, it will renew it, making it able to cope with
|
|
a long OCSP service downtime.
|
|
</p><p>
|
|
Due to backward compatibility, the existing implementation in mod_ssl could
|
|
not be changed drastically. For example, mod_ssl is unable to add a dependency
|
|
to mod_watchdog without braking many existing installations (that do not load it).
|
|
</p>
|
|
</note>
|
|
|
|
<note><title>tailscale</title>
|
|
<p>
|
|
Since version 2.4.14 of the module, you can use it to get certificates
|
|
for your <a href="https://tailscale.com">tailscale</a> domains.
|
|
</p>
|
|
<highlight language="config">
|
|
<MDomain mydomain.some-thing.ts.net>
|
|
MDCertificateProtocol tailscale
|
|
MDCertificateAuthority file://localhost/var/run/tailscale/tailscaled.sock",
|
|
</MDomain>
|
|
</highlight>
|
|
<p>
|
|
Tailscale provides secure networking between your machines, where ever
|
|
they are, and can provide domain names in the *.ts.net space for them.
|
|
For those, it will then provide Let's Encrypt certificates as well, so
|
|
you can open these domains in your browser securely.
|
|
</p>
|
|
<p>
|
|
The directives listed above tell Apache to contact the local tailscale
|
|
demon for obtaining and renewing certificates. This will only work for
|
|
the domain name that tailscale assigns to your machine.
|
|
</p>
|
|
<p>
|
|
Otherwise, these certificates work exactly like the ones retrieved
|
|
via the ACME protocol from Lets Encrypt. You see them in status reporting
|
|
and MDMessageCmd directives are executed for them as well.
|
|
</p>
|
|
<p>
|
|
More details are <a href="https://github.com/icing/mod_md#tailscale">
|
|
available at the mod_md github documentation</a>.
|
|
</p>
|
|
<p>
|
|
Note that this feature only works on machines where the tailscale
|
|
demon provides a unix domain socket. This, so far, seems only the
|
|
case on *nix systems.
|
|
</p>
|
|
</note>
|
|
|
|
</summary>
|
|
|
|
<directivesynopsis>
|
|
<name>MDomain</name>
|
|
<description>Define list of domain names that belong to one group.</description>
|
|
<syntax>MDomain <var>dns-name</var> [ <var>other-dns-name</var>... ] [auto|manual]</syntax>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
|
|
<usage>
|
|
<p>
|
|
All the names in the list are managed as one Managed Domain (MD).
|
|
mod_md will request one single certificate that is valid for all these names. This
|
|
directive uses the global settings (see other MD directives below). If you
|
|
need specific settings for one MD, use
|
|
the <directive module="mod_md" type="section">MDomainSet</directive>.
|
|
</p><p>
|
|
There are 2 additional settings that are necessary for a Managed Domain:
|
|
a contact Email address (via <directive module="mod_md">MDContactEmail</directive> or <directive module="core">ServerAdmin</directive>)
|
|
and <directive module="mod_md">MDCertificateAgreement</directive>.
|
|
The mail address of <directive module="core">ServerAdmin</directive>
|
|
is used to register at the CA (Let's Encrypt by default).
|
|
The CA may use it to notify you about
|
|
changes in its service or status of your certificates.
|
|
</p><p>
|
|
The second setting, <directive module="mod_md">MDCertificateAgreement</directive>,
|
|
should have the value "accepted". By specifying this, you confirm that your
|
|
accept the Terms of Service of the CA.
|
|
</p>
|
|
<example><title>Example</title>
|
|
<highlight language="config">
|
|
MDContactEmail admin@example.org
|
|
MDCertificateAgreement accepted
|
|
MDomain example.org www.example.org
|
|
|
|
<VirtualHost *:443>
|
|
ServerName example.org
|
|
DocumentRoot htdocs/root
|
|
|
|
SSLEngine on
|
|
</VirtualHost>
|
|
|
|
<VirtualHost *:443>
|
|
ServerName www.example.org
|
|
DocumentRoot htdocs/www
|
|
|
|
SSLEngine on
|
|
</VirtualHost>
|
|
</highlight>
|
|
</example>
|
|
<p>
|
|
There are two special names that you may use in this directive: 'manual'
|
|
and 'auto'. This determines if a Managed Domain shall have exactly the
|
|
name list as is configured ('manual') or offer more convenience. With 'auto'
|
|
all names of a virtual host are added to a MD. Conveniently, 'auto' is also
|
|
the default.
|
|
</p>
|
|
<example><title>Example</title>
|
|
<highlight language="config">
|
|
MDomain example.org
|
|
|
|
<VirtualHost *:443>
|
|
ServerName example.org
|
|
ServerAlias www.example.org
|
|
DocumentRoot htdocs/root
|
|
|
|
SSLEngine on
|
|
</VirtualHost>
|
|
|
|
MDomain example2.org auto
|
|
|
|
<VirtualHost *:443>
|
|
ServerName example2.org
|
|
ServerAlias www.example2.org
|
|
...
|
|
</VirtualHost>
|
|
</highlight>
|
|
</example>
|
|
<p>
|
|
In this example, the domain 'www.example.org' is automatically added to
|
|
the MD 'example.org'. Similarly for 'example2.org' where 'auto' is configured
|
|
explicitly. Whenever you add more ServerAlias names to this
|
|
virtual host, they will be added as well to the Managed Domain.
|
|
</p><p>
|
|
If you prefer to explicitly declare all the domain names, use 'manual' mode.
|
|
An error will be logged if the names do not match with the expected ones.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis type="section" idtype="section">
|
|
<name>MDomainSet</name>
|
|
<description>Container for directives applied to the same managed domains.</description>
|
|
<syntax><MDomainSet <var>dns-name</var> [ <var>other-dns-name</var>... ]>...</MDomainSet></syntax>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
|
|
<usage>
|
|
<p>
|
|
This is the directive <directive module="mod_md">MDomain</directive>
|
|
with the added possibility to add setting just for this MD. In fact,
|
|
you may also use "<MDomain ..>" as a shortcut.
|
|
</p>
|
|
<p>
|
|
This allows you to configure an MD that uses another Certificate Authority,
|
|
have other renewal requirements, etc.
|
|
</p>
|
|
<example><title>Example</title>
|
|
<highlight language="config">
|
|
<MDomain sandbox.example.org>
|
|
MDCertificateAuthority https://someotherca.com/ACME
|
|
</MDomain>
|
|
</highlight>
|
|
</example>
|
|
<p>
|
|
A common use case is to configure https: requirements separately for
|
|
your domains.
|
|
</p>
|
|
<example><title>Example</title>
|
|
<highlight language="config">
|
|
<MDomain example.org>
|
|
MDRequireHttps temporary
|
|
</MDomain>
|
|
</highlight>
|
|
</example>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDCertificateAgreement</name>
|
|
<description>You confirm that you accepted the Terms of Service of the Certificate
|
|
Authority.</description>
|
|
<syntax>MDCertificateAgreement accepted</syntax>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<usage>
|
|
<p>When you use mod_md to obtain a certificate, you become a customer of the CA (e.g. Let's Encrypt). That means you need to read and agree to their Terms of Service,
|
|
so that you understand what they offer and what they might exclude or require from you.
|
|
mod_md cannot, by itself, agree to such a thing.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDCertificateAuthority</name>
|
|
<description>The URL(s) of the ACME Certificate Authority to use.</description>
|
|
<syntax>MDCertificateAuthority <var>url</var></syntax>
|
|
<default>MDCertificateAuthority letsencrypt</default>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<usage>
|
|
<p>
|
|
The URL(s) where the CA offers its service.
|
|
Instead of the actual URL, you may use 'letsencrypt' or 'buypass'.
|
|
</p><p>
|
|
If you configure more than one URL, each one is tried in a round-robin
|
|
fashion after a number of failures. You can configure how quickly or
|
|
delayed that happens via the <directive>MDRetryDelay</directive> and
|
|
<directive>MDRetryFailover</directive> directives. The default setting
|
|
makes a failover after about half a day of trying.
|
|
</p><p>
|
|
All other settings apply to each of these URLs. It is therefore
|
|
not possible to have two with different
|
|
<directive>MDExternalAccountBinding</directive>s, for example.
|
|
</p><p>
|
|
For testing, CAs commonly offer a second service URL.
|
|
The 'test' service does not give certificates valid in a browser,
|
|
but are more relaxed in regard to rate limits.
|
|
This allows for verfication of your own setup before switching
|
|
to the production service URL.
|
|
</p>
|
|
<example><title>LE Test Setup</title>
|
|
<highlight language="config">
|
|
MDCertificateAuthority https://acme-staging-v02.api.letsencrypt.org/directory
|
|
</highlight>
|
|
</example>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDCertificateProtocol</name>
|
|
<description>The protocol to use with the Certificate Authority.</description>
|
|
<syntax>MDCertificateProtocol <var>protocol</var></syntax>
|
|
<default>MDCertificateProtocol ACME</default>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<usage>
|
|
<p>
|
|
Specifies the protocol to use. Currently, only <code>ACME</code> is supported.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDDriveMode</name>
|
|
<description>former name of MDRenewMode.</description>
|
|
<syntax>MDDriveMode always|auto|manual</syntax>
|
|
<default>MDDriveMode auto</default>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<usage>
|
|
<p>This directive exists for backward compatibility as the old name for
|
|
<directive module="mod_md">MDRenewMode</directive>.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDRenewMode</name>
|
|
<description>Controls if certificates shall be renewed.</description>
|
|
<syntax>MDRenewMode always|auto|manual</syntax>
|
|
<default>MDRenewMode auto</default>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<usage>
|
|
<p>
|
|
In the default 'auto' mode, the module will do what makes most sense
|
|
of each Managed Domain. For a domain without any certificates, it will
|
|
obtain them from the Certificate Authority.
|
|
</p>
|
|
<p>
|
|
However, if you have defined an MD that is not used by any of Apache's
|
|
VirtualHosts, it will not bother. And for MDs with static certificate
|
|
files (see <directive module="mod_md">MDCertificateFile</directive>),
|
|
it assumes that you have your own source, and will not renew them either.
|
|
</p>
|
|
<p>
|
|
You can override this default in either way. If you specify 'always',
|
|
the module will renew certificates for an MD, regardless if the
|
|
domains are in use or if there are static files.
|
|
</p>
|
|
<p>
|
|
For the opposite effect, configure 'manual' and no renewal will
|
|
be attempted.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDHttpProxy</name>
|
|
<description>Define a proxy for outgoing connections.</description>
|
|
<syntax>MDHttpProxy <var>url</var></syntax>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<usage>
|
|
<p>Use a http proxy to connect to the <directive module="mod_md">MDCertificateAuthority</directive>. Define this
|
|
if your webserver can only reach the internet with a forward proxy.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDMember</name>
|
|
<description>Additional hostname for the managed domain.</description>
|
|
<syntax>MDMember <var>hostname</var></syntax>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<usage>
|
|
<p>
|
|
Instead of listing all dns names on the same line, you may use
|
|
<directive>MDMember</directive> to add such names
|
|
to a managed domain.
|
|
</p>
|
|
<example><title>Example</title>
|
|
<highlight language="config">
|
|
<MDomain example.org>
|
|
MDMember www.example.org
|
|
MDMember mail.example.org
|
|
</MDomain>
|
|
</highlight>
|
|
</example>
|
|
<p>
|
|
If you use it in the global context, outside a specific MD, you can only
|
|
specify one value, 'auto' or 'manual' as the default for all other MDs. See
|
|
<directive module="mod_md">MDomain</directive> for a
|
|
description of these special values.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDMembers</name>
|
|
<description>Control if the alias domain names are automatically added.</description>
|
|
<syntax>MDMembers auto|manual</syntax>
|
|
<default>MDMembers auto</default>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<usage>
|
|
<p>Defines if the <directive module="core">ServerName</directive> and
|
|
<directive module="core">ServerAlias</directive> values of a VirtualHost
|
|
are automatically added to the members of a Managed Domain or not.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDMustStaple</name>
|
|
<description>Control if new certificates carry the OCSP Must Staple flag.</description>
|
|
<syntax>MDMustStaple on|off</syntax>
|
|
<default>MDMustStaple off</default>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<usage>
|
|
<p>Defines if newly requested certificate should have the OCSP Must Staple flag
|
|
set or not. If a certificate has this flag, the server is required to send a
|
|
OCSP stapling response to every client. This only works if you configure
|
|
<module>mod_ssl</module> to generate this (see <directive module="mod_ssl">SSLUseStapling</directive>
|
|
and friends).
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDNotifyCmd</name>
|
|
<description>Run a program when a Managed Domain is ready.</description>
|
|
<syntax>MDNotifyCmd <var>path</var> [ <var>args</var> ]</syntax>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<usage>
|
|
<p>
|
|
The configured executable is run when a Managed Domain has signed up or
|
|
renewed its certificate. It is given the name of the processed MD as
|
|
additional arguments (after the parameters specified here). It should
|
|
return status code 0 to indicate that it has run successfully.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDPortMap</name>
|
|
<description>Map external to internal ports for domain ownership verification.</description>
|
|
<syntax>MDPortMap <var>map1</var> [ <var>map2</var> ]</syntax>
|
|
<default>MDPortMap http:80 https:443</default>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<usage>
|
|
<p>
|
|
The ACME protocol provides two methods to verify domain ownership via
|
|
HTTP: one that uses 'http:' urls (port 80) and one for 'https:' urls
|
|
(port 443). If your server is not reachable by at least one
|
|
of the two, ACME may only work by configuring your DNS server,
|
|
see <directive module="mod_md">MDChallengeDns01</directive>.
|
|
</p><p>
|
|
On most public facing servers, 'http:' arrives on port 80 and
|
|
'https:' on port 443. The module checks the ports your Apache server
|
|
is listening on and assumes those are available. This means that
|
|
when your server does not listen on port 80, it assumes that
|
|
'http:' requests from the internet will not work.
|
|
</p><p>
|
|
This is a good guess, but it may be wrong. For example, your Apache
|
|
might listen to port 80, but your firewall might block it. 'http:'
|
|
is only available in your intranet. So, the module will falsely assume
|
|
that Let's Encrypt can use 'http:' challenges with your server. This
|
|
will then fail, because your firewall will drop those.
|
|
</p>
|
|
<example><title>Example</title>
|
|
<highlight language="config">
|
|
MDPortMap http:- https:8433
|
|
</highlight>
|
|
</example>
|
|
<p>
|
|
The above example shows how you can specify that 'http:' requests from
|
|
the internet will never arrive. In addition it says that 'https:' requests
|
|
will arrive on local port 8433.
|
|
</p><p>
|
|
This is necessary if you have port forwarding in place, your server may be
|
|
reachable from the Internet on port 443, but the local port that httpd uses is
|
|
another one. Your server might only listen on ports 8443 and 8000, but be reached
|
|
on ports 443 and 80 (from the internet).
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDPrivateKeys</name>
|
|
<description>Set type and size of the private keys generated.</description>
|
|
<syntax>MDPrivateKeys <var>type</var> [ <var>params</var>... ]</syntax>
|
|
<default>MDPrivateKeys RSA 2048</default>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<usage>
|
|
<p>
|
|
Defines what kind of private keys are generated for a managed domain and with
|
|
what parameters. You can have more than one private key type configured and
|
|
the module will obtain a certificate for each key.
|
|
</p><p>
|
|
For example, you may configure an RSA and an Elliptic Curve (EC) key, so
|
|
that 2 certificates are created for a domain. On a client connection, the first
|
|
one supported by the client will then be used.
|
|
</p><p>
|
|
Since EC keys and certificates are smaller, you might want to offer
|
|
them first for all compatible (modern) clients. This can enable
|
|
faster handshakes. Add an RSA key type to support older clients.
|
|
</p>
|
|
<example><title>Example</title>
|
|
<highlight language="config">
|
|
MDPrivateKeys secp256r1 rsa3072
|
|
</highlight>
|
|
</example>
|
|
<p>
|
|
The EC types supported depend on the CA you use. For Let's encrypt
|
|
the supported curves include 'secp256r1' and 'secp384r1'.
|
|
</p><p>
|
|
Each key and certificate type is stored in its own file in the
|
|
MD store. The key type is part of the file name with some backward
|
|
compatible naming for RSA certificates. So you may continue sharing
|
|
these files with other applications.
|
|
</p><p>
|
|
Please note that this setting only has an effect on new keys. Any existing
|
|
private key you have remains unaffected. Also, this only affects private keys
|
|
generated for certificates. ACME account keys are unaffected by this.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDRenewWindow</name>
|
|
<description>Control when a certificate will be renewed.</description>
|
|
<syntax>MDRenewWindow <var>duration</var></syntax>
|
|
<default>MDRenewWindow 33%</default>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<usage>
|
|
<p>
|
|
If the validity of the certificate falls below duration, mod_md
|
|
will get a new signed certificate.
|
|
</p><p>
|
|
Normally, certificates are valid for around 90 days and mod_md will renew
|
|
them the earliest 33% of their complete lifetime before they expire (so for
|
|
90 days validity, 30 days before it expires). If you think this is not what
|
|
you need, you can specify either the exact time, as in:
|
|
</p>
|
|
<example><title>Example</title>
|
|
<highlight language="config">
|
|
# 21 days before expiry
|
|
MDRenewWindow 21d
|
|
# 30 seconds (might be close)
|
|
MDRenewWindow 30s
|
|
# 10% of the cert lifetime
|
|
MDRenewWindow 10%
|
|
</highlight>
|
|
</example>
|
|
<p>When in auto drive mode, the module will check every 12 hours at least
|
|
what the status of the managed domains is and if it needs to do something.
|
|
On errors, for example when the CA is unreachable, it will initially retry
|
|
after some seconds. Should that continue to fail, it will back off to a
|
|
maximum interval of hourly checks.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDRequireHttps</name>
|
|
<description>Redirects http: traffic to https: for Managed Domains.</description>
|
|
<syntax>MDRequireHttps off|temporary|permanent</syntax>
|
|
<default>MDRequireHttps off</default>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<usage>
|
|
<p>This is a convenience directive to ease http: to https: migration of
|
|
your Managed Domains. With:
|
|
</p>
|
|
<example><title>Example</title>
|
|
<highlight language="config">
|
|
MDRequireHttps temporary
|
|
</highlight>
|
|
</example>
|
|
<p>you announce that you want all traffic via http: URLs to be redirected
|
|
to the https: ones, for now. This is safe and you can remove this again at
|
|
any time.
|
|
</p><p>
|
|
<strong>The following has consequences: </strong>if you want client to <strong>no longer</strong> use the
|
|
http: URLs, configure:
|
|
</p>
|
|
<example><title>Permanent (for at least half a year!)</title>
|
|
<highlight language="config">
|
|
MDRequireHttps permanent
|
|
</highlight>
|
|
</example>
|
|
<p>This does two things:
|
|
</p>
|
|
<ol>
|
|
<li>All request to the <code>http:</code> resources are redirected to the
|
|
same url with the <code>https:</code> scheme using the <code>301</code>
|
|
status code. This tells clients that this is intended to be forever and
|
|
the should update any links they have accordingly.
|
|
</li>
|
|
<li>All answers to <code>https:</code> requests will carry the header
|
|
<code>Strict-Transport-Security</code> with a life time of half a year.
|
|
This tells the browser that it <strong>never</strong> (for half a year) shall use <code>http:</code>
|
|
when talking to this domain name. Browsers will, after having seen this, refuse
|
|
to contact your unencrypted site. This prevents malicious middleware to
|
|
downgrade connections and listen/manipulate the traffic. Which is good. But
|
|
you cannot simply take it back again.
|
|
</li>
|
|
</ol>
|
|
<p>You can achieve the same with <module>mod_alias</module> and some
|
|
<directive module="mod_alias">Redirect</directive> configuration,
|
|
basically. If you do it yourself, please make sure to exclude the paths
|
|
/.well-known/* from your redirection, otherwise mod_md
|
|
might have trouble signing on new certificates.
|
|
</p>
|
|
<p>If you set this globally, it applies to all managed domains. If you want
|
|
it for a specific domain only, use:
|
|
</p>
|
|
<example><title>Example</title>
|
|
<highlight language="config">
|
|
<MDomain xxx.yyy>
|
|
MDRequireHttps temporary
|
|
</MDomain>
|
|
</highlight>
|
|
</example>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDStoreDir</name>
|
|
<description>Path on the local file system to store the Managed Domains data.</description>
|
|
<syntax>MDStoreDir <var>path</var></syntax>
|
|
<default>MDStoreDir md</default>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<usage>
|
|
<p>
|
|
Defines where on the local file system the Managed Domain data is stored. This is
|
|
an absolute path or interpreted relative to the server root. The default will create
|
|
a directory 'md' in your server root.
|
|
</p><p>
|
|
If you move this and have already data, be sure to move/copy the data first to
|
|
the new location, reconfigure and then restart the server. If you reconfigure
|
|
and restart first, the server will try to get new certificates that it thinks
|
|
are missing.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDCAChallenges</name>
|
|
<description>Type of ACME challenge used to prove domain ownership.</description>
|
|
<syntax>MDCAChallenges <var>name</var> [ <var>name</var> ... ]</syntax>
|
|
<default>MDCAChallenges tls-alpn-01 http-01 dns-01</default>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<usage>
|
|
<p>
|
|
Sets challenge types (in order of preference) when proving domain ownership.
|
|
Supported by the module are the challenge methods 'tls-alpn-01', 'dns-01'
|
|
and 'http-01'. The module will look at the overall configuration of the server
|
|
to find out which methods can be used.
|
|
</p><p>
|
|
If the server listens on port 80, for example, the 'http-01' method is available.
|
|
The prerequisite for 'dns-01' is a configured <directive module="mod_md">MDChallengeDns01</directive> command.
|
|
'tls-alpn-01' is described above in 'https: Challenges'.
|
|
</p><p>
|
|
This auto selection works for most setups. But since Apache is a very powerful
|
|
server with many configuration options, the situation is not clear for all
|
|
possible cases. For example: it may listen on multiple IP addresses where some
|
|
are reachable on `https:` and some not.
|
|
</p><p>
|
|
If you configure <directive>MDCAChallenges</directive> directly, this auto selection is disabled.
|
|
Instead, the module will use the configured challenge list when talking to
|
|
the ACME server (a challenge type must be offered by the server as well).
|
|
This challenges are examined in the order specified.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDBaseServer</name>
|
|
<description>Control if base server may be managed or only virtual hosts.</description>
|
|
<syntax>MDBaseServer on|off</syntax>
|
|
<default>MDBaseServer off</default>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<usage>
|
|
<p>
|
|
Controls if the base server, the one outside all VirtualHosts should be managed by
|
|
mod_md or not. By default, it will not. For the very reason that
|
|
it may have confusing side-effects. It is recommended that you have virtual hosts
|
|
for all managed domains and do not rely on the global, fallback server configuration.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDCertificateFile</name>
|
|
<description>Specify a static certificate file for the MD.</description>
|
|
<syntax>MDCertificateFile <var>path-to-pem-file</var></syntax>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<usage>
|
|
<p>
|
|
This is used inside a <directive module="mod_md">MDomainSet</directive> and specifies
|
|
the file holding the certificate chain for the Managed Domain. The matching
|
|
key is specified via <directive module="mod_md">MDCertificateKeyFile</directive>.
|
|
</p>
|
|
<example><title>Example</title>
|
|
<highlight language="config">
|
|
<MDomain mydomain.com>
|
|
MDCertificateFile /etc/ssl/my.cert
|
|
MDCertificateKeyFile /etc/ssl/my.key
|
|
</MDomain>
|
|
</highlight>
|
|
</example>
|
|
|
|
<p>
|
|
This is that equivalent of the mod_ssl
|
|
<directive module="mod_ssl">SSLCertificateFile</directive> directive. It
|
|
has several uses.
|
|
</p><p>
|
|
If you want to migrate an existing domain, using static files, to
|
|
automated Let's Encrypt certificates, for one. You define the
|
|
<directive module="mod_md">MDomainSet</directive>, add the files here and remove
|
|
the <directive module="mod_ssl">SSLCertificateFile</directive> from
|
|
your VirtualHosts.
|
|
</p><p>
|
|
This will give you the same as before, with maybe less repeating lines
|
|
in your configuration. Then you can add <directive module="mod_md">MDRenewMode</directive>
|
|
'always' to it and the module will get a new certificate before
|
|
the one from the file expires. When it has done so, you remove the
|
|
<directive>MDCertificateFile</directive> and reload the server.
|
|
</p><p>
|
|
Another use case is that you renew your Let's Encrypt certificates with
|
|
another ACME clients, for example the excellent
|
|
<a href="https://certbot.eff.org">certbot</a>. Then let your MDs point
|
|
to the files from certbot and have both working together.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDCertificateKeyFile</name>
|
|
<description>Specify a static private key for for the static cerrtificate.</description>
|
|
<syntax>MDCertificateKeyFile <var>path-to-file</var></syntax>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<usage>
|
|
<p>
|
|
This is used inside a <directive module="mod_md">MDomainSet</directive> and specifies
|
|
the file holding the private key for the Managed Domain. The matching
|
|
certificate is specified via <directive module="mod_md">MDCertificateFile</directive>.
|
|
</p><p>
|
|
This is that equivalent of the mod_ssl
|
|
<directive module="mod_ssl">SSLCertificateKeyFile</directive> directive.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDCertificateStatus</name>
|
|
<description>Exposes public certificate information in JSON.</description>
|
|
<syntax>MDCertificateStatus on|off</syntax>
|
|
<default>MDCertificateStatus on</default>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<usage>
|
|
<p>
|
|
When enabled, a resources is available in Managed Domains at
|
|
'https://domain/.httpd/certificate-status' that returns a JSON
|
|
document list key properties of the current and of a renewed
|
|
certificate - when available.
|
|
</p>
|
|
<example><title>Example</title>
|
|
<highlight language="config">
|
|
{
|
|
"valid-until": "Thu, 29 Aug 2019 16:06:35 GMT",
|
|
"valid-from": "Fri, 31 May 2019 16:06:35 GMT",
|
|
"serial": "03039C464D454EDE79FCD2CAE859F668F269",
|
|
"sha256-fingerprint": "1ff3bfd2c7c199489ed04df6e29a9b4ea6c015fe8a1b0ce3deb88afc751e352d"
|
|
"renewal" : { ...renewed cert information... }
|
|
}
|
|
</highlight>
|
|
</example>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
|
|
<directivesynopsis>
|
|
<name>MDChallengeDns01</name>
|
|
<description>Set the command for setup/teardown of dns-01 challenges</description>
|
|
<syntax>MDChallengeDns01 <var>path-to-command</var></syntax>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<usage>
|
|
<p>
|
|
Define a program to be called when the `dns-01` challenge needs to be setup/torn down.
|
|
The program is given the argument `setup` or `teardown` followed by the domain name.
|
|
For `setup` the challenge content is additionally given. When
|
|
<directive module="mod_md">MDChallengeDns01Version</directive> is set to 2,
|
|
the `teardown` also gets the challenge content as argument.
|
|
</p><p>
|
|
You do not need to specify this, as long as a 'http:' or 'https:' challenge
|
|
method is possible. However, Let's Encrypt makes 'dns-01' the only
|
|
challenge available for wildcard certificates. If you require
|
|
one of those, you need to configure this.
|
|
</p><p>
|
|
It is now possible to use this directive inside a <directive module="mod_md">MDomain</directive>
|
|
section to specify a specific command for that domain. This allows to configure
|
|
a script specific for the particular DNS provider involved.
|
|
</p><p>
|
|
See the section about wildcard certificates above for more details.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDMessageCmd</name>
|
|
<description>Handle events for Manage Domains</description>
|
|
<syntax>MDMessageCmd <var>path-to-cmd</var> <var>optional-args</var></syntax>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<usage>
|
|
<p>
|
|
This command gets called when one of the following events happen for
|
|
a Managed Domain: "renewed", "installed", "expiring", "errored". The command may
|
|
be invoked for more than these in the future and ignore events
|
|
it is not prepared to handle.
|
|
</p><p>
|
|
This is the more flexible companion to <directive module="mod_md">MDNotifyCmd</directive>.
|
|
</p>
|
|
<example><title>Example</title>
|
|
<highlight language="config">
|
|
MDMessageCmd /etc/apache/md-message
|
|
</highlight>
|
|
|
|
# will be invoked when a new certificate for mydomain.org is available as:
|
|
/etc/apache/md-message renewed mydomain.com
|
|
</example>
|
|
<p>
|
|
The program should not block, as the module will wait for it to finish. A
|
|
return code other than 0 is regarded as an error.
|
|
</p><p>
|
|
'errored' is no immediate cause for concern since renewal is attempted
|
|
early enough to allow the internet to come back. This is reported at most
|
|
once per hour.
|
|
</p><p>
|
|
'expiring' should be taken serious. It is issued when the
|
|
<directive module="mod_md">MDWarnWindow</directive> is reached. By default this is
|
|
10% of the certificate lifetime, so for Let's Encrypt this currently
|
|
means 9 days before it expires. The warning is repeated at most once
|
|
a day.
|
|
</p><p>
|
|
'renewed' means that a new certificate has been obtained and is stored
|
|
in the 'staging' area in the MD store. It will be activated on the next
|
|
server restart/reload.
|
|
</p><p>
|
|
'installed' is triggered when a new certificate has been transferred from
|
|
staging into the domains location in MD store. This happens at server
|
|
startup/reload. Different to all other invocations, <directive>MDMessageCmd</directive> is run
|
|
with root permissions (on *nix systems) and has access to the certificate
|
|
files (and keys). Certificates needed for other applications or
|
|
in different formats can be processed on this event.
|
|
</p><p>
|
|
'renewing' event is triggered before starting renew process for the managed
|
|
domain. Should the command return != 0 for this reason, renew will be
|
|
aborted and repeated on next cycle. Some cluster setups use this to
|
|
allow renewals to run only on a single node.
|
|
</p><p>
|
|
'challenge-setup:type:domain' event is triggered when the challenge data for a domain has
|
|
been created. This is invoked before the ACME server is told to check for it.
|
|
The type is one of the ACME challenge types. This is invoked for every
|
|
DNS name in a MDomain. Cluster setups may use this event to distribute
|
|
challenge files to all nodes in a cluster.
|
|
</p><p>
|
|
ocsp-errored happens when <directive module="mod_md">MDStapling</directive>
|
|
is enabled for a domain, this indicates
|
|
that an error was encountered retrieving the OCSP response from the
|
|
Certificate Authority. mod_md will continue trying.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDWarnWindow</name>
|
|
<description>Define the time window when you want to be warned about an expiring certificate.</description>
|
|
<syntax>MDWarnWindow duration</syntax>
|
|
<default>MDWarnWindow 10%</default>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<usage>
|
|
<p>
|
|
See <directive module="mod_md">MDRenewWindow</directive> for a description on
|
|
how you can specify the time.
|
|
</p><p>
|
|
The modules checks the remaining lifetime of certificates and invokes
|
|
<directive module="mod_md">MDMessageCmd</directive> when there is less than the warn
|
|
window left. With the default, this mean 9 days for certificates from
|
|
Let's Encrypt.
|
|
</p><p>
|
|
It also applies to Managed Domains with static certificate files (
|
|
see <directive module="mod_md">MDCertificateFile</directive>).
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDServerStatus</name>
|
|
<description>Control if Managed Domain information is added to server-status.</description>
|
|
<syntax>MDServerStatus on|off</syntax>
|
|
<default>MDServerStatus on</default>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<usage>
|
|
<p>
|
|
Apaches 'server-status' handler allows you configure a resource to monitor
|
|
what is going on. This includes now a section listing all Managed Domains
|
|
with the DNS names, renewal status, lifetimes and main properties.
|
|
</p><p>
|
|
You can switch that off using this directive.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDCertificateMonitor</name>
|
|
<description>The URL of a certificate log monitor.</description>
|
|
<syntax>MDCertificateMonitor name url</syntax>
|
|
<default>MDCertificateMonitor crt.sh https://crt.sh?q=</default>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<usage>
|
|
<p>
|
|
This is part of the 'server-status' HTML user interface and has nothing to
|
|
do with the core functioning itself. It defines the link offered on that
|
|
page for easy checking of a certificate monitor. The SHA256 fingerprint
|
|
of the certificate is appended to the configured url.
|
|
</p><p>
|
|
Certificate Monitors offer supervision of Certificate Transparency (CT)
|
|
Logs to track the use of certificates for domains. The least you may see
|
|
is that Let's Encrypt (or whichever CA you have configured) has entered
|
|
your certificates into the CTLogs.
|
|
</p><p>
|
|
Caveat: certificate logs update and monitor's intakes of those
|
|
updates suffer some delay. This varies between logs and monitors. A
|
|
brand new certificate will not be known immediately.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDStapling</name>
|
|
<description>Enable stapling for all or a particular MDomain.</description>
|
|
<syntax>MDStapling on|off</syntax>
|
|
<default>MDStapling off</default>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<compatibility>Available in version 2.4.42 and later</compatibility>
|
|
<usage>
|
|
<p>
|
|
<module>mod_md</module> offers an implementation for providing OCSP stapling information.
|
|
This is an alternative to the one provided by <module>mod_ssl</module>. For backward
|
|
compatibility, this is disabled by default.
|
|
</p><p>
|
|
The stapling can be switched on for all certificates on the server or
|
|
for an individual <directive module="mod_md">MDomain</directive>.
|
|
This will replace any stapling configuration
|
|
in <module>mod_ssl</module> for these hosts. When disabled, the <module>mod_ssl</module> stapling
|
|
will do the work (if it is itself enabled, of course). This allows for
|
|
a gradual shift over from one implementation to the other.
|
|
</p><p>
|
|
The stapling of <module>mod_md</module> will also work for domains where the certificates
|
|
are not managed by this module (see <directive module="mod_md">MDStapleOthers</directive> for how to control this).
|
|
This allows use of the new stapling without using any ACME certificate
|
|
management.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDStapleOthers</name>
|
|
<description>Enable stapling for certificates not managed by mod_md.</description>
|
|
<syntax>MDStapleOthers on|off</syntax>
|
|
<default>MDStapleOthers on</default>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<compatibility>Available in version 2.4.42 and later</compatibility>
|
|
<usage>
|
|
<p>
|
|
This setting only takes effect when <directive module="mod_md">MDStapling</directive> is enabled. It controls
|
|
if <module>mod_md</module> should also provide stapling information for certificates
|
|
that are not directly controlled by it, e.g. renewed via an ACME CA.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDStaplingKeepResponse</name>
|
|
<description>Controls when old responses should be removed.</description>
|
|
<syntax>MDStaplingKeepResponse <var>duration</var></syntax>
|
|
<default>MDStaplingKeepResponse 7d</default>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<compatibility>Available in version 2.4.42 and later</compatibility>
|
|
<usage>
|
|
<p>
|
|
This time window specifies when OCSP response data used in stapling
|
|
shall be removed from the store again. Response information older than
|
|
7 days (default) is deleted on server restart/reload. This keeps the store
|
|
from growing when certificates are renewed/reconfigured frequently.
|
|
</p><p>
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDStaplingRenewWindow</name>
|
|
<description>Control when the stapling responses will be renewed.</description>
|
|
<syntax>MDStaplingRenewWindow <var>duration</var></syntax>
|
|
<default>MDStaplingRenewWindow 33%</default>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<compatibility>Available in version 2.4.42 and later</compatibility>
|
|
<usage>
|
|
<p>
|
|
If the validity of the OCSP response used in stapling falls below <var>duration</var>,
|
|
<module>mod_md</module> will obtain a new OCSP response.
|
|
</p><p>
|
|
The CA issuing a certificate commonly also operates the OCSP responder
|
|
service and determines how long its signed response about the validity
|
|
of a certificate are itself valid. The longer a response is valid, the longer
|
|
it can be cached which mean better overall performance for everyone.
|
|
The shorter the life time, the more rapidly certificate revocations
|
|
spread to clients. Also, service reliability is a consideration.
|
|
</p><p>
|
|
By adjusting the stapling renew window you can control parts of this yourself.
|
|
If you make the renew time short (e.g. a short time before the current
|
|
information expires), you gain maximum cache time. But a service outage
|
|
(down for maintenance, for example) will affect you. If you renew a long
|
|
time before expiry, updates will be made more frequent, cause more load
|
|
on the CA server infrastructure and also more coordination between
|
|
the child processes of your server.
|
|
</p><p>
|
|
The default is chosen as 33%, which means renewal is started when only
|
|
a third of the response lifetime is left. For a CA that issues OCSP
|
|
responses with lifetime of 3 days, this means 2 days of caching and 1 day
|
|
for renewal attempts. A service outage would have to last full 24 hours
|
|
to affect your domains.
|
|
</p><p>
|
|
Setting an absolute renew window, like `2d` (2 days), is also possible.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDCertificateCheck</name>
|
|
<description>Set name and URL pattern for a certificate monitoring sitSet name and URL pattern for a certificate monitoring sitee</description>
|
|
<syntax>MDCertificateCheck <var>name</var> <var>url</var></syntax>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<compatibility>Available in version 2.4.42 and later</compatibility>
|
|
<usage>
|
|
<p>
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDActivationDelay</name>
|
|
<description>How long to delay activation of new certificates</description>
|
|
<syntax>MDActivationDelay <var>duration</var></syntax>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<compatibility>Available in version 2.4.42 and later</compatibility>
|
|
<usage>
|
|
<p>
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDContactEmail</name>
|
|
<description>Email address used for account registration</description>
|
|
<syntax>MDContactEmail <var>address</var></syntax>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<compatibility>Available in version 2.4.42 and later</compatibility>
|
|
<usage>
|
|
<p>
|
|
The ACME protocol requires you to give a contact url when you sign up. Currently,
|
|
Let's Encrypt wants an email address (and it will use it to inform you about renewals
|
|
or changed terms of service). <module>mod_md</module> uses the <directive>MDContactEmail</directive> directive email in
|
|
your Apache configuration, so please specify the correct address there.
|
|
If <directive>MDContactEmail</directive> is not present, <module>mod_md</module> will use the
|
|
<directive module="core">ServerAdmin</directive> directive.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDExternalAccountBinding</name>
|
|
<description>Set the external account binding keyid and hmac values to use at CA</description>
|
|
<syntax>MDExternalAccountBinding <var>key-id</var> <var>hmac-64</var> | none | <var>file</var></syntax>
|
|
<default>MDExternalAccountBinding none</default>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<compatibility>Available in version 2.4.52 and later</compatibility>
|
|
<usage>
|
|
<p>
|
|
Configure values for ACME "External Account Binding", a feature
|
|
of the ACME standard that allows clients to bind registrations
|
|
to an existing customer account on ACME servers.
|
|
</p>
|
|
<p>
|
|
Let's Encrypt does not require those, but other ACME CAs do.
|
|
Check with your ACME CA if you need those and how to obtain the
|
|
values. They are two strings, a key identifier and a base64 encoded
|
|
'hmac' value.
|
|
</p>
|
|
<p>
|
|
You can configure those globally or for a specific MDomain. Since
|
|
these values allow anyone to register under the same account, it is
|
|
adivsable to give the configuration file restricted permissions,
|
|
e.g. root only.
|
|
</p>
|
|
<p>
|
|
The value can also be taken from a JSON file, to keep more open
|
|
permissions on the server configuration and restrict the ones on that
|
|
file. The JSON itself is:
|
|
</p>
|
|
<example><title>EAB JSON Example file</title>
|
|
<highlight language="config">
|
|
{"kid": "kid-1", "hmac": "zWND..."}
|
|
</highlight>
|
|
</example>
|
|
<p>
|
|
If you change EAB values, the new ones will be used when the next
|
|
certificate renewal is due.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDRetryDelay</name>
|
|
<description>Time length for first retry, doubled on every consecutive error.</description>
|
|
<syntax>MDRetryDelay <var>duration</var></syntax>
|
|
<default>MDRetryDelay 5s</default>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<compatibility>Available in version 2.4.54 and later</compatibility>
|
|
<usage>
|
|
<p>
|
|
The amount of time to wait after an error before trying
|
|
to renew a certificate again. This duration is doubled after
|
|
each consecutive error with a maximum of 24 hours.
|
|
</p>
|
|
<p>
|
|
It is kept separate for each certificate renewal. Meaning an error
|
|
on one MDomain does not delay the renewals of other domains.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDRetryFailover</name>
|
|
<description>The number of errors before a failover to another CA is triggered</description>
|
|
<syntax>MDRetryFailover <var>number</var></syntax>
|
|
<default>MDRetryFailover 13</default>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<compatibility>Available in version 2.4.54 and later</compatibility>
|
|
<usage>
|
|
<p>
|
|
The number of consecutive errors on renewing a certificate before
|
|
another CA is selected. This only applies to configurations that
|
|
have more than one <directive>MDCertificateAuthority</directive>
|
|
specified.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDStoreLocks</name>
|
|
<description>Configure locking of store for updates</description>
|
|
<syntax>MDStoreLocks on|off|<var>duration</var></syntax>
|
|
<default>MDStoreLocks off</default>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<compatibility>Available in version 2.4.55 and later</compatibility>
|
|
<usage>
|
|
<p>
|
|
Enable this to use a lock file on server startup when
|
|
<directive>MDStoreDir</directive> is synchronized with the server
|
|
configuration and renewed certificates are activated.
|
|
</p><p>
|
|
Locking is intended for setups in a cluster that have a shared
|
|
file system for MDStoreDir. It will protect the activation of
|
|
renewed certificates when cluster nodes are restarted/reloaded
|
|
at the same time. Under the condition that the shared file
|
|
system does support file locking.
|
|
</p><p>
|
|
The default duration to obtain the lock is 5 seconds. If the log
|
|
cannot be obtained, an error is logged and the server startup will
|
|
continue. This may result in a cluster node to still use the
|
|
previous certificate afterwards.
|
|
</p><p>
|
|
A higher timeout will reduce that likelihood, but may delay server
|
|
startups/reloads in case the locks are not properly handled in
|
|
the underlying file system. A lock should only be held by a
|
|
httpd instance for a short duration.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDChallengeDns01Version</name>
|
|
<description>Set the type of arguments to call MDChallengeDns01 with</description>
|
|
<syntax>MDChallengeDns01Version 1|2</syntax>
|
|
<default>MDChallengeDns01Version 1</default>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<compatibility>Available in version 2.4.58 and later</compatibility>
|
|
<usage>
|
|
<p>
|
|
Set the way MDChallengeDns01 command is invoked, e.g the number and
|
|
types of arguments. See <directive module="mod_md">MDChallengeDns01</directive>
|
|
for the differences.
|
|
This setting is global and cannot be varied per domain.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDMatchNames</name>
|
|
<description>Determines how DNS names are matched to vhosts</description>
|
|
<syntax>MDMatchNames all|servernames</syntax>
|
|
<default>MDMatchNames all</default>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<compatibility>Available in version 2.4.58 and later</compatibility>
|
|
<usage>
|
|
<p>
|
|
The mode `all` is the behaviour as in all previous versions. Both ServerName
|
|
and ServerAlias are inspected to find the MDomain matching a VirtualHost.
|
|
This automatically detects coverage, even when you only have added
|
|
one of the names to an MDomain.
|
|
</p><p>
|
|
However, this auto-magic has drawbacks in more complex setups. If you set
|
|
this directive to `servernames`, only the ServerName of a virtual host is
|
|
used for matching. ServerAliases are disregarded then, for matching.
|
|
Aliases will still be added to the certificate obtained, unless you also
|
|
run `MDMembers manual`.
|
|
</p><p>
|
|
Another advantage of `servernames` is that it gives you more flexibility
|
|
with sub-domains and wildcards. You can define one MDomain with a wildcard
|
|
and have other MDomains for specific sub-domain names.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
<directivesynopsis>
|
|
<name>MDCheckInterval</name>
|
|
<description>Determines how often certificates are checked</description>
|
|
<syntax>MDCheckInterval <var>duration</var></syntax>
|
|
<default>MDCheckInterval 12h</default>
|
|
<contextlist>
|
|
<context>server config</context>
|
|
</contextlist>
|
|
<compatibility>Available in version 2.4.60 and later</compatibility>
|
|
<usage>
|
|
<p>
|
|
The time between certificate checks. By default, the validity
|
|
and need for renewals is checked twice a day. This interval is
|
|
not followed precisely. Instead the module randomly applies
|
|
a +/-50% jitter to it. With the default of 12 hours, this
|
|
means the actual time between runs varies between 6 and 18
|
|
hours, jittered anew every run. This helps to mitigate
|
|
traffic peaks at ACME servers.
|
|
</p><p>
|
|
The minimum duration you may configure is 1 second. It is
|
|
not recommended to use such short times in production.
|
|
</p>
|
|
</usage>
|
|
</directivesynopsis>
|
|
|
|
</modulesynopsis>
|