403 error when using Apache Tomcat with Certbot/Win-Acme/CertifyTheWeb in Windows Server

[FM2023]

Thanks. We are running this Web server on Windows for years using certbot cert.
Tried Win-Acme and Certifythe Web as certbot is no longer supported. But no luck.

[rg305]

Is there some kind of load-balancer thingy involved?

[FM2023]

Only Azure AppGW. No change in the system.

[rg305]

@FM2023

No change in the system.

Well, something must have changed...

Both IPv4 and IPv6 return the same response:

curl -Iik4 tstpublic.serviceconnect.defence.gov.au/.well-known/acme-challenge/Test_File-1234
HTTP/1.1 403 Forbidden
Date: Thu, 12 Dec 2024 01:10:53 GMT
Content-Type: text/html
Content-Length: 1066
Connection: keep-alive
ETag: "675a0f86-42a"
x-azure-ref: 20241212T011053Z-1577f6f44dbqp74dhC1ATL7rm400000001pg000000008dfv
X-Cache: CONFIG_NOCACHE

curl -Iik6 tstpublic.serviceconnect.defence.gov.au/.well-known/acme-challenge/Test_File-1234
HTTP/1.1 403 Forbidden
Date: Thu, 12 Dec 2024 01:11:15 GMT
Content-Type: text/html
Content-Length: 1066
Connection: keep-alive
ETag: "675a0f86-42a"
x-azure-ref: 20241212T011115Z-1577f6f44dbqrm6fhC1ATL0ksn000000020g000000006mty
X-Cache: CONFIG_NOCACHE

That said, they don't look like Tomcat responses.

[rg305]

From a browser:
"tstpublic.serviceconnect.defence.gov.au/.well-known/acme-challenge/Test_File-1234"

[webprofusion]

@FM2023 nobody here can solve this for you and you need to escalate this to your internal networking team (or apparently the ServiceConnect administrator).

You are attempting to use HTTP domain validation which in turn requires that an http (TCP port 80) request against /.well-known/acme-challenge should resolve to your server where your ACME client is running (certbot, win-acme, Certify The Web etc). Currently there are several layers of abstraction and network control present which are preventing this process from completing normally.

Once an HTTP domain validation request finally reaches your server (so, beyond application gateway, various firewalls and application proxies) your server must know to respond, so if Apache Tomcat is the HTTP listener then you would need to use a filesystem/webroot method to write the challenge response file to the web servers filesystem, so that in turn the file can be served as a challenge response.

An alternative to HTTP domain validation is DNS domain validation (updating a TXT record). Your organization may have a managed solution implemented for this already.

[FirstTimeEZ]

When I go to this link you posted

http://tstpublic.serviceconnect.defence.gov.au/.well-known/acme-challenge/-7SbJ_apDgNR_cZMwJgyEh0iX7dOm3vyD-ZE-CIoxok:

I get a message that says:

There was an error accessing service connect, please return to "https://tstpublic.serviceconnect.defence.gov.au" and start again

This message looks like something an external firewall might produce, if this is some new system you have no control over that will replace the challenge response it will break the certification no matter what you try.

This page should be the response to the challenge in the link.

---

If you are determined to get something working you could use server-ssl, which is Node.js and has wide support for windows, you would need to make some changes to save the certificate and private key to the correct place and make sure you always start your apache/tomcat server first so server-ssl doesn't bind to port 443 or remove the listener.

server-ssl just redirects anything that isn't a challenge issued by the server to the https url

I am interested in the outcome/output, you should use the --staging flag, I would also be interested in a pull request if you make this work with apache/tomcat out of the box

---

J@BUD MINGW64 ~/Desktop/server-ssl (master)
$ ./start-windows.bat --letsEncrypt --domains=['tstpublic.serviceconnect.defence.gov.au'] --staging
Starting SSL Web Server
Time until renewal required: 89 days, 9 hours, 54 minutes
Starting Lets Encrypt ACME Daemon!
Copyright © 2024 FirstTimeEZ
--------
USING THE STAGING SERVER
HTTPS Server is running on port 443
HTTP Server is redirecting requests to 443
Node.js is up to date v23.4.0
It has been: 47233.451 seconds since you last generated certificates
Load ACME Keys From File
Load Signing Keys From File
Next Nonce QOVu-bna_CjkP-iPF6QLYmATzpOmh1pmIcRo_apQOUXHhRx3nDk
Next Nonce QOVu-bnajs_566deiTHbA5YZJzJ72tljqtX0FHxxa-VIJeisC0c
Next Nonce GrOSSYvVzK9CeVgx4Gk8XDtxY4HpMsXpaaTU1qoIXO9jH9niXqE {
  answer: {
    get: {
      type: 'http-01',
      url: 'https://acme-staging-v02.api.letsencrypt.org/acme/chall/175594504/15332435044/-CSDBQ',
      status: 'pending',
      token: 'ERr8glRxfdnfEEswYceyx5VAlWS-NNhy4iEesDFat-I'
    },
    location: 'https://acme-staging-v02.api.letsencrypt.org/acme/chall/175594504/15332435044/-CSDBQ'
  },
  nonce: 'GrOSSYvVzK9CeVgx4Gk8XDtxY4HpMsXpaaTU1qoIXO9jH9niXqE'
}

Then server-ssl will respond on port 80 at this url:

http://tstpublic.serviceconnect.defence.gov.au/.well-known/acme-challenge/ERr8glRxfdnfEEswYceyx5VAlWS-NNhy4iEesDFat-I

---

because you don't need to configure anything except the domain names on windows if server-ssl fails to generate a certificate then you have one of the following issues:

1. You don't own the domain
2. Your DNS is pointing to the wrong server
3. Firewall issues
4. Lets Encrypt is having issues (unlikely)
5. Unknown networking issue

[FM2023]

We moved to Digicert without changing anything.