• Integration with ACME/Let's Encrypt

Using certificates and TLS encryption is hard. Let's try to make it easy.

First iteration of debops.pki role was simple - the goal was to create a private key and self-signed certificate on each host managed by it, so that connections to various services could be encrypted by default. It worked, but each host had a self-signed certificate, so hosts would not trust each other without additional work from the user - secure, distributed services available to the cluster were impossible.

debops.pki Mark II was designed to solve above problems.

Ansible Controller became a central Certificate Authority for the cluster, each host generated their own private keys and Certificate Signing Request which was downloaded to the Ansible Controller, signed, and uploaded again. In fact, to make certain services that do not support intermediate CAs, like MySQL, work with TLS certificates, debops.pki supports multiple Root Certificate Authorities and multiple Intermediate Certificates.

Significant effort was made to allow configuration of user-supplied certificates, private keys, managed using separate PKI realms, which allowed to use different sets of certificates for each application and service. To make services more secure, the role generated its own sets of Diffie-Hellman parameters, long before Logjam attack became an issue. To make reinstallation of hosts, contents of /etc/pki/ directory on each host were backed up on the Ansible Controller, which was then able to re-deploy everything to make configuration faster.

debops.pki in its current form has its own set of issues:

• role is very much overengineered at this point. It should be split into multiple roles if it's possible.
• Diffie-Hellman parameter generation created significant delays during creation of new hosts. This issue is now solved by a separate Ansible role.
• Deployment of multiple new hosts might result in an error when Ansible tries to sign multiple certificates at once.
• The PKI realm system is not used at all, default host realm is usually switched to domain realm which provides better domain-wide set of certificates, and forgotten.
• There's no way to manage sets of keys and certificates using Ansible groups, there's only either all hosts on a domain, or each host separately.
• PKI backup system is redundant with other host backup systems, and could be dropped, if DebOps certificate authorities supported certificate management better.
• Default set of certificates is ill-designed, modification of defaults is hard, it could be improved.
• Management of Root Certificate Authorities in each PKI realm is redundant, and could be split into a separate role.

From these issues it seems, that creation of DebOps PKI 3.0 is inevitable.

Here's a set of goals for the next iteration of the PKI:

• Use the Ansible inventory groups to manage different sets of certificates and private keys for groups of hosts, both using files in the secret/pki/ directory, as well as YAML variables to be used with ansible-vault.
• Support both OpenSSL and GnuTLS libraries for clients and servers (GnuTLS certificates are required by some services).