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.
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..
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).
* 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.
* 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.
* 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.
* 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?)
* 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.
-Dan
--
--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
Site: http://www.gushi.org
---------------------------
