I'm Sure its been asked Wild Card Certs and DNS Server

Hello I’m Daniel Du Vall
I host my own DNS using Bind DNS running on Debian Linux 10
I need to use a wildcard cert for *.quadtrax.com as i use it for more than just a web site example is for a postfix server.It is my understanding this needs to do this through DNS.
I used https://linux.m2osw.com/setting-bind-get-letsencrypt-wildcards-work-your-system-using-rfc-2136
To do my initial setup as well as many other sites. The DNS server is running but I am not able to get any further.
Running this command:
certbot certonly \ --dns-rfc2136 \ --dns-rfc2136-credentials ~/etc/bind/letsencrypt_keys/certbot.ini \ -d *.quadtrax.com -d quadtrax.com

Generates this error:certbot: error: unrecognized arguments: --dns-rfc2136 --dns-rfc2136-credentials /root/etc/bind/letsencrypt_keys/certbot.ini -d *.quadtrax.com

All necessary packages installed in the Distro as far as can tell.

Any pointer would be greatly appreciated and if this is not doable that would be helpful as well.

Thanks in advance,
Daniel Du Vall

1 Like

In the tutorial you linked, I can’t see anywhere where it instructs you to install the plugin. You can do so in Debian 10 by running:

apt install python3-certbot-dns-rfc2136

Further documentation can be found here: https://certbot-dns-rfc2136.readthedocs.io/en/latest/

1 Like

It is true that wildcard certs require using DNS based validation, But it is false that you need a wildcard cert on a server with more than one service/name. You can create a non-wildcard certificate with up to 100 different names that will all work on your server. You can also create separate certificates for each service which can be easier in some circumstances.

For instance, you can create a single cert that is valid for quadtrax.com, www.quadtrax.com, and mail.quadtrax.com or you can split those names up into different certs and you can use HTTP based validation with any combination of them.

Wildcard certs are generally more useful when you don't know the name of the service in advance (like a service provider with dynamically created services) or you need a certificate with more than 100 names.

1 Like

I installed that plugin as suggested via another article sorry for failing to mention it.
Could it possibly not be recognised by bind?
I know that with Apache you have to add or enable them as you need but not familiar with that in bind.

1 Like

Thanks @rmbolger I may go that route if i bang my head on this long enough. I was previously doing it this way but with a new server rebuild and migration I thought I would give this a try. Previously I used le.pl running on and ubuntu server.

1 Like

Your current problem is that it's not recognized by Certbot.

Is it listed when you run certbot plugins?

1 Like

This is what i get:
Saving debug log to /var/log/letsencrypt/letsencrypt.log

  • dns-rfc2136
    Description: Obtain certificates using a DNS TXT record (if you are using BIND
    for DNS).
    Interfaces: IAuthenticator, IPlugin
    Entry point: dns-rfc2136 = certbot_dns_rfc2136.dns_rfc2136:Authenticator

  • standalone
    Description: Spin up a temporary webserver
    Interfaces: IAuthenticator, IPlugin
    Entry point: standalone = certbot.plugins.standalone:Authenticator

  • webroot
    Description: Place files in webroot directory
    Interfaces: IAuthenticator, IPlugin
    Entry point: webroot = certbot.plugins.webroot:Authenticator

I think your trouble is the backslashes before the spaces. This is not correct because it causes the literal space character to appear as part of the argument name (like “ -d” instead of “-d”), which can’t be understood by Certbot. The space character should not be part of the argument name, so the backslash characters in your command line are incorrect.

You might have constructed this command based on a tutorial or example in which the backslashes appeared at the ends of multiple lines, in order to combine several lines into a single command. Unfortunately, the behavior of \ at the end of a line and the behavior of \ before a space are rather different in the shell and are not interchangeable. (The \ at the end of a line causes the following line to be combined with the previous line, while the \ before a space causes the space to be passed literally to the command as part of a command-line argument.)

1 Like

Thanks @schoen that seemed to fix the problem. Yes I was copying it from an example and just did not realise the (/) were not needed.

Now is this normal after all has run:

Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for quadtrax.com
dns-01 challenge for quadtrax.com
Cleaning up challenges
File not found: /root/etc/bind/letsencrypt_keys/certbot.ini

1 Like

Are you sure you want to use ~/etc/bind in your command, and not just /etc/bind?

The ~ prefix means “inside my home directory”.

1 Like

I noticed that and removed it just a few ago. Now it seems to be just hung on:

Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for quadtrax.com
dns-01 challenge for quadtrax.com

Well still hung and now hung cleaning up. Interesting but frustrating will need to revisit tonight when I get home.

OK I am stuck once again running:
certbot certonly --dns-rfc2136 --dns-rfc2136-credentials /etc/bind/letsencrypt_keys/certbot.ini -d *.quadtrax.com -d quadtrax.com

Now gets met this far:
2019-12-04 20:18:35,111:INFO:certbot.auth_handler:Performing the following challenges:
2019-12-04 20:18:35,111:INFO:certbot.auth_handler:dns-01 challenge for quadtrax.com
2019-12-04 20:18:35,111:INFO:certbot.auth_handler:dns-01 challenge for quadtrax.com

And that’s it :frowning:

It proceeds no further I have to ctrl C twice otherwise it hangs with:
2019-12-04 20:23:47,743:DEBUG:certbot.error_handler:Calling registered functions
2019-12-04 20:23:47,743:INFO:certbot.auth_handler:Cleaning up challenges

Nothing further.
I feel I am so close but yet so far away. Looking through dns logs and such I find no reason for it hanging and I even left it overnight in case it was just being slow.

1 Like

Sorry to bother but does anyone have any pointers to where I might look to see why it just stops or hangs at certbot.auth_handler:dns-01 challenge for…

While running tail I don’t seem to see any activity on bind that is recognised as the process happening.

I have verifies all my firewall settings and such and don’t see anything that might be blocking it.

Thanks much,
Daniel Du Vall

I’m not familiar with BIND, but I did some searching and came across this tutorial which explains how to do everything from start to finish to obtain a LetsEncrypt wildcard certificate using BIND9 and certbot. :wink:

Thanks @JimPas I will look at this.

1 Like

OK another quick question is the entry dns_rfc2136_server = in the ini file supposed to be the internal network IP of the Bind server or the internet external IP of the DNS Server?
I know this is supposed to be obvious but after looking at to many configuration sites I have confused myself.

1 Like

I do use a local BIND and instead of the certbot plugin, I wrote a set of manual scripts, that takes care of more than just issuing my certificates, but that’s for a separate discussion.

During the DNS challenge, you need to ensure your domain is transferred to all your slaves after the txt challenge is added. You cannot force LE to use a specific DNS server - unless you somehow manage to register your domain with only the master. Plus, it takes a few seconds for the validations to happen - longer if the slaves are busy.

Because you are using a certbot plugin, I suspect they are taking care of these validations - I’m not familiar with it since I have never used them and my script files were coded way before this plugin was created. But I do know the zone transfer is something you are still responsible for.


1 Like

Thanks for the input. Yet more things to help me look for the issue. I loved they way my single cert worked it was flawless but this seem more complicated than needed but I am sure there is good reason.

1 Like

You probably used HTTP-01 type of validation. For that to work it is enough that the webserver to reachable.

The reason is very likely that you are having serious DNS configuration issues:

1 Like