On Friday, May 13, 2016 at 2:57:57 PM UTC-7, Dan Mahoney wrote: > > Hey there puppet-users deinzens. > > One of my puppet agents helpfully reminded me that my root CA cert is due > to expire within a few months, and I'm wondering what the best way to go > about rolling it over would be. > > A lot of my reading suggests something like "burn everything involving > certificates to the ground and start your entire CA infrastructure over > from scorched earth" is an approximation of the way to go. >
Hi Dan, this is a good and timely post. I'm working on some related issues regarding Puppet's CA that may help you out. Your thinking on this is roughly correct -- things are a lot harder than they need to be, but the above advice to nuke everything and start over is both overly simplistic and wrong-headed. Note that my comments here are specifically about the Clojure CA that is included in puppetserver, not the Ruby CA; most things apply to both but the past couple of years of server-side bugfixes and development energy have gone into the Clojure CA, and Puppet 5 will consolidate all the CA-side cert lifecycle onto this codebase. > > From the various looks and reading I've done, this was one of those parts > of puppet that had some serious technical debt involved in authoring it. > > I've likened puppet's SSL config to how I might manage an SSL cert on my > webserver/clients, and I'm seeing a disconnect, since many of the things > I'd do in those cases don't work here.. > You're right that the agent SSL code is very old and badly needs an overhaul. For some interesting historical context, check out this Redmine bug and the related issues that it links to: https://projects.puppetlabs.com/issues/3143 > In short -- I think the following problems still exist: > > * There's still no support for putting multiple certificate files as the > puppet CA -- all must still be signed by a common root entity. Is this > correct? (In the "web" analogy, my browser could have lots of built-in > and additional trust-points, both corporate and as-shipped). > Have you verified experientially that this doesn't work in current Puppet versions? I am working on one variant of this (chain-of-trust with root and intermediate CA in $ssldir/certs/ca.pem) and it does work. That's slightly different to what you're saying though, which is that any issuer in that file should be considered valid. Due to some confusion in the CA code (see https://tickets.puppetlabs.com/browse/SERVER-1315 ) the ca_crt.pem which the agent downloads can't contain a bundle, but I believe if you "pre-seed" a valid bundle into that location the agent code will do the right thing. You're right that the agent does not support a CApath, in openssl parlance: a directory of hashed CA certs, any of which are valid. The server side farms out its SSL verification to the underlying web stack, so it ought to be tolerant of agents issued from multiple CAs checking in. I haven't tried this angle yet. > > * There's no directive I can find whereby puppet agents can, within N days > of expiry, re-request their certificate, while maintaining a valid one in > the meantime. On the puppet master, a duplicate cert is treated as an > absolute error and must be purged from both sides with extreme prejudice > and started over. > The first part is true, the second is controlled by the 'allow-duplicate-certs' CA setting which will allow later requests to overwrite newer ones. > > * There's no way the puppet master itself can have multiple trust points. > (I.e. old CA and new CA) -- in the real world, of course, I can have > multiple CA files from which I can trust clients, for example, for SMTP > auth. > * Puppet has no concept of a CA Path, rather than a CA file. And since > certificates are multi-line blocks in text files, they're a real pain to > manipulate with Augeas or shell scripts. > As I said above, on the master the cert verification is delegated to the web server layer (jetty in the case of the puppetserver, apache or nginx or (gah) webrick for non-puppetserver setups). So agent verification on the master has a lot more going for it than the agents verifying the master's identity. > > * There's no way the master can say "multiple public keys for the same > cert are bad, but we will re-sign *existing* keys that are merely near > expiry." (Which is a thing we might do in PGP). And even if we could > define such a policy, there's no support in the agent to do such a thing. > > > * There's no way to have the puppet-master auto-sign a cert, based on the > presence of some sort of file or hash on the node, similar to the above. > There's nothing built-in that does either of these things. But policy-based autosigning provides an API that lets you do this based on some 'a priori' knowledge you have of the node: https://docs.puppet.com/puppet/4.4/reference/ssl_autosign.html This is an interesting line of thought that I'm looking into more on the CA side: you can re-use the same private key to generate a new certificate that would have an extended lifetime but not require a complete re-key. There isn't an API guarantee that agents' certs (and therefore their public keys) are collected and stored in the CA, though such a thing would be very useful and is on deck for future work - you can see the whole list of these things at https://tickets.puppetlabs.com/browse/SERVER-974 > > * We blindly trust the first CA we get (using the default options), but > then have NO real method for accepting a second CA without manually > manipulating the CA files directly. (DANE, anyone?) > I don't know what DANE means in this context, but this statement is true. > > * Your old CA, Puppet Master Certs, and Client Certs, are all an > ecosystem, and there's no way to replace any one of them without having to > replace the whole thing. > > Am I getting this wrong? Please tell me I am. > I have a WIP doc adding support for intermediate CAs up at: https://gist.github.com/ahpook/06d4cfda1d68c08bc82fbfdc40123b28 This may help as many of the goals (and the corresponding implementation bugs or missing features) overlap with your use-case. There's also some tooling that may be helpful from an old and incredibly annoying CVE https://puppet.com/blog/important-security-announcement-altnames-vulnerability (tar gz linked off that page) I'm definitely interested in keeping in touch as you go through this, to make things easier for other people. I think a lot of sites are coming up on the five year anniversary of their installation and the easier this kind of re-keying can be, the better. --eric0 -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/75fa2dc1-9170-41e2-9df1-815dffce924f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
