This is probably a bug in admin....

When performing config, the 'Challenges' tab opens first for whatever reason. By default 'Maintainer email passed to CA' on the 'Main' tab is blank. If one does not actually open the 'Main' tab though, config can be saved despite the email being blank as it's validator function doesn't seem to be called.

Think about adding version 0.1.0 to stable repository.

Version: stable=0.0.0 (0 days old) => latest=0.1.0 (30 days old)
Installs: stable=0 (0%), latest=67 (93.06%), total=72
Click to edit

When you enter challenge information it not possible to save them
and
Because of number type for port its hard to remove the content of the input and enter for example 80

error in log
TypeError: this.getCertificateCollectionAsync is not a function at Acme.onReady (/opt/iobroker/node_modules/iobroker.acme/main.js:71:40) at Acme.emit (node:events:514:28) at Acme._callReadyHandler (/opt/iobroker/node_modules/@iobroker/js-controller-adapter/build/lib/adapter/adapter.js:9028:18) at /opt/iobroker/node_modules/@iobroker/js-controller-adapter/build/lib/adapter/adapter.js:9006:26

HTTP-01 challenge is only good for collections where common name is a host who's public port 80 is mapped to the HTTP-01 challenge server started on the configured port & interface.

For other names, wildcards, etc. DNS-01 challenge must be used.

There should be something in the admin interface that sanity checks this stuff and warns users when HTTP-01 challenge is unlikely to work.

In installations where there is only one public IP and port available for incoming web requests from the public internet, the ACME adapter attempts to stop the other adapter listening on port 80 before setting up HTTP challenge, then restart the other adapter when certificate issue has completed.

This solution is inelegant, leads to downtime on the other adapter (albeit very briefly) and the possibility of an error in ACME leading to the other adapter not being restarted.

In this scenario I believe a far better solution would be to enforce the use of the Proxy adapter to send appropriate paths to ACME/other adapters as necessary. Depends on ioBroker/ioBroker.proxy#133

If the ACME adapter could automatically request the HTTP challenge path be forwarded to it, that would be even better. Depends on ioBroker/ioBroker.proxy#134

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.js

On https://git.rootprojects.org/root/acme.js it seems there is no activity.

• 👀 [W171] "common.title" is deprecated in io-package.json
• 👀 [W105] "common.titleLang" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
• 👀 [W109] "common.desc" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
• 👀 [W513] "gulpfile.js" found in repo! Think about migrating to @iobroker/adapter-dev package

Is there any documentation on how to add a new dropdown entry as a pull request?

I really would like to use Dynu.com.

https://github.com/acmesh-official/acme.sh/blob/master/dnsapi/dns_dynu.sh

I don't know why, but on the OpenWRT and Ngnix acme implementation, I set Environment variable dns_dynu_auth_token, although it's not found in the linked acme file. (Instead of using username and password as described in the linked file)

Use collection manager from https://github.com/ioBroker/webserver

When collections are saved there is a from attribute that holds the adapter name & instance.

On the config status tab, only collections from the current adapter and instance should be shown to avoid confusion.

It would be nice to see the status of each collection in the admin interface. Something that shows:

• Has certificate been ordered and is it good?
• If certificate is valid, when renewal is due?
• If certificate is bad, when the last order was attempted and that order failed?

Etc..?

Where to store this info between runs would be up for debate. Maybe more meta objects for each instance? Or a state for each collection?

Can someone give me a hint, where the adapter stores the received certificate files? Thanks

Is it possible to add support for netcup and KAS? aswell? Its already integrated into acme.sh

https://github.com/acmesh-official/acme.sh/blob/master/dnsapi/dns_netcup.sh
https://github.com/acmesh-official/acme.sh/blob/master/dnsapi/dns_kas.sh

acme.0 | 2023-11-11 20:16:59.464 | debug | ACME: _challenge_select: [object Object]
-- | -- | -- | --
acme.0 | 2023-11-11 20:16:59.464 | debug | ACME: challenge_select: [object Object]
acme.0 | 2023-11-11 20:16:57.976 | debug | ACME: certificate_order: [object Object]

