[SERVER-895] SSL configuration with intermediate CA Created: 2014/08/13  Updated: 2018/06/08  Resolved: 2018/06/08

Status: Closed
Project: Puppet Server
Component/s: None
Affects Version/s: None
Fix Version/s: SERVER 6.0.0

Type: New Feature Priority: Normal
Reporter: Kaitlin Carter Assignee: Unassigned
Resolution: Duplicate Votes: 2
Labels: Server
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relates to PUP-3788 Puppet Agent does not support Chained... Closed
Epic Link: Future Work for Intermediate CA Improvements
Team: Froyo
Story Points: 3
CS Priority: Normal
CS Frequency: 2 - 5-25% of Customers
CS Severity: 3 - Serious
CS Business Value: 4 - $$$$$
CS Impact: This is a common ask from customers, especially those which are very security conscious. While this is possible today it's very difficult and as far as we know not a tested, documented, or supported configuration for PE.

It should be made a supported configuration and also a requirement for any rewrite of the current Puppet CA.
QA Contact: Erik Dasher


Puppet should support a CA configuration where an external CA would issue an intermediate CA for puppet CA server. Puppet then will use that intermediate CA to issue certificates the same way it does by default with it's own self-signed certificate.

Comment by Vadym Chepkov [ 2014/08/13 ]

I have requested this feature so I will comment.
We have a corporate CA and the company policy is to not have self-signed certificates and have all certificates to be derived from corporate CA. Having puppet's CA as an intermediate CA would service this purpose.

Comment by Vadym Chepkov [ 2014/10/11 ]

Ticket is still in need information state.
Do you still need me to provide additional information? I have tried to resolve it myself, but wasn't successful so far. Thanks

Comment by Eric Sorenson [ 2015/09/15 ]

Hi, so I've investigated this with a number of people's help, who I'll tag here to keep me honest – Erik Dasher, Stan Duffy, Jeremy Barlow.

This isn't currently supported but there is a path to supportability inside the Clojure CA, which is why I've moved the ticket to the SERVER project rather than PUP. There are a couple of related issues, primarily PUP-3788, which need fixing along with it, but the primary problem is that support for the use of External CAs with Puppet assume that if you're using an outside CA, you're using it for issuance in addition to chain-of-trust.

The request here is for a use-case that is sort of a hybrid: an external chain-of-trust but issuance from Puppet, and that's not something that we've built into the docs, testing and validation, or the cert issuance code. But I totally understand the rationale for it and agree that it makes a lot of sense to support, especially given corporate security requirements for organizations that want to assert greater audit controls over their PKI.

We are planning another iteration of the CA work in 2016, which will consolidate the certificate subsystem onto the new Clojure CA, provide new command-line tooling, and fix other edge cases like duplicate serial numbers being issued. I've added this ticket to the backlog for that work and will ensure that it's part of the functional requirements that we address.

Comment by Eric Sorenson [ 2016/05/22 ]

I got this configuration working, with a couple of caveats. I documented my process and the results on this gist:


It'd be great if someone could independently verify the results; the main barrier to setup is that you need a "proper" issuing CA to create you an intermediate signing certificate, but this was pretty easy to do for Glenn Sarti with the Windows Certificate Service.

Comment by Karen Van der Veer [ 2017/08/22 ]

Adrien Thebo This needs more work before starting on it, correct?

Comment by Adrien Thebo [ 2017/08/23 ]

It would help to get a list of requirements for this feature - such as, does Puppetserver have to support full chain revocation checking, is leaf checking sufficient, or can we skip revocation checking entirely? (Right now Puppetserver says it supports CRL bundles but it doesn't - the actual code paths require that CRL files contain a single PEM.) In addition do we have to support CA cert bundle distribution? Do we need to provide a way to bootstrap the intermediate CA - such as have Puppetserver or Puppet emit a CSR for the intermediate CA and have a command for receiving the generated certificate, or can we rely on people copying the right files to the right location?

Right now we can make some judgement calls on what should be implemented but it would be helpful to have a more specific list of needs so we don't over/undershoot the requirements.

Comment by Charles Taylor [ 2017/11/19 ]

The only reason I can see for having Puppet Server able to issue chain-complete certificates is so that one can use the Puppet Agent certificate for generic services such as HTTPS, MQTT, RabbitMQ, FTPS, etc. With these uses in mind, then the Puppet system only requires minimal alteration.

  • The Puppet Server needs to serve up a complete certificate chain when https://$ca_server:$ca_port/v1/certificate/ca is queried. (That is, the complete content of the $ssldir/certs/ca.pem file, not just whatever subset it deems worthy.) This is because the complete chain will be needed by all those services, plus it simplifies the Puppet Agent's internal certificate verification. This eliminates the need to manually distribute the ca.pem file as a workaround if it is anything besides a self-signed certificate.
  • The Puppet Agent needs only verify that the certificate used by the Puppet Server was signed by the same intermediate certificate as its own. The Puppet system is basically flat, with the agents talking to the servers. So long as a single certificate, be it a top-level CA (as in the default configuration) or an intermediate CA, signed both the server and client end certificates, the Puppet system will function as expected.
  • The Puppet Agent needs to be modified to simply perform certificate revocation checking through the existing Puppet Server facility. It should only check for certificate revocation by the Puppet Server's certificate signing system. No higher checking is needed. Why? Because: 1. The rest of the chain will be checked by those other services. 2. This provides an equivalent level of protection to the standard, self-signed Puppet configuration. 3. If your Puppet Server's certificate is compromised then the network is already compromised and revoking it will happen too late to save the Puppet Agents. This eliminates the need to use the "certificate_revocation = false" configuration statement workaround on Puppet Agents if anything besides a self-signed certificate is being used on the Puppet Server.
  • Puppet Server needs to make its CRL available at the URL specified in the certificates it signs, or accept a URL in its configuration where the administrator can host the CRL. This way those other services can provide proper revocation checking themselves. This is optional for the initial deployment, but should be done eventually.

These relatively simple changes should allow the Puppet system to function as designed, while adding simple support for those additional services. Puppet is 90% there already, as this can actually be achieved now, albeit only with the couple workarounds mentioned above. Why not take it the rest of the way?

Comment by Maggie Dreyer [ 2018/06/08 ]

This is being fixed via SERVER-2171.

Generated at Sat Jul 11 10:36:42 PDT 2020 using Jira 8.5.2#805002-sha1:a66f9354b9e12ac788984e5d84669c903a370049.