Subject Alternate Names for Puppet SSL

[Peter Berghold]

Is there a more up to date process for this process than this page?

https://docs.puppetlabs.com/guides/scaling_multiple_masters.html

I followed this process and now have a dead puppet.  Glad I made backups of the SSL directory.

What I'm trying to accomplish is due to a architecture that was forced upon me I have to have two names for each of the masters I'm running in my environment such that 

host.domain.tld

host-eth1.domain.tld 

will work..  The second entry is needed to make sure agents connect to the correct interface on the puppet master. 

Thoughts anybody?

[Christopher Wood]

Which option did you take? I picked the load balancer option with a single CA (worked for me), so I needed:

0) configure puppet.conf on the agent hosts

server = lbname.me.com
ca_server = capm.me.com

1) Subject Alternative Name certs on the puppetmasters

First agent run (on pm1.me.com) using:

puppet agent --no-daemonize --onetime --dns_alt_names=lbname.me.com

Then on the CA puppetmaster:

puppet cert sign --allow-dns-alt-names pm.me.com

In your situation I would probably have my provisioning system (razor, cobbler, etc.) provision /etc/puppet/puppet.conf with "dns-alt-names = host-eth1.me.com" and use a shell script wrapper to always include the --allow-dns-alt-names so that I didn't have to remember it when signing certs.

Now obviously nobody asked you about this infrastructure, but have you explained that connecting to the correct interface is more about routing and dns than ssl? And since you're asking for thoughts, you could pass on my opinion that somebody is making this into far more work than it has to be. ("Some guy on the internet who claims to do puppet things for work thinks this is daft.")

On Thu, Apr 16, 2015 at 03:13:26PM +0000, Peter Berghold wrote:
> Is there a more up to date process for this process than this page?

> [1]https://docs.puppetlabs.com/guides/scaling_multiple_masters.html

> I followed this process and now have a dead puppet.  Glad I made backups
> of the SSL directory.
> What I'm trying to accomplish is due to a architecture that was forced
> upon me I have to have two names for each of the masters I'm running in my
> environment such that 
> host.domain.tld
> host-eth1.domain.tld 
> will work..  The second entry is needed to make sure agents connect to the
> correct interface on the puppet master. 
> Thoughts anybody?
>

> --
> 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 [2]puppet-users...@googlegroups.com.
> To view this discussion on the web visit
> [3]https://groups.google.com/d/msgid/puppet-users/CAArvnv04afhj6w90jJoYN3idzT42Aw5ZkSocH_Uh%2B_4MzQj3WA%40mail.gmail.com.
> For more options, visit [4]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. https://docs.puppetlabs.com/guides/scaling_multiple_masters.html
> 2. mailto:puppet-users...@googlegroups.com
> 3. https://groups.google.com/d/msgid/puppet-users/CAArvnv04afhj6w90jJoYN3idzT42Aw5ZkSocH_Uh%2B_4MzQj3WA%40mail.gmail.com?utm_medium=email&utm_source=footer
> 4. https://groups.google.com/d/optout

[Peter Berghold]

Where I'm having the issue is on my master.  

To generate and sign a cert for the master I ran:

 puppet cert generate {hostname}.domain.tld  --allow-dns-alt-names  --dns_alt_names={hostname}.domain.tld,{hostname}-eth1.domain.tld,{hostname}.sub.domain.tld ,{hostname}-eth1.sub.domain.tld

substituting {hostname} for the real hostname of the host

                  domain.tld   for the real domain name

              sub.domain.tld  for a sub-domain that a client might use 

What I'm seeing happening is when running the puppet agent against itself I get the following errors:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to submit 'replace facts' command for {hostname}.domain.tld to PuppetDB at {hostname}.domain.tld:8081: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [unable to get local issuer certificate for /CN={hostname}.domain.tld]

Warning: Not using cache on failed catalog

Error: Could not retrieve catalog; skipping run

This after stopping and restarting both the puppetmaster and puppetdb services. 

I decided to poke a bit further and found if I ran openssl verfiy on the certificate for the puppet master I got 

{hostname}.domain.tld.pem: CN = {hostname}.domain.tld

error 20 at 0 depth lookup:unable to get local issuer certificate

however if I do  openssl verify specifying a CA cert things look good.

{hostname}.domain.tld.pem  OK

So where do I go from here?   I"m certain this has been solved before. 

[Peter Berghold]

On Thu, Apr 16, 2015 at 11:59 AM Christopher Wood <christop...@pobox.com> wrote:

Now obviously nobody asked you about this infrastructure, but have you explained that connecting to the correct interface is more about routing and dns than ssl? And since you're asking for thoughts, you could pass on my opinion that somebody is making this into far more work than it has to be. ("Some guy on the internet who claims to do puppet things for work thinks this is daft.")

I've already vented on this subject with the folks I'm doing all this work for. My (hopefully temporary) fix for this so far has been to play /etc/hosts games which I'm not happy with.  It works, but obviously not the right way to do things.

 

