Bug 1294959

Satellite lets you use your own CAs today, which should fullfill this request.

This issue has not been fixed yet. Currently, we can configure custom certs only for apache module.

~~~~
[root@satellite63 ~]# for port in 9090 8008 8140 443 5000 8443 5646 5647 5671 ; do      echo  $port: ;     openssl s_client -connect localhost:$port -showcerts -no_ign_eof < /dev/null 2>/dev/null |         openssl x509 -noout -subject -issuer;     done
9090:
subject= /C=IN/ST=MH/L=PNQ/O=RedHatSatellite/CN=satellite63.sat6.gsslab.pnq.redhat.com/OU=SatelliteOU
issuer= /C=IN/ST=MH/L=Pune/O=RedHat/CN=amar.root-ca-authority.com/OU=Satellite
8008:
subject= /C=IN/ST=MH/L=PNQ/O=RedHatSatellite/CN=satellite63.sat6.gsslab.pnq.redhat.com/OU=SatelliteOU
issuer= /C=IN/ST=MH/L=Pune/O=RedHat/CN=amar.root-ca-authority.com/OU=Satellite
8140:
subject= /CN=satellite63.sat6.gsslab.pnq.redhat.com
issuer= /CN=Puppet CA: satellite63.sat6.gsslab.pnq.redhat.com
443:
subject= /C=IN/ST=MH/L=PNQ/O=RedHatSatellite/CN=satellite63.sat6.gsslab.pnq.redhat.com/OU=SatelliteOU
issuer= /C=IN/ST=MH/L=Pune/O=RedHat/CN=amar.root-ca-authority.com/OU=Satellite
5000:
subject= /C=IN/ST=MH/L=PNQ/O=RedHatSatellite/CN=satellite63.sat6.gsslab.pnq.redhat.com/OU=SatelliteOU
issuer= /C=IN/ST=MH/L=Pune/O=RedHat/CN=amar.root-ca-authority.com/OU=Satellite
8443:
subject= /C=US/ST=North Carolina/O=Katello/OU=SomeOrgUnit/CN=satellite63.sat6.gsslab.pnq.redhat.com
issuer= /C=US/ST=North Carolina/L=Raleigh/O=Katello/OU=SomeOrgUnit/CN=satellite63.sat6.gsslab.pnq.redhat.com
5646:
subject= /C=US/ST=North Carolina/O=dispatch server/OU=SomeOrgUnit/CN=satellite63.sat6.gsslab.pnq.redhat.com
issuer= /C=US/ST=North Carolina/L=Raleigh/O=Katello/OU=SomeOrgUnit/CN=satellite63.sat6.gsslab.pnq.redhat.com
5647:
subject= /C=US/ST=North Carolina/O=dispatch server/OU=SomeOrgUnit/CN=satellite63.sat6.gsslab.pnq.redhat.com
issuer= /C=US/ST=North Carolina/L=Raleigh/O=Katello/OU=SomeOrgUnit/CN=satellite63.sat6.gsslab.pnq.redhat.com
5671:
subject= /C=US/ST=North Carolina/O=pulp/OU=SomeOrgUnit/CN=satellite63.sat6.gsslab.pnq.redhat.com
issuer= /C=US/ST=North Carolina/L=Raleigh/O=Katello/OU=SomeOrgUnit/CN=satellite63.sat6.gsslab.pnq.redhat.com
~~~~

The certificate handling part of our installer and supporting scripts, such as those to generate Capsule certificate bundles, rely upon the core idea that certificates are being generated as needed. The number of services running and requiring certificates, and sometimes in slightly different formats (e.g. Java pkcs12 keystores, nssdb) makes replacing them whole sale painful in the current implementation. Our certificate handling is predicated on the idea that certificates can be generated for each of the services needing certificates, and then wrapped in RPMs, installed on the system and then handled by puppet from there. When a Capsule needs to come online, a set of certificates is generated for all Capsule services needing certs and wrapped in a tarball for distribution.

The custom certificate support today exists due to user requests to use certificates generated using their in-house CA so that their browsers would automatically trust the UI. The rest of the certificates are thought of as a set of "infrastructure" certificates for components to talk to one another.

Candlepin has the largest certificate requirement in that it needs a CA 
certificate in order to generate new client certificates during each 
host registration event as well as for subscriptions consumed per host. 
Users would need to either provide their top-level CA cert and **key** 
or have a subordinate CA generated for use by the Satellite system and 
it's components. This puts a significant amount of authority to rest 
within the Satellite as it would become a system authorized to generate 
certificates under the customer's Certificate Authority. This has 
generally been seen as a show-stopper for granting Satellite the rights 
to act as a signer.

Attempting to replace each certificate on the system by hand is a recipe for disaster. Upgrades would wipe out any changes made on every run. Supporting custom certificates for all services is something that would need to be done within the bones of our installer and certificate handling. This is not impossible, but it is not a trivial amount of work.

Are there any updates on this? Our security team is requesting an update on what the current status is for using custom certificates for internal components that require SSL.

The support of user supplied certificates for component communication with Satellite is being considered and designed with intent for Satellite 7 support.

The Satellite Team is attempting to provide an accurate backlog of bugzilla requests which we feel will be resolved in the next few releases. We do not believe this bugzilla will meet that criteria, and have plans to close it out in 1 month. This is not a reflection on the validity of the request, but a reflection of the many priorities for the product. If you have any concerns about this, feel free to contact Red Hat Technical Support or your account team. If we do not hear from you, we will close this bug out. Thank you.

Hello Team, 
I have a customer who wants to replace self-signed certificates with Custom SSL certificates.
the case No is: 02762024
Do we have any resolution?

Best Regards, 

Hunter

Satellite is required to be a CA in order to issue client certificates to clients so they can access Satellites services. In order for Satellite to stop using self-signed certs internally, the customer would have to provide either a root CA or an Intermediate CA to enable Satellite to issue certificates from that. After doing some customer outreach, our gut feeling is that the majority of customers would not be able to give Satellite a root or intermediate CA from their organisations trusted CA, therefor I'm closing this.

If this is not the case for you and you are willing to provide a root or intermediate CA to Satellite, please take a look at BZ 1898091