Dns-01 challenge fails with Azure P2S VPN

My domain is: diconcloud.onmicrosoft.com

I ran this command: sudo certbot certonly --dns-azure-config ./mycredentials-private.ini -d *.diconcloud.onmicrosoft.com

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log

How would you like to authenticate with the ACME CA?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: Obtain certificates using a DNS TXT record (if you are using Azure for DNS).
(dns-azure)
2: Spin up a temporary webserver (standalone)
3: Place files in webroot directory (webroot)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-3] then [enter] (press 'c' to cancel): 1
Plugins selected: Authenticator dns-azure, Installer None
Requesting a certificate for *.diconcloud.onmicrosoft.com
Performing the following challenges:
dns-01 challenge for diconcloud.onmicrosoft.com
Waiting 10 seconds for DNS changes to propagate
Waiting for verification...
Challenge failed for domain diconcloud.onmicrosoft.com
dns-01 challenge for diconcloud.onmicrosoft.com
Cleaning up challenges
Some challenges have failed.

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: diconcloud.onmicrosoft.com
   Type:   dns
   Detail: DNS problem: NXDOMAIN looking up TXT for
   _acme-challenge.diconcloud.onmicrosoft.com - check that a DNS
   record exists for this domain

My web server is (include version): N/A

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

My hosting provider, if applicable, is: Azure

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

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

I have an Azure virtual network that I can connect to using a P2S configuration. This is set up for a private intranet. There are multiple VMs on the network that I can access via SSH/RDP. There is a private DNS zone that is used for all the VMs in the virtual network. There is also a dedicated DNS server VM that runs the default Windows DNS server and forwards to Azure's DNS server.

I am trying to run gitlab on one of the VMs, and to do that I need an SSL certificate for HTTPS. Using gitlab's internal LetsEncrypt integration will not work since there is no public IP address. I have been reading that I do not need a public IP address to get a certificate validated through a dns-01 challenge from LetsEncrypt.

I have tried a few different certbot plugins, I have tried using dehydrated, I have tried acme.sh, and nothing seems to work. Everything in this blog post made sense to me and it all tracked up until the point where the challenge failed. These 2 plugins: one, two result in the same end situation/error message. In order to get these plugins to work, I also created a (non-private) Azure DNS zone with the same name, which should result in a split-horizon configuration. Using this plugin with certbot, I am able to see in the Azure portal that the TXT record gets set successfully by certbot in the non-private Azure DNS zone. After that, the challenge fails and the TXT record is deleted successfully.

I would greatly appreciate any help or ideas as to why this challenge is failing.

Hi @quoyle

simple answer: That's not your domain.

That domain doesn't exist. So you are not the owner and you can't create a public trusted certificate with that domain name.

Read

So it's not possible to create a Letsencrypt certificate with that domain name.

1 Like

@JuergenAuer Thank you for your response. The page you linked to makes sense to me. But if "diconcloud.onmicrosoft.com" isn't my domain, then what is? How do I find the name of my domain? And how did you know/find out that the "diconcloud.onmicrosoft.com" domain doesn't exist?

For whatever public Azure DNS zone that you're using for diconcloud.onmicrosoft.com, can you put a TXT record in it and then see that it changes in public DNS?

It may be that you need to use a "real" domain name, rather than the onmicrosoft.com one that they "give" you. I don't quite understand how that onmicrosoft.com works, as I somehow "got" one myself when I set up Exchange Online Protection and it's part of the username to log into their system, but I don't know how to really "use" it for anything. But it may be that it would work for your purposes, as long as you can actually edit DNS records for it (as seen by users on the Internet and not just your own network).

That's a simple name server query:

dig NS diconcloud.onmicrosoft.com
nslookup -type=NS diconcloud.onmicrosoft.com
nslookup diconcloud.onmicrosoft.com

Always the same - a NXDOMAIN result -> that domain doesn't exist.

You must register a domain.

@petercooperjr

and then see that it changes in public DNS

What do you mean by this? How would I check that? I can set TXT entries in the Azure DNS zone, and they take the form xxx.diconcloud.onmicrosoft.com => some text value, where 'xxx' is what I can set. For the acme challenges, the record was _acme-challenge.diconcloud.onmicrosoft.com => some string.

That's

not a public visible dns zone. It's only your private thing, nothing else, completely unrelevant.

Who owns onmicrosoft.com? That domain is registered - see https://check-your-website.server-daten.de/?q=onmicrosoft.com

There are name servers defined.

If you set a TXT value for _test.diconcloud.onmicrosoft.com, it should show up at

https://dns.google/query?name=_test.diconcloud.onmicrosoft.com&rr_type=TXT&ecs=

Or you can use a command-line tool like @JuergenAuer suggests,

nslookup -type=TXT _test.diconcloud.onmicrosoft.com 8.8.8.8

Where 8.8.8.8 is Google's DNS server just as an example, you could try 1.1.1.1 or any of the other public resolvers. It needs to be available to everyone on the Internet, not just on your network.

You might need to take some step to have diconcloud.onmicrosoft.com delegated to the public Azure zone you're defining?

@JuergenAuer

You must register a domain.

I have been struggling with this issue for many many hours and these 5 words solved most of my problems. From here I was able to look into what registering a domain means and understand that even though this is an intranet, it still needs a publicly-registered domain name in order to get a certificate from LetsEncrypt. There are extra steps involved in creating the necessary resources in Azure, which was unclear to me before. I was able to use Azure to create an "App Service Domain," and I named it "diconcloud.com" From there, it automatically created a diconcloud.com DNS zone in Azure, and I restarted the whole certificate-obtaining process using diconcloud.com and things worked this time. (For anyone else reading this, I also had to remove the auto-generated lock from the DNS zone using az lock list and then az lock delete --ids <the-id-from-the-list-command> in order to allow certbot to remove the TXT records after the challenges complete.)

There will be more setup work for me to get all the VMs talking to each other and install the certificates, etc. but thank you for the help!

2 Likes

Yes, that's required.

Public trusted certificate -> public visible domain name -> CA must be able to check dns or webserver.

Happy to read you have found a solution :+1:

1 Like

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