Some challenges have failed

[ndowson]

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. crt.sh | 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: tst2public.xxx
I ran this command: certbot certonly -v

It produced this output:
C:\Windows\system32>certbot certonly -v
Saving debug log to C:\Certbot\log\letsencrypt.log

How would you like to authenticate with the ACME CA?

---

1: Spin up a temporary webserver (standalone)
2: Place files in webroot directory (webroot)

---

Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1
Plugins selected: Authenticator standalone, Installer None
Please enter the domain name(s) you would like on your certificate (comma and/or
space separated) (Enter 'c' to cancel): tst2public.xxx
Requesting a certificate for tst2public.xxx
Performing the following challenges:
http-01 challenge for tst2public.xxx
Waiting for verification...
Challenge failed for domain tst2public.xxx
http-01 challenge for tst2public.xxx

Certbot failed to authenticate some domains (authenticator: standalone). The Certificate Authority reported these problems:
Domain: tst2public.xxx
Type: unauthorized
Detail: 2620:1ec:4e:1::38: Invalid response from http://tst2public.xxx/.well-known/acme-challenge/_xr6xFVabt-kxiuifkbtjqWVxfDBhzr_akEbo6_Qmm0: 404

Hint: The Certificate Authority failed to download the challenge files from the temporary standalone webserver started by Certbot on port 80. Ensure that the listed domains point to this machine and that it can accept inbound connections from the internet.

Cleaning up challenges
Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile C:\Certbot\log\letsencrypt.log or re-run Certbot with -v for more details.

My web server is (include version): Apache Tomcat installed on Windows 2019

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

My hosting provider, if applicable, is: defence.gov.au

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

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 2.1.1

[_az]

Are you trying to create a certificate to upload to Azure Application Gateway?

Or is this certificate going to be used locally on the Windows server?

[ndowson]

Yes we will use the certificates locally in a KeyStore and use that same key store on the Application Gateway. We have connected to the URL via Port 80/HTTP and have previously been successful with other URLs. Just this one is having issues.

[_az]

You'll probably want to use --webroot mode in Certbot rather than --standalone mode.

The difference is that standalone mode requires exclusive use of port 80, whereas you can make webroot mode cooperate with Tomcat, without having to stop and start Tomcat.

Tomcat can be a little bit fidgety depending on how customized its configuration is. If the ROOT webapp is still present in the webapps directory (as it is in a default installation), then you can run Certbot like this:

certbot certonly -d example.com --webroot -w "C:\tomcat\webapps\ROOT" --deploy-hook "C:\tomcat\deploy.ps1"

Making sure to:

1. Replace the path (C:\tomcat) with your real Tomcat path.
2. Omit or change the path to the --deploy-hook - I included this to show you that you can make Certbot run a Powershell script when the certificate is obtained or whenever it is renewed. Here you do various tasks related to key stores and your Azure services.

If, on the other hand, the ROOT webapp is removed from your Tomcat installation, then you will need to add a separate <Context ...> in your web.xml to give /.well-known/acme-challenge/ a permanent directory to live, and then point Certbot at that directory you nominated.

[rg305]

It looks like you might need to use DNS-01 authentication:

Name:      part-0007.t-0009.fdv2-t-msedge.net
Addresses: 2620:1ec:4e:1::35
           2620:1ec:4f:1::35
           13.107.237.35
           13.107.238.35
Aliases:   tst2public.serviceconnect.defence.gov.au
           npserviceconnect.azurefd.net
           star-azurefd-prod.trafficmanager.net
           shed.dual-low.part-0007.t-0009.fdv2-t-msedge.net

But, I may be wrong...

[ndowson]

@_az

certbot certonly -d tst2public.xxx --webroot -w "C:\tomcat\webapps\ROOT"

We got is working , we did not have the \ROOT on the end of the webroot, which we did not need previously.. Once we placed \ROOT to -webroot it worked. Will use this in future. Thanks for your help...

[rg305]

@ndowson

Will use this in future.

You could also just renew it [as it was issued]:
certbot renew

[ndowson]

Yes but we will need to have http port 80 open which we can not have. So the renewal will be a manual task ..

[_az]

@ndowson

Yes but we will need to have http port 80 open which we can not have

Not knowing your requirements, there's one thing worth noting:

If you set up Azure Application Gateway to do an HTTP redirect from port 80 to port 443 (HTTPS), then automated renewal should be possible with --webroot.

It's usually a best practice to keep port 80 open, though I understand that may not be the case in particular sensitive environments.

[webprofusion]

If you can't keep port 80 open but still want to automate then I'd suggest DNS validation, and assuming you don't want to update TXT records in your real domain you can use a surrogate domain via a CNAME (e.g. have a CNAME _acme-challenge.tst2public pointing to an external zone, hosted for instance in Azure DNS, which is then used only for DNS challenge validation). Certify The Web (which I work on, and which is also part of an Australian company) has Azure specific functionality, and a Tomcat deployment task.

Note also that if you use DNS validation you can acquire your cert on any machine, thereafter deployment is just scripting/copying to where you need it, you can also utilise things like Azure Keyvault or Hashicorp Vault (store your cert there, then regularly pull it on your web host, which is then otherwise ignorant of the whole certificate renewal process).

If your service is public and will have port 443 open there is still the option of tls-alpn-01, which works on port 443 by represent a special challenge over TLS, but would require you to stop your webserver (to free up 443), run the challenge, then start it again. I believe win-acme has self-hosted tls-alpn-01 support, I'm not sure which other tools do on Windows.