wildcard cert issue with azuredns provider?

[kumarunster]

Hello,

I'm facing below issue, if I try to obtain wild card certificate from letsencrypt with certbot/lexicon.

I found this similar issues https://github.com/certbot/certbot/issues/5673 and referencing https://github.com/AnalogJ/lexicon/issues/182.

It seems for me, that the issue still exist, at least for azure? Does any workaround exists to create a wildcard domain certificate?

2019-09-12 14:27:46 [873] | #### Creating missing certificates if needed (~1min for each) ####
2019-09-12 14:27:46 [873] | >>> Creating a certificate for domain(s): -d *.fireo.de -d fireo.de
2019-09-12 14:27:47 [873] | Saving debug log to /etc/letsencrypt/logs/letsencrypt.log
2019-09-12 14:27:47 [873] | Plugins selected: Authenticator manual, Installer None
2019-09-12 14:27:47 [873] | Obtaining a new certificate
2019-09-12 14:27:48 [873] | Performing the following challenges:
2019-09-12 14:27:48 [873] | dns-01 challenge for fireo.de
2019-09-12 14:27:48 [873] | dns-01 challenge for fireo.de
2019-09-12 14:27:48 [873] | Running manual-auth-hook command: /var/lib/letsencrypt/hooks/authenticator.sh
2019-09-12 14:28:21 [873] | Output from manual-auth-hook command authenticator.sh:
2019-09-12 14:28:21 [873] | Wait 30 seconds before checking that TXT _acme-challenge.fireo.de has the expected value (try 1/3)
2019-09-12 14:28:21 [873] | TXT _acme-challenge.fireo.de has the expected token value (try 1/3)
2019-09-12 14:28:21 [873] | Running manual-auth-hook command: /var/lib/letsencrypt/hooks/authenticator.sh
2019-09-12 14:28:54 [873] | Output from manual-auth-hook command authenticator.sh:
2019-09-12 14:28:54 [873] | Wait 30 seconds before checking that TXT _acme-challenge.fireo.de has the expected value (try 1/3)
2019-09-12 14:28:54 [873] | TXT _acme-challenge.fireo.de has the expected token value (try 1/3)
2019-09-12 14:28:54 [873] | Waiting for verification...
2019-09-12 14:28:55 [873] | Challenge failed for domain fireo.de
2019-09-12 14:28:55 [873] | Challenge failed for domain fireo.de
2019-09-12 14:28:55 [873] | dns-01 challenge for fireo.de
2019-09-12 14:28:55 [873] | dns-01 challenge for fireo.de
2019-09-12 14:28:55 [873] | Cleaning up challenges
2019-09-12 14:28:55 [873] | Running manual-cleanup-hook command: /var/lib/letsencrypt/hooks/cleanup.sh
2019-09-12 14:28:58 [873] | Running manual-cleanup-hook command: /var/lib/letsencrypt/hooks/cleanup.sh
2019-09-12 14:29:01 [873] | Some challenges have failed.
2019-09-12 14:29:01 [873] | IMPORTANT NOTES:
2019-09-12 14:29:01 [873] |  - The following errors were reported by the server:
2019-09-12 14:29:01 [873] |    Domain: fireo.de
2019-09-12 14:29:01 [873] |    Type:   unauthorized
2019-09-12 14:29:01 [873] |    Detail: Incorrect TXT record
2019-09-12 14:29:01 [873] |    "7tNihmGBurUUw3TrqtKxkvJ_-DDBNkLd_3HgLXoC8Cgvrb1uZbnmp3YKnGW4JSEHzZJt90KHfbKLJHIq5cgIsg"
2019-09-12 14:29:01 [873] |    found at _acme-challenge.fireo.de
2019-09-12 14:29:01 [873] |    Domain: fireo.de
2019-09-12 14:29:01 [873] |    Type:   unauthorized

[henningw]

@kumarunster, all - does the issue still exists on azure DNS provider regarding wild-card certificates?

[kumarunster]

@henningw

I dont know. We switched since then to Acme.sh Works like a charm, as well with azure dns and for wildcard domain names. we are setting couple of environment variables, to prepare acme.sh to work with azure dns. The resource should be able to access the keyvault for service principal, and service principal should be permitted to do changes on Azure DNS. but the call is then relatively simple:

hope that helps as idea.

/root/.acme.sh/acme.sh --issue --dns dns_azure \
            --dnssleep 10 --force  \
            -d $VO_DOMAIN -d *.$VO_DOMAIN $staging_flag \
            --log

[henningw]

Thanks for the reply, will investigate further.

[henningw]

Just to note for future reader of this issue, I've created a pull-request to fix the problem in #1359