Wildcard Certificates with Let's Encrypt

Wildcard certificates secure several domains or subdomains at the same time. They can only be issued using the "DNS Challenge", which means that no automatic renewal is actually possible. This seems to make the use for websites that are constantly accessible on the Internet meaningless. It is also not what Let's Encrypt recommends for these websites (see ACME v2 and Wildcard Certificate Support is Live).

For local domains, on the other hand, whose certificates can only be issued and renewed using the "DNS Challenge" anyway, wildcard certificates offer considerable relief, since only one certificate has to be issued and renewed.

It makes sense to use a subdomain of an existing real domain for your local domains. In the example used here it is me.uwe-gehring.de, i.e. all domain names within the subdomain me.uwe-gehring.de are secured by means of a wildcard certificate, e.g. server1.me.uwe-gehring.de, laptop2.me.uwe-gehring.de etc.

The subdomain me.uwe-gehring.de and all subdomains beneath are not used for domains on the Internet, but only for computers, virtual hosts, etc. in the home network.

Issuing the certificate

The following command requests the issuance of the certificate:

$ certbot certonly --agree-tos --manual --preferred-challenges dns \
 --manual-public-ip-logging-ok -d *.me.uwe-gehring.de -m <EMail-Address>

Instead of the certbot command, certbot-auto might be installed on your computer. Both commands must be issued as root or using sudo.

Then the following message appears:

-----------------------------------------------------------------------------
Please deploy a DNS TXT record under the name
_acme-challenge.me.uwe-gehring.de with the following value:
 
mDTONIbjRTTtpBSyLpgdseQ5Lles3Op77vc31UD__GI
 
Before continuing, verify the record is deployed.
-----------------------------------------------------------------------------
Press Enter to Continue

The first thing to do here is to create the subdomain _acme-challenge.me.uwe-gehring.de with the DNS provider of your choice and to only maintain a TXT with the displayed value.

After saving, wait at least 5 minutes or the time of the configured TTL and start a DNS query from another computer or another terminal to check whether the entry can already be called up. That works e.g. with dig -t ANY _acme-challenge.me.uwe-gehring.de. The result looks like this if the entry is available:

; <<>> DiG 9.10.3-P4-Debian <<>> -t ANY _acme-challenge.me.uwe-gehring.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65445
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_acme-challenge.me.uwe-gehring.de. IN	ANY

;; ANSWER SECTION:
_acme-challenge.me.uwe-gehring.de. 300 IN TXT	"mDTONIbjRTTtpBSyLpgdseQ5Lles3Op77vc31UD__GI"

;; Query time: 6 msec
;; SERVER: 172.26.0.2#53(172.26.0.2)
;; WHEN: Thu Sep 10 10:49:09 CEST 2020
;; MSG SIZE  rcvd: 118

The important thing is the ANSWER SECTION and that the correct TXT entry is displayed there. As soon as this is the case, the certbot or certbot-auto command can be continued in the other terminal by pressing the Enter key. Then you should get a success message from certbot that the certificate has been issued.

Renewal of the certificate

The renewal of the certificate is done in exactly the same way as the initial issue, i.e. you use the same command as above and change the TXT record in the DNS to the newly generated value.

Automation

Automating the issuance and in particular the renewal of the certificate is possible only when the DNS provider offers an API via which the TXT entry can be maintained. In this case you can start a program via so-called pre- and post-validation hooks from certbot, which creates or changes the TXT entry via the API (see Pre and Post Validation Hooks in the certbot User Guide).