Method stopped working: Trouble with multiple domain wildcard certificates

My domain is:
eg1.duckdns.org, *.eg1.duckdns.org, eg2.duckdns.org, *.eg2.duckdns.org

I ran this command:
sudo certbot certonly --manual -d eg1.duckdns.org -d *.eg1.duckdns.org -d eg2.duckdns.org -d *.eg2.georgenad.duckdns.org --manual-public-ip-logging-ok --preferred-challenges dns --email "eg@me.com" --csr ./csr.pem --agree-tos –-dry-run

It produced this output:

Performing the following challenges:
dns-01 challenge for eg1.duckdns.org
dns-01 challenge for eg1.duckdns.org
dns-01 challenge for eg2.duckdns.org
dns-01 challenge for eg2.duckdns.org

My web server is (include version):
Nginx 1.18.0

The operating system my web server runs on is (include version):
Ubuntu 20.04 (arm64)

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don’t know):
yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
no - http get request

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): certbot 0.40.0

I created the csr.pem with:
sudo openssl req -new -config openssl.cnf -key ec.key -out csr.pem

contents of openssl.cnf:
[ req ]
prompt = no
encrypt_key = no
default_md = sha512
distinguished_name = dname
req_extensions = reqext

[ dname ]
CN = eg1.duckdns.org
emailAddress = eg@me.com

[ reqext ]
subjectAltName = DNS:eg1.duckdns.org, DNS:*.eg1.duckdns.org, DNS:eg2.duckdns.org, `DNS:*.eg2.duckdns.org`

This method used to only create 2 DNS challenges one for each domain, which is fine i can update the txt record for each domain name. I cant update two separate records for each domain so I’m guessing something has changed as I’ve made (and am currently using) a few certificates generated this way in the past few months.
I wonder if anyone can shed any light on what I’m now doing wrong? I’m far from a professional, I stumbled upon this method by trial and error before.

Thanks in advance

2 Likes

You will get one dns-01 challenge for example.com and one dns-01 challenge for *.example.com. You can simultaneously have two _acme-challenge.example.com DNS TXT records without any problems.

1 Like

Hi thanks for the response. I’m not sure i can, the http request from the duck dns spec seems to over write the first record rather than make another one. it seems you can only make a single request to update eg.duckdns.org and *.eg.duckdn.org at the same time if you see what i mean?
As i mentioned before. I have previously used this method successfully - I’m sure it only used to make 2 DNS challenges rather than 4

2 Likes

For my own domains I have always created a certificate for domain.com and *.domain.com, which has always resulted in my needing two DNS TXT records. I’m not sure how you were able to only create one. Perhaps they were created and validated serially before?

1 Like

I do have a workaround for you though:

  1. Generate a certificate for only eg1.duckdns.org and eg2.duckdns.org. Discard.
  2. Generate the certificate you actually want.

The second certificate will not require the duplicate challenges because they will be valid for 30 days from generating the first certificate.

3 Likes

I’m not familiar with duckdns, but you should be able to make multiple TXT records in any DNS provider I’ve seen so far. You might just need to surround each value with quotation marks and include both of them?

Longer term it’s ideal to automate renewing the certificates every couple months anyway, so you might want to either use certbot manual-mode’s --manual-auth-hook to run a script that updates the TXT records for you, and then it might be able to authorize each TXT record separately sequentially for you? (Tip: Use --dry-run while you’re doing testing so you’re testing in the test environment and not messing with real certificates and your real rate limits)

Or you might be able to find some other client that supports duckdns natively?

1 Like

Hi Thanks for this… I guess i may have done your workaround accidentally in the first place when experimenting. I’ll give this a go.

2 Likes

Thank for this too. You probably can create multiple txt records with duckdns somehow…the documentation just gives this to update txt records:
https://www.duckdns.org/update?domains={YOURVALUE}&token={YOURVALUE}&txt={YOURVALUE}[&verbose=true][&clear=true]
Im not using the &clear but it just seems to overwrite.
But the documentation also states:

You can update your domain(s) TXT record with a single HTTPS get to DuckDNS
your TXT record will apply to all sub-subdomains under your domain e.g. xxx.yyy.duckdns.org shares the same TXT record as yyy.duckdns.org

so maybe they don’t support multiple records? I’m not sure

1 Like

If you do something like &txt="value1","value2" or &txt="value1"&txt="value2" does it do something reasonable? It may just be that they haven’t particularly described their API well. Multiple TXT values is a standard thing.

In terms of other clients, I’ve not used acme.sh myself but I’ve heard good things about it, and it appears to have some built-in support for duckdns. So if you can’t get certbot working the way you want, you might want to try that (or some other client).

1 Like

As much as I’m a believer in using dns-01 challenges, you might find that using http-01 challenges is a lot easier and fully automated. That would require you not to use a wildcard certificate though.

I know, i started that way, but http-01 challenges don’t support wildcards (or i from what i gather they don’t - please correct if I’m wrong and i can make this easier). Also, the fully automated certbot seems not support ECDSA keys.
The whole thing is just for the fun of learning anyway with my pi4 ; I’m an electronic engineer by trade :slight_smile:

1 Like

At present wildcard certificates require dns-01 challenges. I do not see that changing anytime soon.

2 Likes

Thanks :slight_smile: I’ll have a play and see what i can do. I’d not seen the acme.sh bit about duckdns before.

1 Like

So the issue seems to be with DuckDNS’ API - no combination i can find gives multiple txt entries.
I tried acme.sh, (using the DuckDNS support) - it’s really easy to use, but it too fails.
Acme.sh reports it has successfully updated the TXT records - which it has, but the first ones are over written so two of the four challenges fail.
The only way i can find to issue one certificate for everything is to do what griffin suggested and make non-wildacrd certs first and bin them, so I only get two challenges when issuing the ones i want.

Thanks again for the advice.

2 Likes

Hmm. My limited understanding of the ACME protocol is that it would be possible for a client to handle each authorization challenge sequentially, so you could update the TXT record to one value, tell the ACME server to validate it, and then update the TXT to the second value and tell the server to validate the other DNS challenge for the same name. But it may be that in practice clients don’t do it that way.

You might be able to make a ticket with acme.sh to see if they can change it around, or try one of the other bazillion clients. I don’t know how comfortable you are writing software, but you might be able to script something with the manual hooks of certbot or adapt something else to your purposes.

1 Like

Certbots manual hooks look like it would make it possible. I’m sure a bash script for this wouldn’t be beyond me (programming microprocessors in C/C++ is my thing, but I’m adaptable lol) , but i reckon it would still involve binning the first certs.
For automatic renewals acme.sh looks the most promising easily; I’ve just noticed https://github.com/acmesh-official/acme.sh/wiki/How-to-issue-a-cert#3-multiple-domains-san-mode--hybrid-mode
which seems to allow different (and by the looks of it separate but the same) validation methods for one certificate. Job done :slight_smile:

2 Likes

Yep - acme.sh hybrid mode works nicely using the built in duck DNS api. Easy ECC keys and auto renewals - nice.
EDIT - sort of, hybrid mode still tries to add multiple txt records, i got caught out by the domains already being verified (which means it must be hours not 30 days?), webroot for one and dns for the other should do it.

To help others:

Set duck DNS token with:

export DuckDNS_Token="aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"

Then to issue the certifcate:

$ (sudo) acme.sh --issue --keylength ec-256 \
> -d eg1.duckdns.org -d eg2.duckdns.org -w /home/wwwroot/example.com \
> -d '*.eg1.duckdns.org' -d '*.eg2.duckdns.org' --dns dns_duckdns --insecure
3 Likes

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