Re: How to manually create Puppet CA and client certificates using openssl?

[spankt...@gmail.com]

Bumping - no one knows if its possible or isnt it possible at all?

[Felix Frank]

On 02/16/2013 12:20 PM, spankt...@gmail.com wrote:
> after creating CA and client cert and applying them to puppetmaster, it
> complains with:

Wait, what? You create a new CA, even after agents have already been
certified, then create new agent certificates?

If your CA changes, you will have to terminate all the (now deprecated)
agent certificates and sign new certificates for all agents.

Basically, I would expect the outcome you are observing, and you should
just follow the instructions given in your log excerpt. Note that you
are *not* supposed to remove the CA from the master, only the copy of
the agent's certificate.

HTH,
Felix

[spankt...@gmail.com]

Dear Felix,

I think you're getting it wrong, let me clarify it a bit. The goal of this is to be able to write web interface for generating puppetmasters CA's and client certificates on demand. An example: install 3 puppetmasters with loadbalancer in front. Use web interface to generate CA and certificates for chosen clients (lets say, 10 machines). Deploy such generated CA's on puppetmasters, and relevant bits on puppet clients to authorize them against these puppetmasters. Whenever there's need for change, use that CA via web interface to add and delete client certificates, redeploy them on puppetmasters and so on. This, while doable via Subprocess functions (Python is the language of choice for me, but that doesnt really matters) and calls to relevant puppet system commands is extremely ugly and not flexible solution. I would love to do it via openssl library, but to do so, I'd need to have a workable way to build CA's and sign (and revoke) client certs via openssl command - so far I cant reach that goal. I hope this makes more sense now.

Regards,

S.

[Peter Brown]

You might have better luck using something like FreeIPA and using it's ca cert and setting up certs for each node and using those as the puppet certs.

This may help.

http://jcape.name/2012/01/16/using-the-freeipa-pki-with-puppet/

I had a go at setting it up but I am using FreeIPA 3 and the steps need some changing for that so your mileage may vary.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To post to this group, send email to puppet...@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[spankt...@gmail.com]

Thanks Pete, but unfortunately that wont work. The nodes are out of my control, and all I can do is to provide their owners client certs via web gui. In addition to that, I would need multiple CA's, as the clients (and puppetmasters) would be destinated for different owners, and they shouldnt share the CA.

[Felix Frank]

Hi,

I think I understood your goal well enough, and it's sound in and of
itself, but I believe you have some misconceptions on how to implement this.

First off, so we're on the same page: The CA is your root certificate.
It's a self signed certificate shared by all masters. Only the masters
have its private key. They use it to sign all other puppet related
certificates.

A client certificate is generated by a master based on the CA and a
certificate signing request from the agent. It's necessary to either
a) have the CSR generated agent side, so the agent has the private key
generated itself or
b) do all the generating master side and implement a secure way to push
the agent's private key to the agent

Let's cut right to the bottom line: You do *not* want to create new CAs,
ever. You make a CA, make sure its private key is well protected, and
stick with that. If you need deploy aditional masters at various times,
you need a process that will supply them with the CA and its key.

I'm not sure wether you can separate the puppet master from the puppet
ca network-wise, but if it's possible, it would be infinitely simpler to
stick to a monolithic ca server and do only the other agent/master
interaction through loadbalancing.

I believe that your core problem at the moment is private key
management, but that's only a guess.

On 02/19/2013 09:15 PM, spankt...@gmail.com wrote:
> Dear Felix,
>
> I think you're getting it wrong, let me clarify it a bit. The goal of
> this is to be able to write web interface for generating puppetmasters
> CA's and client certificates on demand. An example: install 3
> puppetmasters with loadbalancer in front. Use web interface to generate
> CA and certificates for chosen clients (lets say, 10 machines). Deploy
> such generated CA's on puppetmasters, and relevant bits on puppet
> clients to authorize them against these puppetmasters. Whenever there's
> need for change, use that CA via web interface to add and delete client
> certificates, redeploy them on puppetmasters and so on. This, while
> doable via Subprocess functions (Python is the language of choice for
> me, but that doesnt really matters) and calls to relevant puppet system
> commands is extremely ugly and not flexible solution. I would love to do
> it via openssl library, but to do so, I'd need to have a workable way to
> build CA's and sign (and revoke) client certs via openssl command - so
> far I cant reach that goal. I hope this makes more sense now.
>
> Regards,
> S.
>
> On Tuesday, February 19, 2013 4:04:32 PM UTC, Felix.Frank wrote:
>

[spankt...@gmail.com]

Dear Felix,

On Wednesday, February 20, 2013 9:58:45 AM UTC, Felix.Frank wrote:

Hi,

I think I understood your goal well enough, and it's sound in and of
itself, but I believe you have some misconceptions on how to implement this.

First off, so we're on the same page: The CA is your root certificate.
It's a self signed certificate shared by all masters. Only the masters
have its private key. They use it to sign all other puppet related
certificates.

Correct.

 

A client certificate is generated by a master based on the CA and a
certificate signing request from the agent. It's necessary to either
a) have the CSR generated agent side, so the agent has the private key
generated itself or
b) do all the generating master side and implement a secure way to push
the agent's private key to the agent

The b) is the goal here, correct.

 

Let's cut right to the bottom line: You do *not* want to create new CAs,
ever. You make a CA, make sure its private key is well protected, and
stick with that. If you need deploy aditional masters at various times,
you need a process that will supply them with the CA and its key.

Incorrect. You *do* want to create new CA's. What about different puppetmasters pools? Imagine you and me, we both want a puppetmasters setup with LB's in front of them, for our own machines, and we'd rather want to have different CA's for our puppetmasters.

 

I'm not sure wether you can separate the puppet master from the puppet
ca network-wise, but if it's possible, it would be infinitely simpler to
stick to a monolithic ca server and do only the other agent/master
interaction through loadbalancing.

Dont worry about the details of separation network wise or any other. All I want to do, is to generate complete CA and client certs programatically, using openssl lib - how they're going to be deployed on puppetmasters and puppet clients is out of scope here - it can be via rsync, it can be by embedding CA's into vm images per client base, it can be done in many different ways. A monolithic CA server is out of question, as it becomes a spof.

 

I believe that your core problem at the moment is private key
management, but that's only a guess.

Incorrect, the problem is to emulate puppet ca/cert behavior using openssl command (and then by openssl lib).

[Felix Frank]

On 02/20/2013 11:37 AM, spankt...@gmail.com wrote:
> Incorrect. You *do* want to create new CA's. What about different
> puppetmasters pools? Imagine you and me, we both want a puppetmasters
> setup with LB's in front of them, for our own machines, and we'd rather
> want to have different CA's for our puppetmasters.

Well, so you'd want *your* agents to receive catalogs from *my* puppet
masters?

That's a whole different problem altogether. Each agent node will need
to run several agents, each with their own view of what the CA and the
master certificate is. They could share the agent's private key, but
that would actually add complexity.

Basically, you probably want separate /var/lib/puppet instances on the
agents for each "master pool".

> it can be via rsync

Oh, please don't.

> monolithic CA server is out of question, as it becomes a spof.

Not really, the ca service should not see much use during day-to-day
operation, but again, I may be wrong about this.

> Incorrect, the problem is to emulate puppet ca/cert behavior using
> openssl command (and then by openssl lib).

Ah, only you aren't. The puppet ca service works under the premise that
the client simply generates a CSR for itself and forwards that to the
puppet ca service.

Have you had any success signing the certificate using openssl, when the
CSR originates with the agent (so, as a start, you do step 2 your way?)
Once you have that working, all that's left to do is doing the CSR
generation using openssl, which shouldn't be that hard, either. What's
hard is not doing it on the agent node.

[spankt...@gmail.com]

Dear Felix,

On Wednesday, February 20, 2013 10:51:50 AM UTC, Felix.Frank wrote:

On 02/20/2013 11:37 AM, spankt...@gmail.com wrote:
> Incorrect. You *do* want to create new CA's. What about different
> puppetmasters pools? Imagine you and me, we both want a puppetmasters
> setup with LB's in front of them, for our own machines, and we'd rather
> want to have different CA's for our puppetmasters.

Well, so you'd want *your* agents to receive catalogs from *my* puppet
masters?

No, absolutely not. I need a piece of web based software that would allow you and me generate our own CA's for out own, separate puppetmaster clusters and client certs signed using these CA's. Your CA would be for your puppetmasters and clients only, mine would be for mines. And someone elses would be for him exclusively. The only thing common between your, mine and everyone's else CA's and certs would be the fact they were created and provided by that software.

 

