Certificate request failed: Error: Didn't finalize order: Unhandled status '403' #49
Comments
|
Hello, same for me. But Single iobroker Host. Letsencrypt works before well in web-instance. Now after Update need to use ACME. Same Error Code than Tottback. I'm using IPv6 only. Port 443 and 80 is forwarded to iobroker Host. |
|
adapter: acme 0.1.0
admin: 6.10.1
js-controller: 5.0.12
node: v18.17.1
O/S: Ubuntu 22.04.3 LTS
Am Sa., 30. Sept. 2023 um 15:17 Uhr schrieb Martin M. <
***@***.***>:
… @Tottback <https://github.com/Tottback> @njdsih
<https://github.com/njdsih>
Please add all involved versions
adapter:
admin:
js-controller:
node:
O/S:
—
Reply to this email directly, view it on GitHub
<#49 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A2MIAOAIPM37GT3EUOH4MUDX5ALVZANCNFSM6AAAAAA5CCKEMM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
|
|
Assuming you are using HTTP challenge. Is http://xxx.hopto.org/ reachable from the public internet? And forwarded to the port configured in ACME? |
|
Yes the xxx.hoptp.org ist reachable by Internet for sure. And the Port 80 is forwarded to ACME. |
|
Ok. Please run in debug and let us know the result. You should see messages like challenge server starting, challenge request, etc. |
|
OK, here it is:
|
|
At first glance I believe this is saying when the certificate issuer tried to establish validity of the order by hitting the challenge URL ( |
|
Port Forwarding in Router was not changed (TCP 80 -> Raspi4: 80) and worked well with LetsEncrypt-Handling in admin-instance. before, Error 403: Forbidden – you don't have permission to access this resource is an HTTP status code that occurs when the web server understands the request but can't provide additional access |
|
I know what 403 means. When I get a chance will look in the code but I think the challenge server should be logging an incoming request and if that doesn't happen the request from certificate issuer can't be getting to the challenge server. |
|
Thanks, I didn't know 403 in details, therefore this was just for my documentation ;-) |
|
Looking at the code/log more (and you should note that this would be much easier if your log was formatted correctly)... seems that challenge request is coming in correctly and being responded to. So error with issuer? BTW, have you got both DNS-01 and HTTP-01 turned on? Not sure why 'dns-01' is being mentioned in the log or if having both challenge methods enabled works. If DNS-01 is also on you could try disabling it? |
|
Thanks for analyzing. I have only HTTP activated. |
|
Now I have a different issue: I can't start the ACME adapter anymore because "already running". |
Could be related to #43? |
|
Seems not to be similar: "ADAPTER_ALREADY_RUNNING" is not mentioned there. Error comes from host not acme-Instance ?! |
|
Got that 2nd issue solved: I had an acme-instance running on the raspi3, alltough it was shown as not active in IOB. |
|
I tried again after some minor adapter updates. Now it works suddenly, Status der Sammlungen But now the adapter stuck in a loop and fill the log: I had to stop it manual. (see log) And to be honest I have no clue how to use the certificates in the Web-instance. I created certifcate entries in the system settings and entered the certificates data from the log. I used this entries in the web-instace and this works, the certificate is accepted as valid. |
|
During my tests for #43 I'm also getting this. Using staging server. Put some logging in the HTTP challenge server and it appears to be functioning correctly. Maybe this is a timing issue with the CA? @Tottback is this now working for you? The restart loop should be fixed in main branch so would be good if you can install direct from Github and let us know. |
|
Hello, I'm trying the ACME mainline version from Github and it seems to work fine now. Thanks. |
Good to know, thanks.
This isn't a problem. The HTTP challenge server was initialised but as a certificate wasn't ordered on this run it didn't actually start listening on the defined port and therefore didn't need to do anything on shutdown. Expected behaviour. |
|
OK. Seems that "warn" is then maybe not the appropriate level for that message, if it's no problem and expected behavior. |
Multihost with Master (Raspi3 node 18.17.1 ) and Slave (Raspi4 node 16.20.0), Host both 5.0.12
Port 80 is forwarded to the Raspi4 with ACME-0.1.0 instance. letsencrypt works before well in admin-instance.
When I activate the ACME-Adapter I get the following error code:
"Certificate request for xxx.hopto.org failed: Error: Didn't finalize order: Unhandled status '403'. This is not one of the known statuses... Requested: 'xxx.hopto.org' Validated: '' { "type": "urn:ietf:params:acme:error:orderNotReady", "detail": "Order's status (\"valid\") is not acceptable for finalization", "status": 403 } Please open an issue at https://git.rootprojects.org/root/acme.jsOn https://git.rootprojects.org/root/acme.js it seems there is no activity.
The text was updated successfully, but these errors were encountered: