Deploy server CA certificate for smart-proxy rather than default #396
Conversation
The smart-proxy can be deployed with user-supplied certificates and thus needs the CA certificate for those. However, the smart-proxy also expects to receive communication from clients whose certificates are generated by the default CA. This changes to deploy a chain CA certificate with both present.
ehelms
force-pushed
the
smart-proxy-server-ca
branch
from
9aa7f6f
to
75c690f
Compare
| owner => $owner, | ||
| group => $group, | ||
| mode => '0440', | ||
| require => File[$default_ca_cert], | ||
| require => File[$server_ca_cert], |
There was a problem hiding this comment.
This require is a bit odd. Wouldn't it be on the individual fragments? I'm not sure if it does that automatically (I'm guessing not) so be sure to check that.
|
Yeah, that feels wrong, only Katello CA (or equivalent) should be used for auth, IMHO. |
|
Fair enough, I think I was hoping we could have less certificates and more re-use but mosquitto looks like it will just need to have its own set of deployed certificates to handle communication from smart-proxy and clients. |
|
I still don't exactly understand why Mosquito would need both? |
|
Just a quick thought: it's possible to present a full chain in the certificate file and not use a separate CA file. We can also consider such an approach. I don't know how our tooling handles it today, but it's not uncommon. |
Let's start with the basics. The Katello installation scenario allows for supplying custom certificates (ones not created by the default CA) from the user so that the public facing sites present a certificate from the users CA provider. The primary location for these to get deployed is Apache, but we also deploy them to the smart-proxy.
For the entire lifecycle, at least from looking back at code, of the custom certificates feature (~7-8 years), we have been deploying the user's custom certificate and private key for the smart-proxy service to use but have been deploying the default CA instead of the CA that signed the server certificates. I think this is generally speaking an incorrect behavior - and things have managed to just work for years now.
As soon as we try to correct this, we will notice certain client based workflows will not work anymore. For example, if a Katello client signed by the default CA presents it's certificates to the smart-proxy for remote execution and REX uses the smart-proxy CA to verify them it will now fail.
This plays a role in how we think about deploying something new like mosquitto (see theforeman/puppet-foreman_proxy#726) where if we want to re-use the hostname certificates we also need a combined CA certificate so that clients connecting with Katello certificates can do so.
This change opts to deploy both CA certificates as a chain file.