Changing config parameters has not effect

[htgoebel]

Changeing parameters for ACME has no effect.

• Changing acme-subject, acme_domains, acme_subdomains or acme_alt_names has no effect, since these values is passed to the server only in Create new PKI realms - which is only run if /etc/pki/realms/{{ item.name }}/default.key not yet exists.

• Changing acme_subdomains has no effect at all, since this is never passed over to the script pki-realm.

• Changing acme_ca, acme_ca_api, acme_default_subdomains or acme_challenge_dir has no effect, since these values is passed to the server only in Initialize PKI realms – which is only run if /etc/pki/realms/{{ item.name }}/config/realm.conf not yet exists.

• Even after rm default.key config/realm.conf acme/error.log the file acme/request.pem is not re-created with new values.

I assume this effects other pki configuration parameters, too.

Workaround: rm default.key config/realm.conf acme/error.log acme/request.pem

Example playbook:

---
- hosts: myacmehost
  become: True
  vars:
      secret_directories:
      - '{{ pki_env_secret_directories }}'
  roles:
    - { role: debops.pki/env}
    - { role: debops.secret }
    - { role: debops.pki }
    - { role: debops.nginx }

Example config (ansible/inventory/host_vars/myacmehost.yml)

pki_acme: True
pki_acme_install: True
pki_acme_ca: 'le-staging' # for testing
_hostnames_:
  - share.example.com
  - cloud.example.com
pki_host_realms:
 - name: 'some-realm'
   acme: True
   domains: '{{ _hostnames_ }}'
   acme_domains: '{{ _hostnames_ }}'
   acme_default_subdomains: []

[drybjed]

At the moment the PKI scripts are designed to not expect any changes in the realm configuration. You cannot modify an existing X.509 certificate without creating a new one, so the role doesn't even try. I suppose that this could be changed when a proper Python rewrite is done.

At the moment the easiest way to handle changes is to remove the entire PKI realm from the host. It will be recreated on the next role run, since all data required (including custom private keys/certs, etc.) is supposed to be readily available either via an API or existing on the Ansible Controller. This is also the way to deal with #110.

[htgoebel]

This behavior is okay, but it and the workaround should be documented prominently, esp. also in the ACME section. I wasted several hours tracking this down, since esp. for ACME I'd expect everything to work automatically.