Let’s Encrypt with dynamic subdomains

apache-2.4lets-encryptvirtualhostwildcard-subdomain

Setup is like this. I've got a domain e.g. example.com
I've setup Apache2 with a VirtualDocumentRoot, this way I can point a subdomain to a specific folder in an easy way:

File sites-available/websites.conf:

ServerName example.com
ServerAlias *.example.com
VirtualDocumentRoot /var/www/websites/%1/

<Directory /var/www/websites/%1/>
    Options Indexes FollowSymLinks
    AllowOverride All
    Require all granted
</Directory>

So when you visit test.example.com it searches for test folder under websites directory and serves it.

This works as intended, but I wanted to use Let's Encrypt for SSL. Which cannot yet handle wildcard certificates. How would I tackle such a problem?

Current situation:

Installed let's encrypt certs with: sudo certbot --apache -d example.com -d admin.example.com -d www.example.com

File: sites-available/000-default.conf:

DocumentRoot /var/www/websites/current/

<Directory /var/www/websites/current/>
    Options Indexes FollowSymLinks
    AllowOverride All
    Require all granted
</Directory>
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
<IfModule mod_dir.c>
    DirectoryIndex index.php index.pl index.cgi index.html index.xhtml index.htm
</IfModule>

# Let's Encrypt Redirect
RewriteEngine on
RewriteCond %{SERVER_NAME} =example.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

All subdomains still get redirected to https. Only topdomain example.com, admin.example.com and www.example.com should be https.

Best Answer

The issue is that you have not scoped any of the configuration in any site-specific way.

It's important to note that the separate config files "per site" is not really an Apache httpd feature. It's just a (relatively common) convention for administrative convenience which in the end uses an Include directive in the main configuration file to merge everything together into a single configuration when the configuration is loaded.

Normally these separate configuration files have all their contents inside VirtualHost to scope their effects, but you seem to have only global configuration, including your http to https redirects.

Manual plugin

You can either perform a manual verification - with the manual plugin.

certbot -d bristol3.pki.enigmabridge.com --manual --preferred-challenges dns certonly

Certbot will then provide you instructions to manually update a TXT record for the domain in order to proceed with the validation.

Please deploy a DNS TXT record under the name
_acme-challenge.bristol3.pki.enigmabridge.com with the following value:

667drNmQL3vX6bu8YZlgy0wKNBlCny8yrjF1lSaUndc

Once this is deployed,
Press ENTER to continue

Once you have updated the DNS record, press Enter, certbot will continue and if the LetsEncrypt CA verifies the challenge, the certificate is issued as normally.

You may also use a command with more options to minimize interactivity and answering certbot questions. Note that the manual plugin does not yet support non-interactive mode.

certbot --text --agree-tos --email you@example.com -d bristol3.pki.enigmabridge.com --manual --preferred-challenges dns --expand --renew-by-default  --manual-public-ip-logging-ok certonly

Renewal does not work with the manual plugin as it runs in non-interactive mode. More info in the official certbot documentation.

Update: manual hooks

In the new certbot version you can use hooks, e.g., --manual-auth-hook, --manual-cleanup-hook. The hooks are external scripts executed by certbot to perform the task.

Information is passed in environment variables - e.g., domain to validate, challenge token. Vars: CERTBOT_DOMAIN, CERTBOT_VALIDATION, CERTBOT_TOKEN.

certbot certonly --manual --preferred-challenges=dns --manual-auth-hook /path/to/dns/authenticator.sh --manual-cleanup-hook /path/to/dns/cleanup.sh -d secure.example.com

You can write your own handler or use already existing ones. There are many available, e.g., for Cloudflare DNS.

More info on official certbot hooks documentation.

Automation, Renewal, Scripting

~~If you would like to automate DNS challenge validation it is not currently possible with vanilla certbot.~~ Update: some automation is possible with the certbot hooks.

We thus created a simple plugin that supports scripting with DNS automation. It's available as certbot-external-auth.

pip install certbot-external-auth

It supports the DNS, HTTP, TLS-SNI validation methods. You can either use it in handler mode or in JSON output mode.

Handler mode

In handler mode, the certbot + plugin calls external hooks (a program, shell script, Python, ...) to perform the validation and installation. In practice you write a simple handler/shell script which gets the input arguments - domain, token and makes the change in DNS. When the handler finishes, certbot proceeds with validation as usual.

This gives you extra flexibility, renewal is also possible.

Handler mode is also compatible with Dehydrated DNS hooks (former letsencrypt.sh). There are already many DNS hooks for common providers (e.g., CloudFlare, GoDaddy, AWS). In the repository there is a README with extensive examples and example handlers.

Example with Dehydrated DNS hook:

certbot \
    --text --agree-tos --email you@example.com \
    --expand --renew-by-default \
    --configurator certbot-external-auth:out \
    --certbot-external-auth:out-public-ip-logging-ok \
    -d "bristol3.pki.enigmabridge.com" \
    --preferred-challenges dns \
    --certbot-external-auth:out-handler ./dehydrated-example.sh \
    --certbot-external-auth:out-dehydrated-dns \
    run

JSON mode

Another plugin mode is JSON mode. It produces one JSON object per line. This enables a more complicated integration - e.g., when Ansible or some deployment manager is calling certbot. Communication is performed via STDOUT and STDIN. Cerbot produces JSON objects with data to perform the validation, for example:

certbot \
    --text --agree-tos --email you@example.com \
    --expand --renew-by-default \
    --configurator certbot-external-auth:out \
    --certbot-external-auth:out-public-ip-logging-ok \
    -d "bristol3.pki.enigmabridge.com" \
    --preferred-challenges dns \
    certonly 2>/dev/null

{"cmd": "perform_challenge", "type": "dns-01", "domain": "bs3.pki.enigmabridge.com", "token": "3gJ87yANDpmuuKVL2ktfQ0_qURQ3mN0IfqgbTU_AGS4", "validation": "ejEDZXYEeYHUxqBAiX4csh8GKkeVX7utK6BBOBshZ1Y", "txt_domain": "_acme-challenge.bs3.pki.enigmabridge.com", "key_auth": "3gJ87yANDpmuuKVL2ktfQ0_qURQ3mN0IfqgbTU_AGS4.tRQM98JsABZRm5-NiotcgD212RAUPPbyeDP30Ob_7-0"}

Once DNS is updated, the caller sends the new-line character to STDIN of certbot to signal it can continue with validation.

This enables automation and certificate management from the central management server. For installation you can deploy certificates over SSH.

For more info please refer to the readme and examples on certbot-external-auth GitHub.

EDIT: There is also a new blog post describing the DNS validation problem and the plugin usage.

EDIT: We currently work on Ansible 2-step validation, will be soon off.

Let’s Encrypt – Best Practices for Setting a Cron Job for Certbot Renewal

Monthly is not frequent enough.

This script should run at least weekly, and preferably daily. Remember that certs don't get renewed unless they are near to expiration, and monthly could cause your existing certs to occasionally be expired already before they get renewed.

The name of the program is certbot, which was renamed from letsencrypt. If you are still using letsencrypt, you need to update to the current version.

Aside from those issues, it's about the same as my cron jobs.

43 6 * * * certbot renew --post-hook "systemctl reload nginx"

Note: in 18.04 LTS the letsencrypt package has been (finally) renamed to certbot. It now includes a systemd timer which you can enable to schedule certbot renewals, with systemctl enable certbot.timer and systemctl start certbot.timer. However, Ubuntu did not provide a way to specify hooks. You'll need to set up an override for certbot.service to override ExecStart= with your desired command line, until Canonical fixes this.