search

webprofusion / certify

Professional ACME Client for Windows. Certificate Management UI, powered by Let's Encrypt and compatible with all ACME v2 CAs. Download from certifytheweb.com
https://certifytheweb.com
Other
1.48k stars 255 forks source link

Integrated web server not handling ACME requests. HTTP challenge replaced with DNS challenge #686

Closed Bluejanis closed 2 days ago

Bluejanis commented 2 days ago

The integrated web server does not handle my acme Requests. In the log file, it states using a DNS challenge, when it should use the HTTP challenge.

This is the error in my log:

2024-09-22 06:29:15.015 +02:00 [INF] Certify/6.1.0.0 (Windows; Microsoft Windows NT 10.0.19045.0) 
2024-09-22 06:29:15.015 +02:00 [INF] Beginning certificate request process: BluE-Legion -> Satisfactory using ACME provider Anvil
2024-09-22 06:29:15.015 +02:00 [INF] The selected Certificate Authority is: Let's Encrypt
2024-09-22 06:29:15.015 +02:00 [INF] Requested identifiers to include on certificate: satisfactory.mydomain.de [dns];satisfactory.ddns.net [dns]
2024-09-22 06:29:16.275 +02:00 [INF] Created ACME Order: https://acme-v02.api.letsencrypt.org/acme/order/1960199266/307256618466
2024-09-22 06:29:18.696 +02:00 [INF] Got http-01 challenge https://acme-v02.api.letsencrypt.org/acme/chall-v3/406800134646/3ndWJw
2024-09-22 06:29:19.003 +02:00 [INF] Got dns-01 challenge https://acme-v02.api.letsencrypt.org/acme/chall-v3/406800134646/PQgevA
2024-09-22 06:29:20.966 +02:00 [INF] Got http-01 challenge https://acme-v02.api.letsencrypt.org/acme/chall-v3/406800134656/oAi-Ow
2024-09-22 06:29:21.273 +02:00 [INF] Got dns-01 challenge https://acme-v02.api.letsencrypt.org/acme/chall-v3/406800134656/W4pAuA
2024-09-22 06:29:27.205 +02:00 [INF] Http Challenge Server process available.
2024-09-22 06:29:27.205 +02:00 [INF] Preparing automated challenge responses for: satisfactory.mydomain.de [dns]
2024-09-22 06:29:27.205 +02:00 [INF] Preparing challenge response for the issuing Certificate Authority to check at: http://satisfactory.mydomain.de/.well-known/acme-challenge/mQzDNAgTbUb_nfSmXaY4MVjpkYElAMP074lZs4eOpHA with content mQzDNAgTbUb_nfSmXaY4MVjpkYElAMP074lZs4eOpHA.7YfTCLNZklQyuqIvPm6aQR1Oih7nJlKVwSz_2dT5tnM
2024-09-22 06:29:27.205 +02:00 [INF] If the challenge response file is not accessible at this exact URL the validation will fail and a certificate will not be issued.
2024-09-22 06:29:27.205 +02:00 [INF] Using website path [Auto]
2024-09-22 06:29:27.205 +02:00 [WRN] The website root path for BluE-Legion -> Satisfactory could not be determined. Fileysystem based http validation will not be possible.
2024-09-22 06:29:27.205 +02:00 [INF] Checking URL is accessible: http://satisfactory.mydomain.de/.well-known/acme-challenge/mQzDNAgTbUb_nfSmXaY4MVjpkYElAMP074lZs4eOpHA [proxyAPI: True, timeout: 5000ms]
2024-09-22 06:29:32.215 +02:00 [WRN] Problem checking URL is accessible : http://satisfactory.mydomain.de/.well-known/acme-challenge/mQzDNAgTbUb_nfSmXaY4MVjpkYElAMP074lZs4eOpHA Eine Aufgabe wurde abgebrochen.
2024-09-22 06:29:32.215 +02:00 [INF] Checking URL is accessible: http://satisfactory.mydomain.de/.well-known/acme-challenge/mQzDNAgTbUb_nfSmXaY4MVjpkYElAMP074lZs4eOpHA [proxyAPI: False, timeout: 5000ms]
2024-09-22 06:29:37.237 +02:00 [ERR] Failed to confirm URL is accessible : http://satisfactory.mydomain.de/.well-known/acme-challenge/mQzDNAgTbUb_nfSmXaY4MVjpkYElAMP074lZs4eOpHA 
System.Threading.Tasks.TaskCanceledException: Eine Aufgabe wurde abgebrochen.
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei System.Net.Http.HttpClient.<FinishSendAsyncBuffered>d__58.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei Certify.Shared.Core.Utils.NetworkUtils.<CheckURL>d__6.MoveNext() in D:\a\certify-internal\certify-internal\src\certify-build\certify\src\Certify.Shared\Utils\NetworkUtils.cs:Zeile 151.
2024-09-22 06:29:37.237 +02:00 [ERR] Failed prerequisite configuration checks (SSL_ACME)