That's a whole different problem altogether. Each agent node will need
to run several agents, each with their own view of what the CA and the
master certificate is. They could share the agent's private key, but
that would actually add complexity.

Basically, you probably want separate /var/lib/puppet instances on the
agents for each "master pool".

> it can be via rsync

Oh, please don't.

If the rsync uses SSH for communication, what's wrong with it? And beside, this was only an example, the CA's and certs could be stored in DB, could be encrypted with PGP, possibilities are endless.

 

> monolithic CA server is out of question, as it becomes a spof.

Not really, the ca service should not see much use during day-to-day
operation, but again, I may be wrong about this.

Regardless of how much use it has, it is a spof. Once it's down, whole cluster malfunctiones. With monolithic CA server down, all clusters are malfunctioning.

 

> Incorrect, the problem is to emulate puppet ca/cert behavior using
> openssl command (and then by openssl lib).

Ah, only you aren't. The puppet ca service works under the premise that
the client simply generates a CSR for itself and forwards that to the
puppet ca service.

Have you had any success signing the certificate using openssl, when the
CSR originates with the agent (so, as a start, you do step 2 your way?)
Once you have that working, all that's left to do is doing the CSR
generation using openssl, which shouldn't be that hard, either. What's
hard is not doing it on the agent node.

No, so far I've complete failure. I tried to do it the Mozilla way, from the link included in original post, but it fails and I cant find out why. 

[Felix Frank]

On 02/20/2013 12:02 PM, spankt...@gmail.com wrote:
>
> Regardless of how much use it has, it is a spof. Once it's down, whole
> cluster malfunctiones. With monolithic CA server down, all clusters are
> malfunctioning.

I disagree. An SSL connection requires two peers and at least one signed
certificate. The client needs to trust the issuer's certificate, but it
needs not contact a ca server to re-validate that certificate for each
connection.

A downtime of the CA service would merely imply that you cannot sign any
new certificates for the time being.

> Have you had any success signing the certificate using openssl, when
> the
> CSR originates with the agent (so, as a start, you do step 2 your way?)
> Once you have that working, all that's left to do is doing the CSR
> generation using openssl, which shouldn't be that hard, either. What's
> hard is not doing it on the agent node.
>
>
> No, so far I've complete failure. I tried to do it the Mozilla way, from
> the link included in original post, but it fails and I cant find out why.

I only just looked at that. Lots of script work I won't dive into.

I advise to do this bottom up:

1. Set up a plain old puppet master the usual way, make it work with an
agent

2. Once that works, add another agent, but don't "puppet ca sign" its
certificate but instead use an openssl invocation. Place the signed
certificate in the appropriate location on the master host. The agent
should receive it during its next connection.

3. Once that works, generate a CSR on yet a new agent using openssl, put
the files in the appropriate locations in /var/lib/puppet/ssl and do an
agent run. It should send your CSR to the master. Repeat step 2.

4. Once that works, you're basically there. Doing step 3 on the master
node and transferring the files should not be too different.

[spankt...@gmail.com]

On Wednesday, February 20, 2013 12:00:07 PM UTC, Felix.Frank wrote:

On 02/20/2013 12:02 PM, spankt...@gmail.com wrote:
>
> Regardless of how much use it has, it is a spof. Once it's down, whole
> cluster malfunctiones. With monolithic CA server down, all clusters are
> malfunctioning.

I disagree. An SSL connection requires two peers and at least one signed
certificate. The client needs to trust the issuer's certificate, but it
needs not contact a ca server to re-validate that certificate for each
connection.

A downtime of the CA service would merely imply that you cannot sign any
new certificates for the time being.

And that's already too much. The whole point of this is to avoid spof's of any kind and be able to create redundant, highly available Puppet infrastructure. Unfortunately, I cant accept single CA server.

 

>     Have you had any success signing the certificate using openssl, when
>     the
>     CSR originates with the agent (so, as a start, you do step 2 your way?)
>     Once you have that working, all that's left to do is doing the CSR
>     generation using openssl, which shouldn't be that hard, either. What's
>     hard is not doing it on the agent node.
>
>
> No, so far I've complete failure. I tried to do it the Mozilla way, from
> the link included in original post, but it fails and I cant find out why.