[Christopher Wood]

On Thu, Apr 16, 2015 at 04:23:40PM +0000, Peter Berghold wrote:
> Where I'm having the issue is on my master.  
>
> To generate and sign a cert for the master I ran:
>  puppet cert generate {hostname}.domain.tld  --allow-dns-alt-names
>  --dns_alt_names={hostname}.domain.tld,{hostname}-eth1.domain.tld,{hostname}.sub.domain.tld
> ,{hostname}-eth1.sub.domain.tld
> substituting {hostname} for the real hostname of the host
>                   domain.tld   for the real domain name
>               sub.domain.tld  for a sub-domain that a client might use 
> What I'm seeing happening is when running the puppet agent against itself
> I get the following errors:
> Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
> Failed to submit 'replace facts' command for {hostname}.domain.tld to
> PuppetDB at {hostname}.domain.tld:8081: SSL_connect returned=1 errno=0
> state=SSLv3 read server certificate B: certificate verify failed: [unable
> to get local issuer certificate for /CN={hostname}.domain.tld]

This means that the puppetmaster's cert isn't signed by any ca cert known to the agent, to my recollection.

I haven't specifically had your issue, but in my "bootstrap a new environment" (from scratch/git) document I have this sentence for the first puppet apply: "This run will have some errors due to how there is no CA certificate to be used in the mcollective server configuration for this node given how the CA doesn't exist yet. So we run it again!"

In the first "puppet apply" the agent or master haven't started yet so the neither host cert nor ca cert are created yet. I am going somewhere with this; maybe you can take advantage of how the master will (?) use cert parameters from puppet.conf to kick off the initial signing.

> Warning: Not using cache on failed catalog
> Error: Could not retrieve catalog; skipping run
> This after stopping and restarting both the puppetmaster and puppetdb
> services. 
> I decided to poke a bit further and found if I ran openssl verfiy on the
> certificate for the puppet master I got 
> {hostname}.domain.tld.pem: CN = {hostname}.domain.tld
> error 20 at 0 depth lookup:unable to get local issuer certificate
> however if I do  openssl verify specifying a CA cert things look good.
> {hostname}.domain.tld.pem  OK
> So where do I go from here?   I"m certain this has been solved before. 

I cheated. I submitted a cert request from another host with all my puppetmaster SANs and then manually copied it into place in all my puppetmasters (not that many). So pm-ca1 has /var/lib/puppet/ssl/certs/pmca1.me.com.pem, pm-worker1 has /var/lib/puppet/ssl/certs/pm-worker1.me.com.pem, etc., which are the same by md5sum. I was in a hurry, anyway all hosts are presenting a CA-signed cert.

Now that I know more about the process I might experiment to see if I could do this more legitimately. What follows is unproven rhubarbing.

----------------------------------------
----------------------------------------
----------------------------------------
I would take the following steps (all on the CA puppetmaster, assuming you have no other nodes built yet) and see how it goes. I could be wrong about any or all of this.

I have the following assumptions:

/etc/puppet/puppet.conf is your puppetmaster's config
you have "ca = true" in your puppetmaster's config
you have no other nodes built yet

https://docs.puppetlabs.com/references/3.stable/configuration.html

0) halt all puppet-related daemons

1) remove /var/lib/puppet/ssl (nuking your CA and agent's ssl config)

2) add your SANs to puppet.conf under the master section

dns_alt_names = {hostname}.domain.tld,{hostname}-eth1.domain.tld,{hostname}.sub.domain.tld,{hostname}-eth1.sub.domain.tld

(Maybe have to fiddle with this, does it go here or under another section?)

3) start your puppetmaster

I suspect it will create the CA, then submit the request but not sign it given how 'puppet cert sign' won't sign a SAN cert by default.

4) manually sign the cert

puppet cert sign --allow-dns-alt-names yourcert.you.com

5) might have to restart the puppetmaster to get it to pick up its new cert

If the puppetmaster couldn't auto-sign its own cert the daemon may have bombed.
----------------------------------------
----------------------------------------
----------------------------------------

End untested rhubarbing! If it doesn't work, remember, you got it on the internet for free.

>
> --
> 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 [1]puppet-users...@googlegroups.com.

> To view this discussion on the web visit

> [2]https://groups.google.com/d/msgid/puppet-users/CAArvnv38S%2BrK5qNvdpV0ZengYBk0ZWF_cnkNCUPNSTnk0cA82g%40mail.gmail.com.
> For more options, visit [3]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:puppet-users...@googlegroups.com
> 2. https://groups.google.com/d/msgid/puppet-users/CAArvnv38S%2BrK5qNvdpV0ZengYBk0ZWF_cnkNCUPNSTnk0cA82g%40mail.gmail.com?utm_medium=email&utm_source=footer
> 3. https://groups.google.com/d/optout