[tech] Wildcard SSL/TLS certificates on core servers

David Adam zanchey at ucc.gu.uwa.edu.au
Mon May 13 21:07:54 AWST 2019


Hi all,

We've been using Let's Encrypt to get free SSL certificates since it 
launched, including for all member domains [1]. We settled on acmetool as 
the most sensible client at the time.

Two things have changed:
 - the ACMEv1 protocol is being deprecated, and acmetool does not yet 
   support ACMEv2 and appears to no longer be actively maintained [2]
 - wildcard certificates are available through Let's Encrypt, requiring 
   DNS-01 challenges and a client that support ACMEv2.

I've gotten wildcard certificates working for *.ucc.{gu.uwa.edu,asn}.au by 
doing the following:

New DNS zones: ucc.machines now has entries for 
_acme-challenge.ucc.{gu.uwa.edu,asn}.au, both of which have an NS record 
pointing to mooneye. Mooneye has a simple zonefile (just an SOA and an NS 
record) for each of these domains configured in /etc/bind/named.conf.local

Dynamic updates: Both zones are configured following the Certbot/Let's
Encrypt examples [3] to use a new TSIG key (called letsencrypt-key) to
allow RFC 2136 updates to TXT records only, with a stanza similar to
this:

  update-policy {
    grant letsencrypt-key name _acme-challenge.ucc.gu.uwa.edu.au. TXT;
  };

I tested this manually using nsupdate:

  # nsupdate -k letsencrypt.key
  > add _acme-challenge.ucc.gu.uwa.edu.au. 600 TXT "Hello this is a test entry"
  > send
  # host -t TXT _acme-challenge.ucc.gu.uwa.edu.au
  _acme-challenge.ucc.gu.uwa.edu.au descriptive text "Hello this is a test entry"

New client: After reviewing the various options for ACMEv2 compatible
clients, I decided to go with the official Certbot client [4]. It has
matured enormously in the last three years and importantly is included
in Debian by default. Renewals are set up by the Debian package and
require no further configuration.

I installed it with:
  # apt-get install certbot python3-certbot-dns-rfc2136
  # certbot register --agree-tos -m wheel at ucc.gu.uwa.edu.au

Then created /etc/letsencrypt/dns-rfc2136-credentials.ini with the
credentials for the TSIG key.

Getting a wildcard certificate for all domains was now easy:
  # certbot certonly --dns-rfc2136 --dns-rfc2136-credentials \
    /etc/letsencrypt/dns-rfc2136-credentials.ini \
    --dns-rfc2136-propagation-seconds 5 -d \*.ucc.gu.uwa.edu.au \
    -d \*.ucc.asn.au
  # certbot certificates
  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  Found the following certs:
    Certificate Name: ucc.gu.uwa.edu.au
      Domains: *.ucc.gu.uwa.edu.au *.ucc.asn.au
      Expiry Date: 2019-08-10 13:10:47+00:00 (VALID: 89 days)
      Certificate Path: /etc/letsencrypt/live/ucc.gu.uwa.edu.au/fullchain.pem
      Private Key Path: /etc/letsencrypt/live/ucc.gu.uwa.edu.au/privkey.pem
  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

I'll start adding these certificates to the various SSL services on Motsugo,
Mussel, and Mooneye. The only service which definitely can't use a wildcard is
the IPsec VPN [5], so the magic secure.ucc certificate mechanisms probably need
to remain in place for now (but I'll look at adding that to the DNS 
configurator as well).B

David Adam
UCC Wheel Member
zanchey at ucc.gu.uwa.edu.au

[1]: 
https://lists.ucc.gu.uwa.edu.au/pipermail/tech/2016-January/004730.html
[2]: https://github.com/hlandau/acme/issues/319
[3]:
https://certbot-dns-rfc2136.readthedocs.io/en/stable/#sample-bind-configuration
[4]: https://certbot.eff.org/
[5]: https://wiki.strongswan.org/issues/794


More information about the tech mailing list