'object Object' does not provide much information. Please consider stringifying the object or log relevant components of object explicitly.

Seems to be logged here:

Adapterversion 0.1.0 + wip (github)

Think about adding version 0.0.2 to stable repository.

Version: stable=0.0.0 (0 days old) => latest=0.0.2 (117 days old)
Installs: stable=0 (0%), latest=14 (77.78%), total=18
Click to edit

@GermanBluefox I think this logic is trying to be too smart for it's own good. I do not like it at all for a number of reasons:

1. It fails on my system here because there is an old web instance running, which uses the old Let's Encrypt method which does not have the listen port defined in port but of course defined in lePort and thus isn't found.
2. There is absolutely no way to guarantee other adapters won't have similar config and be missed. I note, for example, that you changed the name of the port config in this adatper to be port for consistency but that's only because you know about this. It will be very hard to police this. I don't like that you made that change - I prefer verbose names as much as possible for clarity.
3. To avoid the above, if you think users can't be trusted to properly configure ports (see point 5) there really should be a mechanism for port management with a nice API or whatever for adapters to use to check ports, request port release, notify port release, etc, etc. I doubt this is going to happen any time soon (or even ever?).
4. I really do not like the idea of one adapter stopping another like this. There is no safeguard to absolutely guarantee that an adapter would be restarted if ACME crashed.
5. If someone has configured their system to use the same ports for two different adapters then IMHO that is a big mistake. I think the an adapter should fail with the address already in use message so the system owner can find an alternate port.
6. If you absolutely insist that this function should stay (and why would we keep something with all the above issues?) then I think there should be an option to disable it, and if enabled, there should be logging all over that start/stop logic to let a system owner know what's going on. Imagine the frustration of not knowing why an adapter has restarted seemingly randomly.

And the most obvious reason: the challenge server only ever runs on the public facing port 80 (or where that has been forwarded to) which is for insecure HTTP. If one is using ACME that implies they also want to use HTTPS, not HTTP, and therefore would never have anything else running on the same insecure HTTP port anyway!

According to a statemengt form @Apollon77 here ioBroker/ioBroker.admin#1940 (comment) acme needs js-controller 5 to function correctly.

So I suggest to update the dependencies of acme and require js-controller 5.x.x (whatever subversion is required).

This should reduce reporting problems.

Bei mir ist Port 80 in der Fritzbox für ein anderes Gerät im Heimnetz freigegeben. Außerdem nutzt der plenticore Adapter 24/7 den Port.
Beides verhindert aktuell die Verwendung von acme mit LE Cert. Bisher war das unwichtig, aber nun wurde im web Adapter ab v6 der LE Support entfernt und acme erzwungen.

Hier hatte ich ein Teil dazu auch beschrieben #17
Wie kann ich web v6 mit LE Cert über acme nutzen wenn ich das LE Cert nur manuell aktualisieren kann?
Das Problem des belegten Ports durch andere Adapter scheint ebenfalls erst zukünftig gelöst zu werden:

WORK IN PROGRESS
(bluefox) Corrected detection of instances on the same port

English
In my network port 80 is in use for a different hardware device and has completely nothing to do with iobroker. Further more the planticore adapter uses port 80 for communication with the photovoltaik inverter.
Both prevents currently the usage of acme with LE cert. Due to the web adapter v6 forces acme it is a problem.
Currently I have to stay on web v5, even for simplea-api adapter. Because this doesn't support acme and only with web v5 I can renewal my LE cert.

How can I use web v6 with LE cert over acme if I can renewal it only manually?
The issue with used port 80 by other adapter seems to be solved first in future:

WORK IN PROGRESS
(bluefox) Corrected detection of instances on the same port

How do I have to setup acme if port 80 is only open in router (port forwarding) for the moment I will renew the letsencrypt cert every 3 months. The rest of the time port 80 has a forwarding rule for another device at home (nothing in iobroker context).

Furthermore the plenticore adapter has a setting to retrieve data from photovoltaic inverter (local IP:80). This seams to be another issue for acme adapter.

I can't change the port in plenticore settings because the device delivers its data only over this port.

acme Log:

