Design: Document for discussion and planning of certificate handling redesign

[ehelms]

I thought I would try this method for communicating the design and technical Roadmap of certificate redesign work I am undertaking. I am trying to achieve larger design goals through small, incremental changes and realize that the steps I envision in my head may not be obvious to those reviewing the incoming work.

Thus, I am trying out a pull request with design document that will remain in draft status. I do not intend to merge this ever. I intend this to serve as a communication and reference as well as a place for discussions of key points through the ability to comment on specific lines.

I am sure I missed something that will come out through discussion. I have learned a lot about how all the current code works so if there is an area that is not super clear, or you'd like a deeper exposition of how a part of it works today I'll add that.

[ekohl]

I'm not entirely use we need separate types for certificate and private_key. We can consider using https://github.com/voxpupuli/puppet-openssl as well but I think we'll find out along the way what works best.

Overall I agree with the plan. If we keep ssl-build we should also consider moving it to /var/lib because /root is a bad place for it.

[ekohl]

Suggested change

Services almost always need to set some level of ownership on certificates in order to consume them at runtime. This can be as simple as user and group. The certificates used by a service are also often co-located within a directory owned by that service. This creates dependency cycles and burdens when trying to manage the certificates from within puppet-certs. For example, puppet-candlepin needs to install Candlepinand ensure the tomcat user and group exists, as well as the `/etc/candlepin/certs` directory in order for puppet-certs to set the owner and group on the certificates. And, puppet-candlepin needs puppet-certs to have created and deployed the certificates with those correct ownerships before the service can be started.

Services almost always need to set some level of ownership on certificates in order to consume them at runtime. This can be as simple as user and group. The certificates used by a service are also often co-located within a directory owned by that service. This creates dependency cycles and burdens when trying to manage the certificates from within puppet-certs. For example, puppet-candlepin needs to install Candlepin and ensure the tomcat user and group exists, as well as the `/etc/candlepin/certs` directory in order for puppet-certs to set the owner and group on the certificates. And, puppet-candlepin needs puppet-certs to have created and deployed the certificates with those correct ownerships before the service can be started.

[ehelms]

I'm not entirely use we need separate types for certificate and private_key. We can consider using https://github.com/voxpupuli/puppet-openssl as well but I think we'll find out along the way what works best.

Take a look at what I added to #348 and my comments at the end. I think this all comes down to how much we want to create an abstraction and how much we want to try to add some 'verifications'.