[pve-devel] RFC for ACME DNS Challenge

[Fabian Grünbichler]

so this got a bit longer than expected - just a high-level feedback, I 
haven't actually tested anything yet since there are too many open 
general design questions for that to make sense.

On October 14, 2019 1:08 pm, Wolfgang Link wrote:
> This series also includes a new GIT repository on proxdev.
> The path is staff/wl/pve-acme.

please send those as patches as well for the next iteration - otherwise 
how are we supposed to discuss them here? some quick notes anyway:

- don't set permissions via patches (do we really need that? those files 
  are either unused or just sourced, not directly executed?)
- use debian/patches, not manual patching via Makefile

do we really need to package all of acme.sh? wouldn't a short stub with 
the following methods be enough (note: this is for ALL plugins, if we 
just want to support a subset this list would probably get smaller):

implemented:

_base64
_dbase64
_digest
_contains
_egrep_o
_endswith
_exists
_get
_post
_inithttp (depending on implementation of _get/_post)
_getfield
_head_n
_tail_n
_hex_dump
_hmac
_idn
_is_idn
_lower_case
_math
_normalizeJson
_sed_i
_sleep
_stat
_time
_url_encode
_utc_date

stubbed/aliased:
__green
__red
_err
_info
_log
_readaccountconf
_readaccountconf_mutable

no-ops:
_clearaccountconf
_cleardomainconf
_debug
_debug2
_debug3
_secure_debug
_secure_debug2
_secure_debug3
_saveaccountconf
_saveaccountconf_mutable
_save_conf
_savedomainconf

if we really go down the 'ship full copy of acme.sh' route, we should:
- not ship it as acme.sh IMHO (to prevent future namespace collisions, 
  e.g. pve-acme-sh-wrapper)
- disable/remove all the commands we don't use (to prevent users from using it)
- not ship the main script in /usr/sbin, but just in /usr/share/...

whether we ship our own wrapper with stubs, or use a patched acme.sh as 
wrapper does not change anything w.r.t. the rest of the series though, 
so we can leave that decision and just discuss the rest for now! it 
would even be possible to switch one way or another in the future 
without much hassle, since there is a single point where our code and 
that wrapper meet.

> 
> The acme_sh project is used as DNS API plugin systems.
> So we can reuse the already defiend plugins.
> I deside to install the complett acme_sh scrips so somwone could use it
> for alternative use.

but the whole reason this series exists is that we want to eliminate the 
need for users to manually setup and use acme.sh instead of our 
integration?

> I'm not sure about where we save the information about the dns_plugin.
> I deside to load it dynamicly like we do with ceph key for the storage.
> Alternative we could save the information in the node config,
> as I already specify in patch manger 6 Add dns_api_config.
> 
> The dns key file is not standiziert so ervery plugin expect other paramerts.
> So I would say the dns key file has to be created from the user manually.

see acme.sh's _read_conf()/_save_conf() - the format is a simple 
key=value, with the latter optionally and transparently base64 
encoded/decoded (although none of the current dnsapi plugins seem to use 
this feature).

see the long comment to pve-common #1

> 
> If someone need a OVH key for testing please contact me.
> 
> Steps to test.
> The api key file must exists on /etc/pve/priv/acme/dns_ovh.cred
> 
> 1.) pvenode acme account register default <mail at example.invalid>
> 2.) pvenode config set --acme domains=test.linksystems.li,plugin=acme_sh
> 3.) pvenode cert order
> 
> These patches are only tested against the OVH API because of missing alternative possibilities.
> 
> There are two bugs in this Series.
> I send it anyway because they are not essential to the genrall functionality
> and this is anyway an RFC and not the final version.
> Known bugs:
> Alias does not work in acme_sh.
> Multiples domains will only use one domain in certivicate.

multiple domain support is pretty central to the rest of the series 
though - see my comments regarding 'plugin' and 'alias' properties in 
node config..