debops / ansible-pki

Bootstrap and manage internal PKI, Certificate Authorities and OpenSSL/GnuTLS certificates
GNU General Public License v3.0
65 stars 29 forks source link

Changing config parameters has not effect #109

Open htgoebel opened 7 years ago

htgoebel commented 7 years ago

Changeing parameters for ACME has no effect.

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 commented 7 years ago

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 https://github.com/debops/ansible-pki/issues/110.

htgoebel commented 7 years ago

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.