Apache Module mod_md

TLS in a VirtualHost context

MDomain example.org

<VirtualHost *:443>
    ServerName example.org
    DocumentRoot htdocs/a

    SSLEngine on
    # no certificates specification
</VirtualHost>

This setup will, on server start, contact Let's Encrypt 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 MDStoreDir) and provide it, on next restart, to mod_ssl.

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'.

Prerequisites

This module requires mod_watchdog to be loaded as well.

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')

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.

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 MDChallengeDns01 is configured, the challenge dns-01 is added as well.)

If your setup is not so straight forward, there are two methods available to influence this. First, look at MDPortMap if the server is behind a portmapper, such as a firewall. Second, you may override the module's guesswork completely by configuring MDCAChallenges directly.

https: Challenges

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 MDPortMap if you map that port to something else).

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).

As with the HTTP/2 protocol, to allow this, you configure:

Protocols h2 http/1.1 acme-tls/1

And the `tls-alpn-01` challenge type is available.

Wildcard Certificates

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.

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.

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:

MDChallengeDns01 /usr/bin/acme-setup-dns

and Apache will call this script when it needs to setup/teardown a DNS challenge record for a domain.

Assuming you want a certificate for `*.mydomain.com`, mod_md will call:

/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"

and afterwards it will call

/usr/bin/acme-setup-dns teardown mydomain.com
# this needs to remove all existing DNS TXT records for 
# _acme-challenge.mydomain.com

Monitoring

Apache has a standard module for monitoring: mod_status. mod_md contributes a section and makes monitoring your domains easy.

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.

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.

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.

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

<Location "/md-status">
  SetHandler md-status
</Location>

on your server. As with 'server-status' you will want to add authorization for this.

If you just want to check the JSON status of a specific domain, simply append that to your status url:

> curl https://<yourhost>/md-status/another-domain.org
{
  "name": "another-domain.org",
  "domains": [
    "another-domain.org",
    "www.another-domain.org"
  ],
  ...

This JSON status also shows a log of activities when domains are renewed:

{
"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"
},
...

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.

In addition, there is MDCertificateStatus which gives access to relevant certificate information in JSON format.

Stapling

If you want to try the stapling in one Managed Domain alone at first, configure:

<MDomain mydomain.net>
  MDStapling on
</MDomain>

and use the 'server-status' and/or MDMessageCmd 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.

If this all works to your satisfaction, you can switch it on for all your certificates or just your managed ones.

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:

1. 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.
2. In memory vs. persisted: mod_ssl can persist this information, but most example configurations use a memory cache. mod_md always stores in the file system.

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.

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.

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).

tailscale

Since version 2.4.14 of the module, you can use it to get certificates for your tailscale domains.

<MDomain mydomain.some-thing.ts.net>
  MDCertificateProtocol tailscale
  MDCertificateAuthority file://localhost/var/run/tailscale/tailscaled.sock",
</MDomain>

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.

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.

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.

More details are available at the mod_md github documentation.

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.