ACME configuration via GUI

[daviditty]

I'm trying to configure the ACME validation trough the GUI to use a LE certificate, with the cloudflare API.

Everything is configured the same as in my PVE installation, which works fine.

The record is created trough the API, but the validation fails because the verification only waits 5 seconds instead of the 30 settings which I configured and is default.
It looks like a bug, but I have yet to find how to fix it, grepping trough cfg files have not brought me anything.


In short: the Validation Delay setting is not being honored within PBS.

Am I overlooking something?

Thanks,
Randommen

 

[Stoiko Ivanov]

Does it work if you explicitly configure the validation-delay to 30 seconds? - you can do so when editing the plugin in the GUI

 

[daviditty]

Hi @Stoiko Ivanov thanks for your time.

I just tried changing the setting to 30 seconds, after saving and reopening the plugin settings it says "30" in light gray again, if I set it higher, to 60 for example, and check again it says "60" in black.

However, after trying both, It still ignores it and checks it in 5 seconds:
2021-06-28T15:46:21+02:00: Placing ACME order
2021-06-28T15:46:22+02:00: Order URL: https://acme-v02.api.letsencrypt.org/acme/order/126516xxxxxxx736
2021-06-28T15:46:22+02:00: Getting authorization details from 'https://acme-v02.api.letsencrypt.org/acme/authz-v3/1xxxxxxx9'
2021-06-28T15:46:22+02:00: The validation for zeus.xxxx.nl is pending
2021-06-28T15:46:22+02:00: Setting up validation plugin
2021-06-28T15:46:25+02:00: [Mon Jun 28 15:46:25 CEST 2021] Adding record

2021-06-28T15:46:26+02:00: [Mon Jun 28 15:46:26 CEST 2021] Added, OK

2021-06-28T15:46:26+02:00: Triggering validation
2021-06-28T15:46:26+02:00: Sleeping for 5 seconds
2021-06-28T15:46:35+02:00: TASK ERROR: validating challenge 'https://acme-v02.api.letsencrypt.org/acme/chall-v3/1436xxxxxxxA' failed - status: Invalid

Kind regards,
Randommen

 

[Stoiko Ivanov]

could you please share the (redacted):
* /etc/proxmox-backup/node.cfg
* /etc/proxmox-backup/acme/plugins.cfg (remove the 'data' line)

(currently trying to reproduce this here - but can only try so with a local powerdns (which does not need more then the 5 seconds)

In any case the logs are a bit misleading - entering the TXT record and waiting for its propagation happens _before_ the validation is triggered.

 

[daviditty]

Hi @Stoiko Ivanov

I'm running the latest pbs / proxmox version (no-subscription repo), if I check cloudflare DNS at the moment of ordering the certificate, I see the record being created, but 5 seconds seems to be too short.

See the redacted content of the files (with default 30 configured in the GUI:

:~# cat /etc/proxmox-backup/acme/plugins.cfg
dns: cf
        api cf
        data xxxxxxxx

standalone: standalone

:~# cat /etc/proxmox-backup/node.cfg
acme: account=default
acmedomain0: zeus.xxxx.nl,plugin=cf

redacted content with delay of 60 configured:

~# cat /etc/proxmox-backup/acme/plugins.cfg
dns: cf
        api cf
        data xxxxxxx
        validation-delay 60

standalone: standalone

~# cat /etc/proxmox-backup/node.cfg
acme: account=default
acmedomain0: zeus.xxxxx.nl,plugin=cf

So the option is being set correctly, but ignored for some reason, even if set to default.

I already deleted the plugin and recreated it, no luck.

Kind regards,
David

 

[t.lamprecht]

Note that there are two types delays, the plugin internal ones and the one configured via gui/api used only in-between "set" and "verify" callbacks to the plugins' helper.

The internal one is basically chosen by the acme.sh upstream plugin, and if it's too short there, you may want to report it against
https://github.com/acmesh-official/acme.sh

2021-06-28T15:46:35+02:00: TASK ERROR: validating challenge 'https://acme-v02.api.letsencrypt.org/acme/chall-v3/1436xxxxxxxA' failed - status: Invalid

What's shown if you click on that link? The delay here could be a red-herring.

Oh and note that you may want to use the Let's Encrypt staging API until you got that one working OK, as else you may get rate limited for hours/days on that domain after ~5 tries. https://letsencrypt.org/docs/rate-limits/
Once all is working OK you would switch over to the production one and order a "real" trusted cert.

I just tried changing the setting to 30 seconds, after saving and reopening the plugin settings it says "30" in light gray again, if I set it higher, to 60 for example, and check again it says "60" in black.

That's expected as 30s is the default, so if you set it to default 30s it can be just deleted, as that is assumed anyway.

 

[daviditty]

Hi @t.lamprecht

That is the whole problem, the validation-delay set by the GUI / CLI within proxmox is not being honored / passed trough to the plugin,
it is not the internal setting.

I'm aware of the rate limit

{
  "type": "dns-01",
  "status": "invalid",
  "error": {
    "type": "urn:ietf:params:acme:error:unauthorized",
    "detail": "No TXT record found at _acme-challenge.zeus.xxxxxxx.nl",
    "status": 403
  },
  "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/xxxxx/3xxxxxx",
  "token": "xxxxxxxxxxx",
  "validated": "2021-06-28T15:05:08Z"
}

I checked manually, and the record is created and exists, but 5 seconds between waiting for the propagation and verification is just too short, which shouldn't be 5 seconds anyway, as it is 30 seconds default.

Note: this works perfectly fine within PVE, which waits for 30 seconds, as configured.

Good that it is expected behaviour of the setting within the file

 

[t.lamprecht]

Ah, sorry overlooked the PBS part, and yes, this is a bug in PBS, which forgot to honor that setting in the new rust-based helper code. We'll look into it!

 

[Stoiko Ivanov]

I think I managed to reproduce the issue and sent an initial patch to the pbs-devel:
https://lists.proxmox.com/pipermail/pbs-devel/2021-June/003553.html

once this (or an improved version has been applied) the setting should be honored.

Thanks for the report!

 

[t.lamprecht]

FYI, will be tracked under https://bugzilla.proxmox.com/show_bug.cgi?id=3496

 

[daviditty]

Cool!

No problem, glad to help!
Thank you for your time and such a wonderful product @t.lamprecht @Stoiko Ivanov

Looking forward to the patch.