/var/log/foreman/production.log Failed to save: Unable to communicate with the proxy: ERF12-2530 [ProxyAPI::ProxyException]: Unable to detect features ([OpenSSL::SSL::SSLError]: SSL_connect returned=1 errno=0 state=unknown state: sslv3 alert unsupported certificate) for proxy https://xxxxx:8443/features, Please check the proxy is configured and running on the host.
Problem is solved.
I have too generate new certifcate with correct CN (Commonname = hostname).
Extensions -> TLS Web Server Authentication, TLS Web Client Authentication
Keylength i took 2048 instead 4096.
In general I’d avoid using public certificates for the internal communication. Using your own CA and only allowing that is the first level of security. The second is checking names (trusted_hosts in the settings). A third party CA removes one layer of security.
Note that the Foreman server can serve (and use) different certificates from those it uses for connecting to smart proxies.
You are right about the layer of security you remove in this way, I was wondering because I can simply deploy public certs as proxiest that don’t do Puppet Server related stuff don’t have a puppet user anymore since puppet 4 aio so you cannot relax the puppet certs easily for proxy usage and a public cert would have fixed that but indeed removes a layer of security.
Or should the foreman-installer be used for this (puppet user creation) ?
If you already have a puppet infrastructure, then you can still use those certificates on the server. Even if the proxy isn’t a puppet server. When you pass in --foreman-proxy-puppet false --foreman-proxy-puppetca false it doesn’t install the puppet and puppet ca modules. By default it will then create a puppet group and change the permissions on the certificates so the foreman-proxy user can read them. If you pass in --foreman-proxy-manage-puppet-group false you’re on your own.