On Friday, January 29, 2016 at 4:25:36 AM UTC-6, Alex M wrote: > > so, i fixed it. by reinstalling Windows... but it isn't a good solution. > >
No, that's not a good solution at all. Fortunately, it's also not a necessary one. The agent and master each identify themselves to the other via an SSL certificate signed by a trusted authority (which authority by default is operated by the master). On the master / CA side, the CA refuses to sign a certificate for a given name if an another valid certificate for that name is already outstanding. This is an essential aspect of Puppet's security infrastructure, for otherwise there would be a substantial risk of one machine impersonating another, whether purposefully or accidentally. If the CA has an outstanding certificate bearing the specified name, then that cert must expire or be revoked before the CA will issue a new one for the same name. The error message you reported indicates that the hangup was there. On the agent side, the agent does not share variable data (configuration, cached catalogs, plugins, *certificates*) between users, in part because that would open numerous avenues for credential theft, privilege escalation, etc.. Since certificates in particular are not (automatically) shared even within the same machine, and since the CA will not permit multiple certs for the same name to be valid simultaneously, you cannot freely switch the identity under which the agent runs. If a certificate has already been issued to a given machine, with the agent running under a given identity, and you want the agent to run instead with a different identity, then you have three main options: 1. Revoke the machine's existing certificate at the CA, and allow the agent, running under the new identity, to request a new one. 2. Copy the old cert or otherwise make it accessible under the new identity. 3. Request a certificate with a different name. If you do this, then for all intents and purposes, Puppet considers the agent to represent a different machine when the agent presents one certificate than when it present the other. Option (1) is probably easiest and best in practice, but I am reasonably confident that any of these would have worked for you. Note, by the way, that reinstalling the OS on the agent side is not even guaranteed to solve a certificate problem like the one you reported. If the new OS installation is configured so that it requests the same certificate name that the old one did, then you'll still have exactly the same problem. In fact, if you set up an entirely different machine that requests a certificate for a name that already has an outstanding, valid certificate, then you will also see the same error. I seem to recall PuppetLabs having a fairly good overview of all this among its documentation pages, but now I'm having trouble finding such a thing. There are still some docs about the certificate management tool <https://docs.puppetlabs.com/puppet/latest/reference/man/cert.html>, and docs about some non-default CA configurations and about a few non-routine actions, but the closest I can find to a certificate management overview is a somewhat dated document targeted a bit differently, at agent/master HTTPS interactions <https://docs.puppetlabs.com/puppet/4.3/reference/subsystem_agent_master_comm.html> . John -- 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/d131a809-c014-41ff-adf9-82e7fd929fae%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
