Certbot failing to create certificate for australiaeast.cloudapp.azure.com

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:australiaeast.cloudapp.azure.com

I ran this command:

certbot certonly --webroot -w /data/challenge -d XXXXXXXXXXXXXXXXXXX.australiaeast.cloudapp.azure.com --agree-tos --email abhi@gmail.com --non-interactive -v --debug-challenges

It produced this output:

certbot certonly --webroot -w /data/challenge -d XXXXXXXXXXXXXXXXXXX.australiaeast.cloudapp.azure.com --agree-tos --email abhi@gmail.com --non-interactive -v --debug-challenges
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Certificate is due for renewal, auto-renewing...
Renewing an existing certificate for XXXXXXXXXXXXXXXXXXX.australiaeast.cloudapp.azure.com
Performing the following challenges:
http-01 challenge for XXXXXXXXXXXXXXXXXXX.australiaeast.cloudapp.azure.com
Using the webroot path /data/challenge for all unmatched domains.

Challenges loaded. Press continue to submit to CA.

The following URLs should be accessible from the internet and return the value
mentioned:

URL:
http://XXXXXXXXXXXXXXXXXXX.australiaeast.cloudapp.azure.com/.well-known/acme-challenge/mAnnJO4kdxjIg4HlWlEApeok7sZynIM7bVAk94WPqTk
Expected value:
mAnnJO4kdxjIg4HlWlEApeok7sZynIM7bVAk94WPqTk.jrC7x1IBoKaTXOxONaXYhl4mGZJCZg_dRZv6ElpsChE

Waiting for verification...
Challenge failed for domain XXXXXXXXXXXXXXXXXXX.australiaeast.cloudapp.azure.com
http-01 challenge for XXXXXXXXXXXXXXXXXXX.australiaeast.cloudapp.azure.com

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Domain: XXXXXXXXXXXXXXXXXXX.australiaeast.cloudapp.azure.com
Type: unauthorized
Detail: 4.25.17.21: Invalid response from http://XXXXXXXXXXXXXXXXXXX.australiaeast.cloudapp.azure.com/.well-known/acme-challenge/mAnnJO4kdxjIg4HlWlEApeok
7sZynIM7bVAk94WPqTk: "<html lang="en"><meta charset="utf-8"/><meta name="viewport" content="width=device-width,initial-scale=1,sh"

Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from t
he provided --webroot-path/-w and that files created there can be downloaded from the internet.

My web server is (include version):

I am running appsmith application in azure VM with docker containerization. I create public DNS for application using azure public IP and routing through application gateway.

The operating system my web server runs on is (include version):
linux- ubuntu

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know):

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

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

2

To use HTTP domain validation your service needs to respond to TCP port 80 requests and in particular needs to serve the expected response to the request at /well-known/acme-challenge

In your case this will mean forwarding HTTP (not just HTTPS) to your server via application gateway.

I would suggest:

  • Use Azure managed certificates where you can
  • If you want to get your own certs, consider using DNS domain validation instead of HTTP. As you are using heavily nested infrastructure (a container, inside docker, inside a vm host, behind application gateway, possibly even load balanced) HTTP validation can be harder to setup and maintain.
4 Likes
3

Is there a documentation for cratering certificate for azure public ip DNS. Certificate creation works in aks ingress in automated way. But it fails for docker containers app.

4

Sorry I'm not an azure expert. My point was that your docker container doesn't need a certificate at all, it's only your public endpoint that needs one, unless you are trying to secure service to service communication within your backend infrastructure. If application gateway is terminate TLS for you then that's where you need your cert.

5

@abhisam5454 , Not sure if this documentation helps - Manage App Service Certificates - Azure App Service | Microsoft Learn

However, there's documentation and guidance on managing DNS records for public IP addresses in Azure, which includes using alias records to prevent dangling references and ensuring proper DNS record management for custom domains associated with Azure resources.

Using Alias Records with Public IP Addresses:

  • When creating a DNS record for a public IP address, you can use an alias record type.
  • This allows you to associate the DNS record with the public IP address resource in Azure.
  • If the public IP address is deleted, the alias record will automatically be updated to reflect that the resource no longer exists.

Documentation Link - Quickstart: Create a public DNS zone and record - Azure portal - Azure DNS | Microsoft Learn

In essence, while there isn't a "cratering certificate" concept, Azure DNS offers features like alias records and custom domain management that ensure robust and reliable DNS resolution for your public IP addresses and custom domains.