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.
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.
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.