I only just looked at that. Lots of script work I won't dive into.

I advise to do this bottom up:

1. Set up a plain old puppet master the usual way, make it work with an
agent

2. Once that works, add another agent, but don't "puppet ca sign" its
certificate but instead use an openssl invocation. Place the signed
certificate in the appropriate location on the master host. The agent
should receive it during its next connection.

3. Once that works, generate a CSR on yet a new agent using openssl, put
the files in the appropriate locations in /var/lib/puppet/ssl and do an
agent run. It should send your CSR to the master. Repeat step 2.

4. Once that works, you're basically there. Doing step 3 on the master
node and transferring the files should not be too different.

And what would be the purpose of that? That still includes using puppet to create CA, and I want to avoid that completely. What the ideal workflow would like is:

1. Puppetmaster's vm's are being booted. No CA nor cert actions taken.

2. User goes to web app, click's 'generate CA' - CA gets generated.

3. User provides node names to generate - CA generated in 2. is being used to generate and sign these.

4. User downloads all files neccessary to place on his puppet nodes.

5. CA and client certs are being placed on vm's booted in 1.

6. User can now use his nodes without any certificate actions required to talk to puppetmasters behind the loadbalancer. 

[Felix Frank]

On 02/20/2013 01:28 PM, spankt...@gmail.com wrote:
> And what would be the purpose of that? That still includes using puppet
> to create CA, and I want to avoid that completely.

Ah, right. I forgot step 5. Which is replacing the CA with one created
using openssl. Of course, all other certs are obsolete after you do
that, so you can use your shiny new process of certifying agents to make
them new ones.

> 1. Puppetmaster's vm's are being booted. No CA nor cert actions taken.
>
> 2. User goes to web app, click's 'generate CA' - CA gets generated.

A simpler alternative might be:
1a. User creates puppetmaster vm for a new pool, that bootstraps itself
with a CA certificate
1b. User adds a puppetmaster vm to an existing pool, by cloning another VM

That way, you need not even implement a frontend for generating CAs on
the fly.

[Felix Frank]

Hi again,

to answer the question more succinctly: The purpose of the proposed
process is to find and eliminate the points of failure.

Once you've completed all those iterations, you will very well know what
works and how.

Cheers,
Felix

[spankt...@gmail.com]

On Wednesday, February 20, 2013 12:58:44 PM UTC, Felix.Frank wrote:

On 02/20/2013 01:28 PM, spankt...@gmail.com wrote:
> And what would be the purpose of that? That still includes using puppet
> to create CA, and I want to avoid that completely.

Ah, right. I forgot step 5. Which is replacing the CA with one created
using openssl. Of course, all other certs are obsolete after you do
that, so you can use your shiny new process of certifying agents to make
them new ones.

Great, except I tried that and failed, therefore this thread ;) I was hoping someone was doing something like that already and know if its possible, and if it is, how to do it properly.

 

> 1. Puppetmaster's vm's are being booted. No CA nor cert actions taken.
>
> 2. User goes to web app, click's 'generate CA' - CA gets generated.

A simpler alternative might be:
1a. User creates puppetmaster vm for a new pool, that bootstraps itself
with a CA certificate
1b. User adds a puppetmaster vm to an existing pool, by cloning another VM

That way, you need not even implement a frontend for generating CAs on
the fly.

That's an interesting and tempting perspective, although I have two issues with it:

a) it would require user to know what is he doing with puppet ca/certs, and one of the purposes of the web app is to make user's life, and entire process as easy as possible

b) I would lost control over how many nodes user could add using that CA, something that would have been applied in the application logic

[Felix Frank]

On 02/20/2013 02:38 PM, spankt...@gmail.com wrote:
> Ah, right. I forgot step 5. Which is replacing the CA with one created
> using openssl. Of course, all other certs are obsolete after you do
> that, so you can use your shiny new process of certifying agents to
> make
> them new ones.
>
>
> Great, except I tried that and failed, therefore this thread ;) I was
> hoping someone was doing something like that already and know if its
> possible, and if it is, how to do it properly.

Well, I disbelieve this has been done, because the way you are proposing
to model puppet architecture sounds pretty unique.

As I understood, you tried to do steps 1 through 5 in one, which failed.
I can think of quite some ways this would happen. Therefor the baby steps.

HTH,
Felix

[Jason Slagle]

Howdy!

