RFC: Using Foreman client certificates for all backend service communication

This RFC can be thought of as a subset of the larger Certificates RFC.

The effort here is being tracked with this Redmine: Tracker #32381: Communication with services from Foreman application should use a single set of client certificates - Installer - Foreman and you can find links to the PRs for the details.


The goal of this RFC is to move from a model of generating client certificates per service that we communicate with to using the Foreman client certificates for all communication. This reduces the need to generate and manage multiple special use certificates simplifying deployments, understanding and overhead.


Candlepin Artemis

A set of dedicated client certificates are generated to communicate with the Artemis service running inside Candlepin. There is RBAC present that restricts access based upon the DN presented with the certificate and is required to be in a specific format. Moving to using the Foreman client certificates primarily revolves around being able to to more dynamically derive the the DN based on the certificate to pass along to the configuration (Refs #32381: Add function to determine the Artemis user string dynamically from th… by ehelms · Pull Request #405 · theforeman/puppet-katello · GitHub).

Pulp 3 API

Pulp 3 API authentication revolves around setting the REMOTE_USER header in Apache and passing that along to the pulpcore-api.service. This header is set based on the CN of the certificate presented. Thus, today we generate a set of dedicated client certificates with a CN of admin. To move to Foreman client certificates, Apache can set the header based on if the certificates CN matches a defined value. Thus we need only to declare what CN to match against. This can be seen with initial work here.

Other services?

I am admittedly most familiar with Pulp and Candlepin and how we build the certificate structure for those services. If there are instances within the community that fit this model that could use work to move to this model please respond to this thread with details and I’ll take a look.


To me the goal is to minimize the number of files that the Foreman user needs to connect. So using the same client certificates for all outgoing connections is a good start. Then we also have the CA files that we use to verify connections.

I started a PR to Katello core, but haven’t had time to finish it.

During that PR I realized that the connection to Pulp can use a different CA file and we don’t have that. However, there is a more generic need for it and this PR would add a setting for it:

That CA is exactly the one that Pulp is on since it’s in the same vhost. For remote Smart Proxies I think we have the constraint that it should be signed by the same CA.

Once it’s merged, we need to modify the installer to set it:

Do you agree that we should include it in the scope?