#mcollective

one moment

your root ssl identity has to be the same in all places

otherwise you get what you see, which is it says "that doesn't match the notion I have of root's keypair"

_rc: just to confirm I have regenerated the sums en-masse to be 100% sure each is correct in the paste

I do see that yes, the root keypair is not the same on both hosts

well it has to be

_rc: that is clear, thank you. The client parameter "plugin.ssl_server_public" does this need to be the same on all hosts - in which case I would assume it to be the middleware certificare

it's not the middleware certificate. it's a shared identity shared by all the nodes

like it says here. https://docs.puppetlabs.com/mcollective/referen...

As a general comment I am tempted to rename the file extensions from .pem to .key & .cert respectively to help me reduce my own confusion

that would be a bad idea

the securityprovider expects the files to be named after that pattern

ok

I have tried using a shared CA configuration and have somehow made it worse

[marionette-collective] ploubser pushed 2 new commits to 2.6.x: http://git.io/hySuMg

marionette-collective/2.6.x 03ab082 Richard Clamp: MCO-502 update changelog and releasenotes for 2.6.1

marionette-collective/2.6.x b58bf4a Pieter Loubser: Merge pull request #260 from richardc/MCO-502-changelog_2.6.1...

_rc: I think I'm finally there, thanks for the help. The solution is everso slightly ugly as I'm using the same certs for mco as for activemq - but working is working

ok okay riddle me this. When I use FIND to locate an A/D object, I guess I should be glad that it shows me the object...

but I completely fail to grok why it does not in any display show me WHERE the effing object resides, which is the one and only thing I am looking for.

Yep, there is that object in this tree. Here’s its attributes. But you’ll never know where it is… until you FIND again.

We’re lonely and we like to be used. Often.

think you;ve got the wrong window

*headdesk*

yes, yes I do