Long time, no update to this RFC. Given it’s been 3 years, and I have been thinking on this topic again. We previously had extensive discussion and ideas on how to tackle this problem. Some of the ideas we implemented and simplified, others felt hard to go from where we are today to that future.
This update to the RFC is aimed at defining a set of high level goals to target regarding how we generate, manage and think about the certificates used when operating Foreman, Katello and related services. I believe it is valuable to align Foreman and Katello certificate expectations, remove technical debt and open up the ability for users to provide Katello based installations with full certificate infrastructure if they desire. In order to do this I believe we need to tease apart layer by layer in order to make sure we do not de-stabilize a user’s install by forcing re-deployment of certificates.
That being said, I believe as long as we protect existing installations, and the CA certificate and key we can consider more radical approaches if they get us to a better future faster tha what I propose below.
#1 - Remove katello-certs-tool
The katello-certs-tool project is old, and full of both outdated methods (e.g. using nsCertType) and large chunk of unused functionality. The code is hard to read and understand.
Proposal: Eliminate the use of katello-certs-tool under the hood of puppet-certs via a refactor and instead rely on native methods using openssl directly via abstractions from puppet-openssl. This is presented here.
#2 - Separate generation from deployment
Today Katello uses puppet-certs to generate certificates in /root/ssl-build and handles the deployment and management of those certificates to locations for use by services.
Proposal: Add certificate deployment to the appropriate service modules and remove the deployment handling code from puppet-certs.
#3 - Define required certificates and locations
Currently Foreman defaults to using puppet certificates or allows a user to present them as inputs. Katello relies in puppet-certs to put certificates in various locations that are inconsistent across services.
Proposal: This comes in two parts. The first is to clearly define the set of certificates required and naming conventions that clearly identify them (e.g. apache.crt). The second part is to define a pattern and location for each set of certificates for a given service (e.g. /etc/foreman/pki, /etc/httpd/pki).
#4 - Remove generation from core installer execution
For Katello the generation of a default set of certificates happens within the puppet modules and thus core installer execution. This tightly couples the generation of the default set of certificates with installation making it hard to cleanly provide your own certificates.
Proposal: Remove generation from within the puppet modules and instead make it a step that happens within installer hooks prior to the core installation run. Users can either provide their own certificates or the installer will generate a default set of certificates.