2023-03-23 07:53:09.366 - info: acme.0 (904308) starting. Version 0.0.2 (non-npm: iobroker-community-adapters/ioBroker.acme#881ca8139141522a885d60073ae14d7cb3ef1bab) in /opt/iobroker/node_modules/iobroker.acme, node: v16.19.1, js-controller: 4.0.24
2023-03-23 07:53:09.396 - error: acme.0 (904308) Failed to initiate any challenges
2023-03-23 07:53:09.436 - info: acme.0 (904308) Terminated (ADAPTER_REQUESTED_TERMINATION): Processing complete
2023-03-23 07:56:42.596 - info: acme.0 (904817) starting. Version 0.0.2 (non-npm: iobroker-community-adapters/ioBroker.acme#881ca8139141522a885d60073ae14d7cb3ef1bab) in /opt/iobroker/node_modules/iobroker.acme, node: v16.19.1, js-controller: 4.0.24
2023-03-23 07:56:43.825 - warn: acme.0 (904817) Saved account does not match maintainer email, will recreate.
2023-03-23 07:56:43.825 - info: acme.0 (904817) Registering new ACME account...
2023-03-23 07:56:44.926 - info: acme.0 (904817) Collection letsencrypt does not exist - will create
2023-03-23 07:56:45.559 - error: acme.0 (904817) uncaught exception: listen EADDRINUSE: address already in use 0.0.0.0:80
2023-03-23 07:56:45.561 - error: acme.0 (904817) Error: listen EADDRINUSE: address already in use 0.0.0.0:80
at Server.setupListenHandle [as _listen2] (node:net:1463:16)
at listenInCluster (node:net:1511:12)
at doListen (node:net:1660:7)
at processTicksAndRejections (node:internal/process/task_queues:84:21)
2023-03-23 07:56:45.561 - error: acme.0 (904817) Exception-Code: EADDRINUSE: listen EADDRINUSE: address already in use 0.0.0.0:80
2023-03-23 07:56:45.572 - info: acme.0 (904817) Shutting down challengeServer
2023-03-23 07:56:45.573 - info: acme.0 (904817) terminating
2023-03-23 07:56:45.574 - warn: acme.0 (904817) Terminated (UNCAUGHT_EXCEPTION): Without reason
2023-03-23 07:56:47.052 - error: host.iobroker instance system.adapter.acme.0 terminated with code 6 (UNCAUGHT_EXCEPTION)

`
host.
2023-08-06 12:03:38.804 info instance system.adapter.acme.0 started with pid 673205
host.
2023-08-06 12:03:38.762 info instance scheduled system.adapter.acme.0 0 24 * * *
host.
2023-08-06 12:03:37.684 info stopInstance system.adapter.acme.0 (force=false, process=false)
host.
2023-08-06 12:03:37.684 info "system.adapter.acme.0" disabled
host.
2023-08-06 12:03:36.269 info instance system.adapter.acme.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION)

acme.0
2023-08-06 12:03:36.231 warn Shutdown called but nothing to do

acme.0
2023-08-06 12:03:35.728 info Terminated (ADAPTER_REQUESTED_TERMINATION): Processing complete
host.
2023-08-06 12:03:35.728 info stopInstance system.adapter.acme.0 (force=false, process=true)
host.
2023-08-06 12:03:35.728 info "system.adapter.acme.0" enabled
host.
2023-08-06 12:03:35.098 info stopInstance system.adapter.acme.0 (force=false, process=true)
host.
2023-08-06 12:03:35.098 info "system.adapter.acme.0" disabled

acme.0
2023-08-06 12:03:35.042 info starting. Version 0.1.0 in /opt/iobroker/node_modules/iobroker.acme, node: v18.17.0, js-controller: 5.0.11
host.
2023-08-06 12:03:34.356 info instance system.adapter.acme.0 started with pid 673190
host.
2023-08-06 12:03:34.314 info instance scheduled system.adapter.acme.0 0 24 * * *
`

Reproduce this error by disabling HTTP challenge and trying to use DNS-01 with Cloudflare.

Looks like challenge is initialised by somehow not being passed to ACME create correctly.