ungleich-public/cdist
ungleich-public
/
cdist
7
3
Fork 10
Code Issues 57 Pull Requests 12 Projects Releases Wiki Activity

__letsencrypt_cert rewrite and subtypes, analyse phase #57

New Issue
Open
opened 2021-11-20 11:25:17 +00:00 by ungleich-gitea · 20 comments
ungleich-gitea commented 2021-11-20 11:25:17 +00:00
Owner
Copy Link

facts: currently __letsencrypt_cert is a mess and there are many acme clients.

idea: __letsencrypt_cert should have subtypes for every client with common interface.

clients we should support:

parameters we need:

  • --mail <mail-addr>
  • --domain <domain-name> (multiple)
  • --type <certbot|acme|dehydrated> (default: certbot)
  • --validation <http-01:webroot=/var/www|what-ever:foo-bar>
  • --webroot(-path)? <path-to-webroot> (shorthand for --validation http-01:webroot=/path/to/webroot etc)
  • --extra-args <args> (multiple, pass more specific options to the backend)

--webroot or --validation must be set, because we need validation method.

not sure:

  • --key-path (optional, default is /etc/ssl/private/? not needed by certbot in some cases)
  • --cert-path (optional, default is /etc/ssl/certs/? not needed by certbot in some cases)
  • --pre-renewal-hook (optional, multiple)
  • --deploy-renewal-hook (optional, multiple)
  • --post-renewal-hook (optional, multiple)
  • --server (optional, which server to use, staging or any other acme compatible server)
  • --automatic-renewal (boolean, not needed with some distros/clients)
  • --standalone (boolean, spawns built-in httpd for challange)

if subtype doesn't support hook, then always throw exit 1?

some clients doesn't have hooks, so we have to work round that. definitely pre and post hooks are needed, not sure about deploy.

what else? discuss, propose better parameter names etc.

**facts:** currently `__letsencrypt_cert` is a mess and there are many acme clients. **idea:** `__letsencrypt_cert` should have subtypes for every client with common interface. clients we should support: * https://certbot.eff.org = `__acme_certbot` * https://github.com/acmesh-official/acme.sh = `__acme_sh` * https://github.com/dehydrated-io/dehydrated = `__acme_dehydrated` * ??? * 100% cdist acme client without external client dependency = `__acme_cdist` **parameters we need:** * `--mail <mail-addr>` * `--domain <domain-name>` (multiple) * `--type <certbot|acme|dehydrated>` (default: `certbot`) * `--validation <http-01:webroot=/var/www|what-ever:foo-bar>` * `--webroot(-path)? <path-to-webroot>` (shorthand for `--validation http-01:webroot=/path/to/webroot` etc) * `--extra-args <args>` (multiple, pass more specific options to the backend) `--webroot` or `--validation` must be set, because we need validation method. **not sure:** * `--key-path` (optional, default is `/etc/ssl/private/`? not needed by certbot in some cases) * `--cert-path` (optional, default is `/etc/ssl/certs/`? not needed by certbot in some cases) * `--pre-renewal-hook` (optional, multiple) * `--deploy-renewal-hook` (optional, multiple) * `--post-renewal-hook` (optional, multiple) * `--server` (optional, which server to use, staging or any other acme compatible server) * `--automatic-renewal` (boolean, not needed with some distros/clients) * `--standalone` (boolean, spawns built-in httpd for challange) if subtype doesn't support hook, then always throw `exit 1`? some clients doesn't have hooks, so we have to work round that. definitely pre and post hooks are needed, not sure about deploy. what else? discuss, propose better parameter names etc.
ungleich-gitea commented 2021-11-20 15:32:05 +00:00
Author
Owner
Copy Link

I agree with --type defaulting to certbot. I guess that's what most users would expect.
Users who want a different backend, can just use the --type parameter.

Not sure about the --webroot. --validation http-01:webroot=/var/www?
Maybe --validation should default to standalone mode, what do you think?

I agree with `--type` defaulting to `certbot`. I guess that's what most users would expect. Users who want a different backend, can just use the `--type` parameter. Not sure about the `--webroot`. `--validation http-01:webroot=/var/www`? Maybe `--validation` should default to standalone mode, what do you think?
ungleich-gitea commented 2021-11-20 15:32:06 +00:00
Author
Owner
Copy Link

I'm starting to get annoyed by this, bit me again today - __letsencrypt_cert is somewhat broken and needs to be fixed.

I'll do some priority ordering...

I'm starting to get annoyed by this, bit me again today - `__letsencrypt_cert` is somewhat broken and needs to be fixed. I'll do some priority ordering...
ungleich-gitea commented 2021-11-20 15:32:08 +00:00
Author
Owner
Copy Link

mentioned in merge request !873

mentioned in merge request !873
ungleich-gitea commented 2021-11-20 15:32:09 +00:00
Author
Owner
Copy Link

