CERTBOT_DOMAIN for wildcard domains

I’m trying to request a certificate for a domain and its wildcard subdomains (i.e. subdomain.example.com and *.subdomain.example.com )

I’m using certbot-auto with DNS verification. I use --manual-auth-hook to call my DNS update script. The DNS update script talks to AWS Route53 to add the TX record based on the CERTBOT_DOMAIN environment variable. For some reason, it seems certbot-auto sets CERTBOT_DOMAIN to “subdomain.example.com” for both domains. I was expecting one to be “subdomain.example.com” and “*.subdomain.example.com” but am getting “subdomain.example.com” for both.

Is certbot-auto behaving correctly?

AWS doesn’t seem to allow me to create multiple TX records for the same domain. It will either error out if I try to create the two TXT records for the same domain or overwrite the first one if I use UPSERT (update or insert) instead. Either way, DNS verification fails.

Is this a limitation of AWS Route53 or is there something wrong with my DNS update script?

Thanks in advance.


You can’t set a DNS resource record (RR) with an actual wildcard symbol in it. Let’s Encrypt requires you to put two TXT RRs on the same hostname for the example you’re presenting here.

Probably a limitation of AWS Route53, because two TXT records are required.

A workaround might be getting two separate certificates, one for the “base” subdomain and one for the wildcard. After that, when both hostnames are validated, it should be possible to get a certificate with both hostnames without actually the need for validating the hostnames again.

It seems the certbot-dns-route53 plugin can handle two TXT records: Amazon route53 wildcard domain support question / issue

Not sure how you’d fix that with the manual plugin tho. Perhaps we could have a look at your DNS update script?

1 Like

First, thanks so much for your help.

My script is (I had borrowed it from an article I read):

# shell script to be called by certbot-auto for domain verification
# this creates the Let's Encrypt TXT record LE will use to verify domain ownership
# this is needed for LE to issue the certificate
# from https://hackernoon.com/easy-lets-encrypt-certificates-on-aws-79387767830b
aws route53 wait resource-record-sets-changed --id \
  $(aws route53 change-resource-record-sets --hosted-zone-id \
      "$(aws route53 list-hosted-zones-by-name --dns-name $2. \
      --query HostedZones[0].Id --output text)" \
    --query ChangeInfo.Id \
    --output text \
    --change-batch "{ \
      \"Changes\": [{ \
        \"Action\": \"$1\", \
        \"ResourceRecordSet\": { \
          \"Name\": \"_acme-challenge.${CERTBOT_DOMAIN}.\", \
          \"ResourceRecords\": [{\"Value\": \"\\\"${CERTBOT_VALIDATION}\\\"\"}], \
          \"Type\": \"TXT\", \
          \"TTL\": 30 \
        } \
      }] \
    }" \

certbot-auto command:

/opt/letsencrypt/letsencrypt-auto certonly --non-interactive \
    --manual --preferred-challenge dns --config-dir "./letsencrypt" \
    --work-dir "./letsencrypt" --logs-dir "./letsencrypt" \
    --agree-tos --manual-public-ip-logging-ok \
    --domains *.subdomain.example.com,subdomain.example.com \
    --email email@example.com \
    --manual-auth-hook "./auth-hook.sh UPSERT example.com" \
    --manual-cleanup-hook "./auth-hook.sh DELETE example.com"

I did more digging around and it looks like AWS route53 doese allow more than one TXT record by using a list of space separated list of strings. I think I just need to modify my script to update the read the existing value if it exists and append to it instead of just overwriting it. That’s what I’ll try next. If it works, I’ll post the updated script.

Thanks again for the help. If you can think of anything else in the meantime, please let me know.

1 Like

I think at this point the smartest thing for me to try is to use the built in certbot-dns-route53 plugin. I didn’t know such a thing existed. Thanks again.

1 Like

That would be a good idea, yes. However, I’m not actually sure how to do that with the certbot-auto script.

1 Like

You can install the Route53 plugin into certbot-auto using:

/opt/eff.org/certbot/venv/bin/pip install certbot-dns-route53

The problem is that the automatic upgrades of certbot-auto will result in the plugin being occasionally deleted, so you would need to run certbot-auto (and its cron task) with --no-self-upgrade , and upgrade it manually rom time to time.


Yep. Getting rid of my own script and using the Route53 plugin solved the issues.

I had to bootstrap certbot-auto by doing in my .ebextensions config file:

/opt/letsencrypt/certbot-auto --debug --non-interactive --install-only

followed by:

source /opt/eff.org/certbot/venv/bin/activate && pip install certbot-route53 && deactivate

and finally:


where request_cert.sh looks like:

/opt/letsencrypt/certbot-auto certonly \
            --debug \
            --non-interactive --preferred-challenge dns \
            --config-dir "/opt/letsencrypt" --work-dir "/opt/letsencrypt/certs" \
            --logs-dir "/var/log" --agree-tos \
            --manual-public-ip-logging-ok \
            -d *.subdomain.example.com \
            -d subdomain.example.com \
            --email email@example.com \
            --dns-route53 \

Thanks everyone!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.