Fixes #34667 - Add SSL support when connecting to mqtt broker #75
Conversation
|
Is it worth adding the setting to the example config? |
Use of SSL can be forced either way by explicitly setting mqtt_tls setting. If unset, it gets used if certificate, private key and CA certificate are available. Currently it reuses the ssl_* set of certs smart proxy has.
|
@ehelms care to weigh in? My CA knowledge on Foreman infra is about zero so can't judge this too much. |
| :ssl => settings.mqtt_tls, | ||
| :cert_file => ::Proxy::SETTINGS.ssl_certificate, | ||
| :key_file => ::Proxy::SETTINGS.ssl_private_key, | ||
| :ca_file => ::Proxy::SETTINGS.ssl_ca_file, |
There was a problem hiding this comment.
I have been thinking about certificates and this raises a good question: should we use the smart-proxy server certificates or the foreman client certificates (:foreman_ssl_ca, :foreman_ssl_cert, :foreman_ssl_key) to talk to mosquitto?
A few things to consider with this.
- In a standard Foreman installation, this should be all Puppet certificates so it doesn't really matter.
- In a standard Katello installation, this should be all certificates from the default CA so it doesn't really matter.
And then there is the dragon scenarios:
- If the user provides custom server certificates in the Katello scenario:
a) the smart-proxy server certificates will be the custom certificates and mosquitto will need to be configured with the CA of those certificates to accept them.
b) the smart-proxy Foreman client certificates will be from the default CA and if used, mosquitto would need to be configured with the default CA
That leads in to what certificates should we configure mosquitto with: ones derived only from the default CA or the same server certificates running the smart-proxy?
Foreman has a similar scenario if the user is using Puppet certificates but has opted to provide the smart-proxy with server certificates from a different CA.
@ekohl @evgeni your thoughts are appreciated, apologies for any headaches this may cause
There was a problem hiding this comment.
This is one of the headaches I already had (thanks to a very special tree).
Either Mosquitto or Go's TLS stack was very picky about which certificate was used where, based on flags present. So using the non-client cert didn't work and "solved" the selection for me.
There was a problem hiding this comment.
Switched to client certs
|
Anything else to do here? |
| @@ -60,6 +60,10 @@ def validate_mqtt_settings! | |||
|
|
|||
| raise 'mqtt_broker has to be set when pull-mqtt mode is used' if Plugin.settings.mqtt_broker.nil? | |||
| raise 'mqtt_port has to be set when pull-mqtt mode is used' if Plugin.settings.mqtt_port.nil? | |||
|
|
|||
| if Plugin.settings.mqtt_tls.nil? | |||
| Plugin.settings.mqtt_tls = [:ssl_certificate, :ssl_private_key, :ssl_ca_file].all? { |key| ::Proxy::SETTINGS[key] } | |||
There was a problem hiding this comment.
I think this line needs updating with change to client certificates.
|
|
||
| # Use of SSL can be forced either way by explicitly setting mqtt_tls setting. If | ||
| # unset, SSL gets used if smart-proxy's ssl_certificate, ssl_private_key and | ||
| # ssl_ca_file settings are set available. |
There was a problem hiding this comment.
Does this also need updating if using client certificates?
|
Thank you everyone! |
Use of SSL can be forced either way by explicitly setting
mqtt_tlssetting. If unset, it gets used if certificate, private key and CAcertificate are available. Currently it reuses the
ssl_*set of certs smart proxy has.