[pve-devel] RFC for ACME DNS Challenge V2

[Fabian Grünbichler]

some high-level feedback:
- looks much better than previous version already, I think v3 should be 
  the one that makes it :)

- just upgrading triggers the following error on order/renew:

Loading ACME account details
Placing ACME order
Order URL: https://acme-staging-v02.api.letsencrypt.org/acme/order/foobar

Getting authorization details from 'https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/barbaz'
... pending!
can't open '/etc/pve/priv/plugins.cfg' - No such file or directory      ...propagated at /usr/share/perl5/PVE/ACME.pm line 527.
Task can't open '/etc/pve/priv/plugins.cfg' - No such file or directory         ...propagated at /usr/share/perl5/PVE/ACME.pm line 527.

- Touching that file and repeating:

Loading ACME account details
Placing ACME order
Order URL: https://acme-staging-v02.api.letsencrypt.org/acme/order/6085187/82472654

Getting authorization details from 'https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/46773730'
... pending!
Died at /usr/share/perl5/PVE/ACME.pm line 527.
Task Died at /usr/share/perl5/PVE/ACME.pm line 527.

what's at line 527?

527    die if $plugin_type eq "standalone";

die without a message ;) also, "standalone" is the (implicit) default, 
so this whole die is probably very wrong?

removing it, and adding a standalone plugin definition to 
/etc/pve/priv/plugins.conf and /etc/pve/local/config seems to work, but 
this needs to be fixed else ALL the configs out there break on upgrade.

it's probably a good idea to just always define a 'standalone: default', 
similar to the always defined local storage, and then use that as 
default plugin id when going from NodeConfig -> ACME if no explicit one 
is defined.

- some more detailed comments as replies to individual patches, a mix of 
  design/architecture improvements and concrete stuff

On March 31, 2020 12:08 pm, Wolfgang Link wrote:
> The acme_sh project is used as a DNS API plugin system.
> So we can reuse the already defiend plugins.
> I add it as a submodule.
> 
> The acme.sh script is replaced by proxmox-acme,
> which contains the function required to operate the DNSAPI plug-ins.
> 
> The login information is saved in the file plugin.cfg
> and passt directly on the proxmox-acme.
> 
> The DNSAPI plugin credentials are not standardized, so each plugin expects different parameters.
> 
> These patches are only tested against the OVH API because of missing alternative possibilities.
> 
> This implementation uses the design that we discuss at the pve-devel list.
> It doesn't have much to do with V1.
> 
> Build conflicts arise due to the code movements.
> The prerequisite for this series is the installation of Curl.
> For this series you have to create the deb packages pve-common, pve-cluster and proxmox-acme.
> Then apply these packages and you can now build and install the pve-manager package.
> 
> The GUI is broken at the moment.
> Fixes will follow shortly.
> Old configurations are converted and can be used without any problems.
> The new configuration must be defined via the CLI.
> 
> For the alias mode a CNAME record is needed
> _acme-challenge.<host>.<domain>.<TLD> 	CNAME 	_acme-challenge.<Alias Target>
> 
> Steps to test.
> 
> 1.) pvenode acme account register default <mail at example.invalid>
> 2.) pvenode acme plugin add <dns|standalone> <plugin_id> --data <login information> 
> 3.) pvenode config set --acme domain=<Domain>,plugin=<plugin_id>[,alias=<alias_domain>]
> 4.) pvenode acme cert order
> 
> 
> 
> _______________________________________________
> pve-devel mailing list
> pve-devel at pve.proxmox.com
> https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> 
>