Refactor #14573

Foreman-Proxy Certificate Files

Added by Matthias Thubauville about 6 years ago. Updated almost 4 years ago.

Target version:
Bugzilla link:
Pull request:
Fixed in Releases:
Found in Releases:
Red Hat JIRA:


Hi there,

(I'm not sure if Refactor is the correct tracker, if not please move the issue where it belongs)

I've realized that the puppet-certs module sets (and generates) certificates at /etc/foreman-proxy/ (see

If a user wants to setup a SmartProxy (without using the capsule installer) and follows the Foreman manual (see things will not work.

The reason is, that Foreman uses the existing (and in my opinion: easy to handle) Puppet certificates for the connection to the SmartProxies.

Is there a reason for Katello to use their own certificates for the proxy communication?

I can see two possible solutions:

1) Use the Puppet certificates, unless there is a good reason to use separate certificates.
2) Create a documentation on how to create the required certificate files to connect a smart proxy without using the Puppet certificates. (I will add them here as soon as I have them).

Maybe someone can have a look at the issue.

Thanks a lot,


#1 Updated by Matthias Thubauville about 6 years ago

2) Create a documentation on how to create the required certificate files to connect a smart proxy without using the Puppet certificates. (I will add them here as soon as I have them).

1) Generate the certificates using the capsule-certs-generate

capsule-certs-generate --capsule-fqdn "" --certs-tar "~/" 

2) Use scp to get the following files to the Smart-Proxy: (from the formeman/katello instance)

scp /etc/foreman-proxy/ssl_ca.pem root@$fqdn:/etc/foreman-proxy/ssl/certs/ca.pem
scp /root/ssl-build/$fqdn/$fqdn-foreman-proxy.crt root@$fqdn:/etc/foreman-proxy/ssl/certs/$fqdn-foreman-proxy.crt
scp /root/ssl-build/$fqdn/$fqdn-foreman-proxy.key root@$fqdn:/etc/foreman-proxy/ssl/certs/$fqdn-foreman-proxy.key

3) Make sure the files (on the smart proxy) belong to the foreman-proxy user

chown foreman-proxy:foreman-proxy /etc/foreman-proxy/ssl/certs/ca.pem
chown foreman-proxy:foreman-proxy /etc/foreman-proxy/ssl/certs/
chown foreman-proxy:foreman-proxy /etc/foreman-proxy/ssl/certs/

4) Add the following files to your foreman-proxy settings.yaml

# grep -e ^:ssl /etc/foreman-proxy/settings.yml 
:ssl_ca_file: /etc/foreman-proxy/ssl/certs/ca.pem
:ssl_certificate: /etc/foreman-proxy/ssl/certs/
:ssl_private_key: /etc/foreman-proxy/ssl/private_keys/

5) Restart the service with service foreman-proxy restart

Now you should be able to access the service via https and the port you specified in /etc/foreman-proxy/settings.yml

Can somebody double check the solution if this is correct? (It works, but you can never be sure...)

#2 Updated by Eric Helms about 6 years ago

  • Category set to 83
  • Legacy Backlogs Release (now unused) set to 114

The current Katello setup uses a custom CA and sets the Apache SSL configuration up using that. Thus, we use custom certificates derived from the custom CA for the Smart Proxy so that the server can verify the smart proxy and vice versa. If you used different certificates on the Smart Proxy, you would need to ensure they have each other's CAs configured properly. We are exploring ways to open this up or support this use case more directly. We are also looking at splitting out the certificate requirements for the Web UI and infrastructure pieces (

Your snippet looks generally correct. How are you installing your Smart Proxy?

#3 Updated by Matthias Thubauville about 6 years ago

Hi Eric,

thanks for the explanation.

I followed the instructions given in the Foreman manual:
(Right now I'm not sure whether we use the packages or from source. Does that make a difference in this case?)

Installing a Smart Proxy and connecting/configuring it manually seems more secure to me if I want to connect services which are already existing (in our case an IPA infrastructure).
To be honest: I'm a little afraid the capsule installer might override existing settings. ;)

The Foreman instructions point you to the Puppet SSL configuration ( which does not work in the Katello case.

In general I don't see a problem in using a separate CA, however it would be nice to have it pointed out in the manual somewhere. (e.g. as an alternative path here:

Also available in: Atom PDF