>> So we have recently implemented the pem based storage options, but in >> the passed we pushed people to use the truststore configuration >> instead: >> >> http://docs.puppetlabs.com/puppetdb/1.5/configure.html#truststore >> >> This forced a user to create a traditional JKS store and put their CA >> certificates in that. I haven't tested it, but this probably accepts >> multiple CA certificates. Have you tried this yet? I would need to run >> up a test myself to do this, if this sounds sort of like what you are >> after happy to help. I'm not positive it works - but this feels like >> the way to do it for now. >> >> If it doesn't work, we can work towards solving it properly, but going >> forward, the ability to specify multiple ca certificates for the >> ssl-ca-cert setting sounds like another viable option: >> http://docs.puppetlabs.com/puppetdb/1.5/configure.html#ssl-ca-cert > > > So, I didn't have any problems setting up the puppetdb to use the CA we want > to use (and we have puppet defines that take care of requesting the certs > from certmaster, installing them, etc.). I'm actually using puppetdb behind > apache (reverse proxy to non-ssl port) since I prefer not to mess with > keystores when I can help it, but I am pretty confident we'd have no problem > using the JKS approach either if we were serving the SSL directly from > Jetty. (We have lots of puppet manifest to help with managing JKS stores > for other Java apps we run.) > > My problem is with puppetmaster trying to talk to puppetdb. The cert verify > is failed. Trying to grep through puppet code, it looks like it adds the > $ssldir/certs/ca.pem file as the [only] valid authority for the https > connections. I tried pasting more certs into that file -- looking at > Net::HTTP ruby module for reference it says ca_file can include multiple > certs. But still getting the permission denied error. Maybe it is using > the /var/lib/puppet/ssl/certs/ca.pem instead of > /var/lib/puppetmaster/ssl/certs/ca.pem? (This is a puppet-managed > puppetmaster so we have two trees.) Anyway, I will continue poking at it. > I have no idea if changing the contents of certs/ca.pem is going to break > signing.
So I think I understand, what you are saying is that the client refuses to accept the PuppetDB's server certificate, because its not signed by its own CA? This is not a client certificate thing, my point is - purely server side certs. Right? Because your PuppetDB's server cert is signed with a more global different CA, it doesn't work yeah? > Yeah, we'll see. This doesn't look promising. > > It would be really nice if there was a way to say "hey, puppet[master] for > your outbound https connections, here's a ca-bundle.pem you can use to > verify servers". The idea that we'd use the puppetmaster CA *seems* wrong > here. Especially in an environment like ours where we have many (dozens) of > puppetmasters that each manage their own little ecosystems. (And we don't > really want to force a single CA.) Yeah, its wrong in your multi-CA scenario for sure. We totally just use the HTTP libraries Puppet provides us and all its cert assumptions, for simplicity I guess. At least, it works for single-CA scenarios just fine. We could look into providing a feature for this probably. The change would probably need to occur in the puppetdb-terminus code and an option added to /etc/puppet/puppetdb.conf most probably. Although if Puppet itself supported multiple CA bundles, this wouldn't happen - I think the fix is more elegant in Puppet as all clients/termini/plugins using their HTTP libraries would just work for multi-ca without each one having to do its own thing. ken. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAE4bNTkFsn27S2%2B7seKevFrVvrgTrEEAZFK_m1ofkoB-0gn5cg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
