Closed carlalexander closed 8 years ago
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.
Ok, I'll try those options and report back!
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.
Which roles would break?
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:
debops service/pki --tags role::pki:secret
secret/
debops
command normally as neededThis way, the debops.pki
role should get the provided private keys and certificates immediately, and that will most likely make other roles work correctly.
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.
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.
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: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
oropenssl
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 likepki_generate_certificates
orpki_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