I might suggest starting here:

http://projects.puppetlabs.com/projects/1/wiki/certificates_and_security


It talks a little about setting up a seperate CA - this is pretty
commonly done for HA environments.

As far as pre-generating the client certs without Puppet, I'd have a
look at ssl/host.rb in the source tree to see how it does it. It has
all the logic puppet certificate --generate uses (It seems to call
generate_certificate_request), and then the logic --sign uses which
calls ca.sign. If you look through that code I'm sure you can figure
out the right options to pass openssl to do it.

Jason

[Matthew Black]

I think you're trying to over complicate the situation here.

Yes its a single point of failure but unfortunately that is not going
to change anytime between now and maybe 6 months.

You do not need multiple CAs to use multiple puppet masters. The
client needs to have the setting ca_server set to the Puppet Master
that is the CA. You need to configure that Puppet master with ca =
true. The puppet masters you create need to be configured with ca =
false. You can have 300 different puppet masters and each client can
connect to the different ones as needed.

If you need to limit which clients can connect to which puppet masters
then you should look at the auth.conf file.

As for a web interface around certificate signing, when each client
connects into the CA it will submit its request and if autosign is
turned off it should be setup to wait for certificate. The web
interface can be a wrapper around the puppet cert face so you can get
a list of certificates signed and whats waiting to be signed. You can
even set it up to revoke or clean out a certificate. You do not need
to call to the command line to do this either, you can interface with
the puppet api from rubygems.

[spankt...@gmail.com]

Dear Matt,

On Wednesday, February 20, 2013 5:41:11 PM UTC, Matt wrote:

I think you're trying to over complicate the situation here.

Yes its a single point of failure but unfortunately that is not going
to change anytime between now and maybe 6 months.

I am aware of that, and I am fine with that.

 

You do not need multiple CAs to use multiple puppet masters. The
client needs to have the setting ca_server set to the Puppet Master
that is the CA. You need to configure that Puppet master with ca =
true. The puppet masters you create need to be configured with ca =
false. You can have 300 different puppet masters and each client can
connect to the different ones as needed.

The thing is, the puppetmasters are exposed to puppet clients via loadbalancer, so they actually appear as one puppetmaster, therefore, they all need to have the same CA installed.

 

If you need to limit which clients can connect to which puppet masters
then you should look at the auth.conf file.

As for a web interface around certificate signing, when each client
connects into the CA it will submit its request and if autosign is
turned off it should be setup to wait for certificate. The web
interface can be a wrapper around the puppet cert face so you can get
a list of certificates signed and whats waiting to be signed. You can
even set it up to revoke or clean out a certificate. You do not need
to call to the command line to do this either, you can interface with
the puppet api from rubygems.

That, again, would require running puppetmaster per user, something I really, really want to avoid.

[Matthew Black]

I run an F5 load balancer with SSL termination at the F5 and I dont
need to put the CA cert anywhere except the F5. The actual CA signs
the certs. The CA cert is only really used to authenticate the client
cert. This gives the appearance to my puppet clients that I only have
one puppet master when in actuality I have around 4-5 per VIP.

As for your last part I'm not really seeing how you think you would
need a puppetmaster per user.

[spankt...@gmail.com]

Dear Matt,

On Wednesday, February 20, 2013 10:39:51 PM UTC, Matt wrote:

I run an F5 load balancer with SSL termination at the F5 and I dont
need to put the CA cert anywhere except the F5. The actual CA signs
the certs. The CA cert is only really used to authenticate the client
cert. This gives the appearance to my puppet clients that I only have
one puppet master when in actuality I have around 4-5 per VIP.

Unfortunately, I dont have F5 available and all I can have is software based load balancing, either in form of Haproxy (most probably) or Nginx (less probably).

 

As for your last part I'm not really seeing how you think you would
need a puppetmaster per user.

As one puppetmaster can use one CA at a time to sign/revoke certificates, if you'd have multiple users, you would need multiple puppetmasters, to be sure that two (or more) users can use different CA's at the same time to sign/revoke their certs. Using openssl library and multiple instances of web app makes that possible, if using openssl to create CA's and signing/revoking certs is possible in first place.

[Matthew Black]

I think you're missing what I'm trying to convey. When you run via
Apache or Nginx you are doing SSL termination at the apache and
forwarding the requests to a puppetmaster application if you use say
passenger. Its not so different than an F5. While I'm not giving you
exact details on how to do it I'm giving you enough information to
know its possible.

