| <?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> |