Allow for simpler pki setups

[carlalexander]

This is a bit related to #41. I'm really not that familiar with pki infrastructure and how it's used through out DebOps. I might be asking for something that can't be done.

I'm wondering if there's a way we can make debops.pki do less through configuration. If I look at the WordPress project, we don't seem to need internal certificate authorities, root certificates and all the stuff generated by default. We only need to support two scenarios:

• Upload certificates that someone bought
• Let's Encrypt certificates (not done yet)

99% of the users of the WordPress project will not need a lot of the features of this role. Yet it puts a lot of burden on them that I'd like to remove. I don't want to have to ask them to update bash or openssl if they won't use the internal certificate authorities at all.

Ideally maybe an option like pki_enabled, but just for the internal certificate authority generation stuff. Maybe something like pki_generate_certificates or pki_generate.

I'm also not sure how much of the role or other roles depend on those certificates being present. That said, I'd rather work through those issues in those roles.

Does this make sense? Or am I crazy to ask this lol

[drybjed]

Sure, you can disable the internal CA and certificates, and deployment of external and ACME certificates should still occur. Set in inventory:

pki_internal: False
pki_authorities: []

It might not be everything that needs to be set, but I think that should do the trick. The result should be that the private key and certificate requests is still performed on the remote hosts (Debian, presumably) so ACME requests and overall PKI structure should work there. I'm not sure about pki-authority not working on MacOS X in this case, so that needs to be tested. It could be modified to avoid problematic code if possible.

[carlalexander]

Ok, I'll try those options and report back!

[drybjed]

Ah, I forgot. When you disable internal certificates, you will need to provide some external certificates beforehand, otherwise other roles will most definitely break - support for debops.pki is still enabled in Ansible facts, but certificate files aren't there anymore. This is a bootstrapping issue which internal certificates and internal CA is trying to solve. If you want to disable that, well, there's nothing else the role could do besides generating self-signed certificates on the remote hosts themselves, which is kinda meh.

[carlalexander]

Which roles would break?

[drybjed]

In the common playbook, I imagine that Postfix itself would start fine, but not sure if mail delivery will work. Otherwise, right now no other roles use certificates, but that will most likely change - for example I want to enable encrypted log distribution in debops.rsyslog at some point.

As for other plays and roles, that depends. If it's a service that can be published and accessed on the network, it most likely has support for debops.pki certificates.

In that case I would probably split the deployment into three phases:

• create the required secret directories using debops service/pki --tags role::pki:secret
• put the private keys and certificates in the created directories in secret/
• run debops command normally as needed

This way, the debops.pki role should get the provided private keys and certificates immediately, and that will most likely make other roles work correctly.

[carlalexander]

Changing the two options seems to have done the trick. I don't seem to have found any issues with any of the roles so far. I have still a few more tests to run.

[carlalexander]

This has been working really well so far. Let's Encrypt works fine as well. @drybjed's addition of self-signed certificates also helped a lot. I'm going to close this in favor of specific issues (like #62) as they arise.