The value of ca_server defaults to "puppet", that means the
certificate of the server it connects to must have that name in the
cert and the DNS must match. When you start up the first puppet
master, the CA server and not with mod_passenger, it will
auto-generate the CA cert because the value of ca defaults to true if
its not otherwise specified in the puppet conf.

Essentially each puppet master that isnt the CA server is basically
just a puppet client meaning when it does its first run it will
generate a key, csr, and then try to connect to "puppet". You dont
actually need a cert for a puppet master if you do the ssl termination
at the load balancer. I provided a copy of my apache conf used for a
puppetmaster. As long as the puppetmasterd rack is installed it will
function as a puppetmaster with that config.

You need to generate a signed certificate from the CA for the load
balancer dns. Lets say your DNS for one pool is
puppetpool01.example.com, that is the cert name you need to generate
and install on the apache/nginx load balancer. You need to also
configure the load balancer to validate the ssl cert from the client
against the CA. Specific parameters need to be passed to puppet, which
is specified in the apache conf below. In each puppet master that is
load balanced in its conf file in the master section you need to put
these two lines

ssl_client_header = SSL_CLIENT_S_DN
ssl_client_verify_header = SSL_CLIENT_VERIFY

You want to go the mod_passenger route then you can do ssl termination
otherwise to do the tcp proxy is a real pain in the ass (been there,
done that, never again).

Below is an example of my apache conf where the communication is
unencrypted because of the ssl termination at the load balancer.

As long as the cert on the load balancer is signed by the CA and you
set it up to pass the correct headers if the SSL cert is validated
against the CA then you do not need multiple CA's.

That way this setup you can revoke a certificate from one place
instead of trying to figure out which CA you need to revoke it from.
In each of my datacenters I have at the very minimum two F5 VIPs that
go to 4 different puppet masters each with one common CA. I have at
the current moment 6 datacenters, meaning I have 25 puppetmasters (24
servers, 1 CA).

Hopefully this clarifies the point I am conveying. I know my apache
configs, specifically for mod_passenger, might need tweaking but this
actually works really good. Also if you pick up one of the puppet
books, I forget which one exactly, they actually tell you how do the
proxying with apache in a similar fashion to what I explained.

#####
Apache Conf
#####

Listen 18140

PassengerHighPerformance on
PassengerMaxPoolSize 12
PassengerPoolIdleTime 30
PassengerMaxRequests 10
PassengerStatThrottleRate 120
PassengerUseGlobalQueue on
RackAutoDetect On
RailsAutoDetect On
<VirtualHost *:18140>
ServerName ppm001.example.com
DocumentRoot /usr/share/puppet/rack/puppetmasterd/public/
RackBaseURI /
<Directory /usr/share/puppet/rack/puppetmasterd/public/>
Options None
AllowOverride None
Order allow,deny
allow from all
</Directory>
SetEnvIf X-SSL-Subject "(.*)" SSL_CLIENT_S_DN=$1
SetEnvIf X-Client-Verify "(.*)" SSL_CLIENT_VERIFY=$1
SetEnvIf X-Forwarded-For "(.*)" REMOTE_ADDR=$1
SetEnvIf X-Forwarded-Proto "https" HTTPS=1

LogLevel error
ErrorLog "|/usr/sbin/cronolog
/var/log/httpd/puppetmaster_error_log.%Y%m%d -l
/var/log/httpd/puppetmaster_error_log"
CustomLog "|/usr/sbin/cronolog
/var/log/httpd/puppetmaster_access_log.%Y%m%d -l
/var/log/httpd/puppetmaster_access_log" combined
</VirtualHost>
#####

[Matthew Black]

Oh and to add to my message. The benefit of this is there is no
tomfoolery with multiple CAs and the confusion that will cause. If the
concern is about letting one puppet client connect to two different
pools then you can limit who can retrieve their catalog either through
the auth.conf or directives via apache/nginx directives.

The only time a new CA would be required is if you cant isolate via
auth.conf or apache/ngnix and that would depend on the topology of
your network. If you are concerned with a rogue server then you have
autosign off then this is less of a issue because you actually have to
authorize, by signing the certificate, the client to connect to any
puppet master/pool signed by the CA.