Details
-
Bug
-
Status: Closed
-
Normal
-
Resolution: Fixed
-
SERVER 1.0.2
-
None
-
2
-
Server Emerald 2015-03-18, Server Emerald 2015-04-01
Description
Puppet Server likely isn't handling the use of the cacert / localcacert settings correctly in two cases:
1) The retrieve-ca-cert! function in certificate_authority.clj unconditionally copies the file at the "cacert" setting to the file at the "localcacert" setting.
If a pre-existing file were located at the "localcacert" location, that file would be overwritten from the content of the file at the "cacert" location. This approach would be problematic if a user were to have intended to load multiple CA certificates into the file at the "localcacert" location - e.g., to allow clients issued from different CAs to access the master - since the file at the "cacert" location would presumably only have the CA service's certificate and not the other allowed CA certificates.
Instead, it would seem better for this logic to only copy the file if the file at the "localcacert" location did not already exist.
2) Via the init-webserver! function in puppet_server_config_core.clj, the value of the "cacert" setting from puppet.conf is propagated up to the webserver in the event that no value for "ssl-ca-cert" is present in the webserver configuration.
Assuming that the "cacert" setting is intended to denote the location where the Puppet Server CA service obtains its own certificate, it would seem more appropriate for the init-webserver! function to use the "localcacert" setting to populate the list of CA certificates that the webserver would use to validate clients.
------
From the comments below, I pulled up these items to be covered in the work for this ticket:
1) Change the implementation of retrieve-ca-cert! in certificate_authority.clj to not copy the cacert over the top of the localcacert if there's already a file at the localcacert location.
This would avoid the problem of the user's "external CA" cert possibly being stomped by the Puppet CA service if the "external CA" cert happened to be populated before the Puppet Server were started and the Puppet CA were still enabled as the master tries to retrieve the CA cert during initialization. This doesn't solve the issue of the Puppet CA going ahead and initializing its own certs, which isn't ultimately what the user wants to have happen.
2) Change the init-webserver! function in puppet_server_config_core.clj to, for the case that Jetty webserver ssl settings are being overridden from core Ruby Puppet settings, override the Jetty webserver ssl-ca-cert setting with the core Ruby Puppet localcacert setting.
Risk assesment: High (automated test needed)
Probability: Medium-High; Users have encountered issues already for this.
Severity: Medium. If a user brings up a puppet CA on a master where the user wanted to use an external puppet CA, the local CA will stomp on the certificate from the external CA.
Attachments
Issue Links
- relates to
-
SERVER-346 More surgical update of hostcrl from cacrl setting
-
- Closed
-
-
SERVER-498 Need to create some documentation for "remote Puppet CA" configuration
-
- Closed
-
-
SERVER-500 Consider failing Puppet Server startup if localcacert but no CA files exist at startup
-
- Closed
-
- links to