changed the description

changed the description
ungleich-gitea commented 2021-11-20 15:32:10 +00:00
Author
Owner
Copy Link

changed the description

changed the description
ungleich-gitea commented 2021-11-20 15:32:12 +00:00
Author
Owner
Copy Link

changed the description

changed the description
ungleich-gitea commented 2021-11-20 15:32:13 +00:00
Author
Owner
Copy Link

changed the description

changed the description
ungleich-gitea commented 2021-11-20 15:32:14 +00:00
Author
Owner
Copy Link

changed the description

changed the description
ungleich-gitea commented 2021-11-20 15:32:16 +00:00
Author
Owner
Copy Link

shortest possible working type should be something like this:

__letsencrypt_cert example.com --mail hostmaster@example.com --webroot /var/www

now, how we decide which backend? we don't want too complex heuristics for that.

or maybe just set certbot as default for --type and call it a day. it's official client anyway :)

shortest possible working type should be something like this: ``` __letsencrypt_cert example.com --mail hostmaster@example.com --webroot /var/www ``` now, how we decide which backend? we don't want too complex heuristics for that. or maybe just set `certbot` as default for `--type` and call it a day. it's official client anyway :)
ungleich-gitea commented 2021-11-20 15:32:17 +00:00
Author
Owner
Copy Link

changed the description

changed the description
ungleich-gitea commented 2021-11-20 15:32:18 +00:00
Author
Owner
Copy Link

changed the description

changed the description
ungleich-gitea commented 2021-11-20 15:32:20 +00:00
Author
Owner
Copy Link

changed the description

changed the description
ungleich-gitea commented 2021-11-20 15:32:21 +00:00
Author
Owner
Copy Link

changed the description

changed the description
ungleich-gitea commented 2021-11-20 15:32:22 +00:00
Author
Owner
Copy Link

changed the description

changed the description
ungleich-gitea commented 2021-11-20 15:32:24 +00:00
Author
Owner
Copy Link

changed the description

changed the description
ungleich-gitea commented 2021-11-20 15:32:25 +00:00
Author
Owner
Copy Link

changed the description

changed the description
ungleich-gitea commented 2021-11-20 15:32:26 +00:00
Author
Owner
Copy Link
  1. that looks nice
  2. agree
  3. me neither because I don't use it, but some maybe does
  4. but then again ju can use extra-args for standalone
1. that looks nice 2. agree 3. me neither because I don't use it, but some maybe does 4. but then again ju can use extra-args for standalone
ungleich-gitea commented 2021-11-20 15:32:28 +00:00
Author
Owner
Copy Link

  1. For us, support for different challenge types, i.e. DNS validation, would be really useful since we use Let's Encrypt certificates also for non-internet facing machines.
    Moreover, DNS validation is required for wildcard certificates.

    What do you think about having a --validation parameter that would accept a type and parameters for it?
    e.g.:

    • --validation http-01:webroot=/var/www
    • --validation dns-01:add-script=/etc/getssl/scripts/dns-add.sh,del-script=/etc/getssl/scripts/dns-del.sh
    • --validation alpn-01:dir=/srv/acme

  2. A --type parameter should be available to select a "backend".

  3. I'm not sure about the --standalone parameter as not all ACME clients support a standalone mode.

  4. How about adding an extra-args parameter to pass more specific options to the backend?