First it tries to setup http server, but then uses dns challenge instead:

2024-09-22 06:29:27.205 +02:00 [INF] Http Challenge Server process available.
2024-09-22 06:29:27.205 +02:00 [INF] Preparing automated challenge responses for: satisfactory.mydomain.de [dns]

Notable is this log statement: 2024-09-22 06:29:27.205 +02:00 [INF] Using website path [Auto] 2024-09-22 06:29:27.205 +02:00 [WRN] The website root path for BluE-Legion -> Satisfactory could not be determined. Fileysystem based http validation will not be possible. It seems like it is expecting a website root path of a web server, like IIS. I do not wish to install IIS or another web server at the moment.

Regarding Firewall settings: I opened ports 80 and 443 in my router. In Windows Firewall, I added the application Certify.UI.exe and allowed all incoming traffic to it. When I start a local website in docker, it can also be accessed externally. This web service is not running, when I try to create the certificate. Certify the web should be able to use the ports exclusively.

Bluejanis commented 2 days ago

After some experiments in the UI, I got this error message now: Built-in Http Challenge Server process unavailable or could not start. Challenge responses will fall back to the default web server process (if available).

webprofusion-chrisc commented 2 days ago

Hi,

Something on your machine is using port 80 or otherwise a port 80 http.sys listener is not allowed on your system (which would be unusual). Either way the app wasn't able to create the listener, so it would then have to fallback to using whatever webserver you have in order to serve an HTTP challenge.

The line Preparing automated challenge responses for: satisfactory.mydomain.de [dns] means satisfactory.mydomain.de is a DNS identifier as opposed to an IP address or another form of certificate subject., I agree that's confusing and we''ll probably change that.

webprofusion-chrisc commented 2 days ago

The best place for community support (assuming you're just using the Community Edition) is https://community.certifytheweb.com/

Bluejanis commented 2 days ago

Something on your machine is using port 80 or otherwise a port 80 http.sys listener is not allowed on your system (which would be unusual). Either way the app wasn't able to create the listener, so it would then have to fallback to using whatever webserver you have in order to serve an HTTP challenge.

Nope! Nothing else is running. Definitely seems like an issue with this certify app.

The line Preparing automated challenge responses for: satisfactory.mydomain.de [dns] means satisfactory.mydomain.de is a DNS identifier as opposed to an IP address or another form of certificate subject., I agree that's confusing and we''ll probably change that.

Thanks for clarifying. So that was not the issue. Must be something else, then.

Not sure why you closed this bug so prematurely!

But that's okay for me, I can just uninstall this buggy program, since I got it working flawlessly using letsencrypt via docker. Just FYI, this worked (so it is clearly no port issue):

$certPath = "F:\Epic Games\SatisfactoryDS\LetsEncrypt\"
[System.IO.Directory]::CreateDirectory($certPath)
cd $certPath
docker run -it --rm -p 80:80 -p 443:443 --name satisfactory-letsencrypt-new `
-v "$($certPath)etc:/etc/letsencrypt" `
-v "$($certPath)log:/var/log/letsencrypt" `
certbot/certbot certonly --standalone `
-m letsencrypt.domain@mydomain.de --agree-tos --no-eff-email `
-d satisfactory.mydomain.de
# Done

So it is weird, that your program was not able to handle this situation. And it was easier to figure out something else using the command line, than contacting your support. And apparently you don't like to look into bugs..

webprofusion-chrisc commented 2 days ago

Sorry man, closing your issue was not intended as a slight against you, we just do not provide support via GitHub.

Our http challenge server is via http.sys, so if there is a bug then it's in Windows.

There are many possible configuration issues that can cause problem but none of those are bugs. If you are running docker there's a chance it is using port 80 for an existing container and non-windows native apps tend not to use the http pipeline sharing that http.sys provides (they just allocate the port to themselves).