On Monday, January 9, 2017 at 2:39:38 PM UTC-5, R.I. Pienaar wrote: > > > Because if i can convince your client to connect to $evil_ca, then what? > How's it to know its a new legit ca and not a new bad ca? >
The same way it "knew" when you originally provisioned it-- It didn't. In fact, the agent, by default, displays the *request* fingerprint-- but never the server fingerprint, and doesn't give me a chance to verify it. So how many times have you verified you didn't talk to an evil CA when you originally connected an agent? And the thing is, if I delete that cached file, it promptly (and as near as I can tell, blindly) downloads the ca.pem file anyway. The entire point of a public/private key system is the ability to trust. The agent can trust the server, the server can trust the agent. The lack of ability to renew that trust *before* it expires is a serious failure-- Recently, my initial 5 year CA expired. The "conventional wisdom" was to REBUILD MY ENTIRE ENTERPRISE. If I'd had to do that, there's a good chance I'd have reevaluated my 5 year old decision to go with puppet-- not saying I wouldn't have wound up with puppet anyway, but I'd have looked much, much harder at competing products, which have made huge progress in 5 years. Fortunately, based on a suggestion here, I was able to sign a new CA with the same private key used to create the original CA, and replace that CA before everything stopped working. Then, using mcollective, I removed the cached ca.pem file, and let puppet download the new ca.pem. Of course, the workstations that were off for the month of July came back and couldn't do anything, because the original CA had expired, and the only way to fix them at that point was to manually log in and clean up the mess. If the CA is valid, and the client cert is valid, there's no reason on earth why the agent and CA shouldn't be able to renegotiate a certificate. There's no reason why the CA shouldn't be able to tell the client "Oh, you have the old CA, here, have a new one", since the agent has, in theory, a valid copy of the original CA which it can use to validate the connection. Otherwise, you have to delete the certificates from the master and the agent, regenerate the request from the agent, and re-sign the cert on the master-- and you can't tell me that's a more secure process than a negotiated, verified renewal / update-- not to mention a massive time waster that goes completely against the philosophy of *having* centralized management. It's too much dev, not enough ops. :) I've written a script to automate renewing the agent cert-- but it's ugly, and as you point out, it opens up the possibility for someone to impersonate my existing CA. -- 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/12d735a7-554c-4687-9043-95f916f62af6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