1. For us, support for different [challenge types](https://letsencrypt.org/docs/challenge-types/), i.e. DNS validation, would be really useful since we use Let's Encrypt certificates also for non-internet facing machines. Moreover, DNS validation is required for wildcard certificates. What do you think about having a `--validation` parameter that would accept a type and parameters for it? e.g.: * `--validation http-01:webroot=/var/www` * `--validation dns-01:add-script=/etc/getssl/scripts/dns-add.sh,del-script=/etc/getssl/scripts/dns-del.sh` * `--validation alpn-01:dir=/srv/acme` 2. A `--type` parameter should be available to select a "backend". 3. I'm not sure about the `--standalone` parameter as not all ACME clients support a standalone mode. 4. How about adding an `extra-args` parameter to pass more specific options to the backend?
ungleich-gitea commented 2021-11-20 15:32:29 +00:00
Author
Owner
Copy Link

what do we win if we have type with subtypes?

how do we decide in main type which subtype to use?

what's default fallback?

what do we win if we have type with subtypes? how do we decide in main type which subtype to use? what's default fallback?
ungleich-gitea commented 2021-11-20 15:32:30 +00:00
Author
Owner
Copy Link

changed the description

changed the description
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
master
7.0
6.9
py3.10
ander/__package_apt_update_index
haproxy-dualstack
ander/__sed
beta
ander/os_version_debian_sid
evilham-compatibility-fixes
ander/__rsync
__snakeoil_cert
ander/update_readme
__download_improvements
feature/onchange
cleanup/string-formatting
feature/type-relationship-graph
cleanup/ssh-auth-keys-types
__letsencrypt_cert-fix-hooks
bugfix/preos-debug
bugfix/in-script-import
6.8
bugfix/sphinx-docs-build
6.7
cherry-pick-2f433a14
bugfix/make-code-consistent
6.6
regain-py3.2-support
6.5
bugfix/multiple-log-lines
matterbridge
coturn
alpinefix
matrix
new-type/network-interface
feature/process
6.4
feature/info-command
feature/libexec
6.3
preos-plugins-dir-opt
gitlab-ci
6.2
order-dep-fix
6.1
6.0
build/support-pip-from-git
feature/shell-lib
5.1
feature/support-type-deprecation
5.0
feature/python-types
4.11
4.10
shellcheck
4.9
4.8
freebsd-improvements
new-prometheus
key_value-onchange
feature/output_streams
AnotherKamila-patch-1
__letsencrypt_cert-fixes
letsencrypt-cron-fix
4.7
newtype-__letsencrypt_cert
os_explorer_devuan_fix
prometheus-exporter-fixes
daemontools-for-fbsd
type-prometheus-exporter-from-master
prometheus-more-fixes
4.6
4.5
fix-j
steven-backport
4.4
prometheus-fixes
grafana_dashboard
prometheus
daemontools
consul_improvements
feature/trigger
4.3
4.0-pre-not-stable
4.2
4.1
4.0
feature_install_and_preos
3.1
no-dot-cdist
random_dot_cdist
feature_yum_url
feature_files_export
3.0
2.3
2.2
2.1
ssh_callback
2.0
archive_shell_function_approach
1.7
1.6
1.5
1.4
1.3
1.2
1.1
1.0
7.0.0
6.9.8
6.9.7
6.9.6
6.9.5
6.9.4
6.9.3
6.9.2
6.9.1
6.9.0
6.8.0
6.7.0
6.6.0
6.5.6
6.5.5
6.5.4
6.5.3
6.5.2
6.5.1
6.5.0
6.4.0
6.3.0
6.2.0
6.1.1
6.1.0
6.0.4
6.0.3
6.0.2
6.0.1
6.0.0
5.1.3
5.1.2
5.1.1
5.1.0
5.0.2
5.0.1
5.0.0
4.11.1
4.11.0
4.10.11
4.10.10
4.10.9
4.10.8
4.10.7
4.10.6
4.10.5
4.10.4
4.10.3
4.10.2
4.10.1
4.10.0
4.9.1
4.9.0
4.8.4
4.8.3
4.8.2
4.8.1
4.8.0
4.7.3
4.7.2
4.7.1
4.7.0
4.6.1
4.6.0
4.5.0
4.4.4
4.4.3
4.4.2
4.4.1
4.4.0
4.3.2
4.3.1
4.3.0
4.2.2
4.2.1
4.2.0
4.1.0
4.0.0
3.1.13
tn1
3.1.12
3.1.11
3.1.10
3.1.9
3.1.8
3.1.7
3.1.6
4.0.0pre3
3.1.5
3.1.4
3.1.3
3.1.2
3.1.1
3.1.0
4.0.0pre2
3.0.9
3.0.8
3.0.7
3.0.6
3.0.5
3.0.4
3.0.3
4.0.0pre1
3.0.2
3.0.1
3.0.0
2.3.7
2.3.6
2.3.5
2.3.4
2.3.3
2.3.2
2.3.1
2.3.0
2.2.0
2.1.2
2.1.1
2.1.0
2.1.0pre8
2.1.0pre7
2.1.0pre6
2.0.15
2.1.0pre5
2.1.0pre4
2.1.0pre3
2.1.0pre2
2.1.0pre1
2.0.14
2.0.13
2.0.12
2.0.11
2.0.10
2.0.9
2.0.8
2.0.7
2.0.6
2.0.5
2.0.4
2.0.3
2.0.2
2.0.1
2.0.0
1.7.1
1.7.0
1.6.2
1.6.1
1.6.0
1.5.0
1.4.1
1.4.0
1.3.2
1.3.1
1.3.0
1.2.0
1.1.0
1.0.4
1.0.3
1.0.2
1.0.1
1.0.0
0.9.9
0.9.8
0.9.7
0.9.6
0.9.5
0.9.4
0.9.3
0.9.2
0.9.1
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
Labels
Clear labels   
bugfix

   
cleanup

   
discussion

   
documentation

   
doing

   
done

   
feature

   
improvement

   
packaging

   
Stale

   
testing

   
TODO
No Label
bugfix
cleanup
discussion
documentation
doing
done
feature
improvement
packaging
Stale
testing
TODO
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: ungleich-public/cdist#57
No description provided.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?