Invalid endpoint origin (client not allowed)

This forum was archived to /woltlab and is now in read-only mode. Please register a new account on our new community platform.

You can create a thread on the new site and link to an archived thread. This archive is available as knowledge base, safe and secured.

More details here.
  • Dear mp-users,

    i am not able to allow my master to send commands to my client as the subject line already states.
    Full LogLine:

    notice/ClusterEvents: Discarding 'execute command' message from '': Invalid endpoint origin (client not allowed).

    My master node is on debian 8 and runs icinga r2.6.2-1 (so does my client under debian 7).
    I have setup a zone on the master like this:

    my clients zone config:

    contants.conf relates NodeName and ZoneName to

    my api.conf on client:

    1. object ApiListener "api" {
    2. cert_path = SysconfDir + "/icinga2/pki/" + NodeName + ".crt"
    3. key_path = SysconfDir + "/icinga2/pki/" + NodeName + ".key"
    4. ca_path = SysconfDir + "/icinga2/pki/ca.crt"
    5. accept_config = true
    6. accept_commands = true
    7. }

    api.conf on master:

    1. object ApiListener "api" {
    2. cert_path = SysconfDir + "/icinga2/pki/" + NodeName + ".crt"
    3. key_path = SysconfDir + "/icinga2/pki/" + NodeName + ".key"
    4. ca_path = "/var/lib/icinga2/ca/ca.crt"
    5. ticket_salt = TicketSalt
    6. }

    Inital PKI was build with icinga2 pki new-ca and client cert and keys build with provided tools (icinga2 pki new-cert and sign-csr).

    A connection test with openssl from master to client (and vice versa) is successful with:

    1. openssl s_client -CAfile /var/lib/icinga2/ca/ca.crt ca.crt -cert /etc/icinga2/pki/ -key /etc/icinga2/pki/ -connect
    2. CONNECTED(00000003)

    i read up and down the docs but cannot see the error in my config, does anybody else see it?



  • my api.conf on client:

    accept_commands = true

    That is the thing that matters - and that looks ok for me.

    Did you reSTART the icinga2 at the client so that it honors the setting ?

    • Masters zone.conf looks good.
    • Clients zone.conf looks good as long nodename and zonename are set to the respective values of the masters zone.conf in the client's constants.conf.
    • api.conf client looks good.
    • api.conf master looks good.

    icinga2 feature list shows api enabled on both machines ?

    in icinga2.conf, the following line is present include "features-enabled/*.conf" @ both machines ?

    Certificates are ok ?…r-unauthenticated-clients

    May be related:

    Invalid endpoint origin (client not allowed)

    The post was edited 2 times, last by sru ().

  • hey sru,

    thanks for your reply.

    icinga2 was restarted more than once on both nodes.

    feature list master:

    1. Disabled features: compatlog debuglog gelf graphite influxdb livestatus opentsdb perfdata statusdata syslog
    2. Enabled features: api checker command ido-pgsql mainlog notification

    feature list client:

    1. Disabled features: checker command compatlog debuglog gelf graphite influxdb livestatus mainlog notification opentsdb perfdata statusdata syslog
    2. Enabled features: api

    constants.conf on client (relevant part):

    1. const NodeName = ""
    2. const ZoneName = ""

    what leaves me puzzled (debuglog from client):

    that the client does not connect to master should be fine, as the master is configured to initialize the connection.

    certificates look ok to me, as the openssl command successfully establishes a connection.

    but maybe theres more to it to verify?

    and thanks for the related link. i consulted that one before and already thought of a misconfigured trust within the zones, but i could not find it.

    i am quite lost here...

  • I can only guess from the obfuscated configuration. I know the code parts and they verify that the sender's endpoint name is configured on the child node. So I would verify that a) the master got the correct local endpoint configured (FQDN typo maybe?) b) the client got the correct master endpoint name. Both must match, otherwise the client won't trust the master node in terms of receiving and processing messages.

  • hi dnsmichi,

    correct: obfuscation does not really help here.

    i have checked zone.conf and constants.conf on both hosts, as well as openssl connect to verifiy CNs. i cannot see any typo.
    I have started both icinga instances with iicinga2 daemon -x debug and extracted this here:

    That looks ok to me but icingaweb2 still insists on:

    Remote Icinga instance '' is not connected to ''

    some minutes later in the logs:

    still this look fine to me, no connection problems are reported here or do I interpret the logs in a wrong way?

    could it be that icingaweb2 does not report the correct state?
    Is there some cache that could be purged?

    I enabled checker feature on gosa-ma as I assumed that this might be the problem but it is not...

    next step might be to rebuild pki

  • Oh, I did not mean to let you post your sensitive information. Just saying it makes it harder to analyse the issue. Still there are certain tools to verify the same names.

    For example, create a checksum over the host name you've set on the master (NodeName, the Endpoint object name) and then do that on the client. Might be a whitespace, or strangely typed character too.

    1. md5sum <object name>
  • no sensitive here, only internal names. but usually i prefer not to expose them but i got the point that it is more complex to debug.

    thanks for looking into it.

    the problem was my pki. i used:

    1. icinga2 pki new-cert --cn fqdn --key fqdn --cert fqdn

    and that produced me a self signed certificate (as stated in the logs!)

    but it was not signed against my ca, so i used:

    1. icinga2 pki new-cert --cn fqdn --key fqdn.key --csr fqdn.csr

    and signed it off with my ca:

    1. icinga2 pki sign-csr --csr fqdn.csr --cert fqdn.crt

    (likewise i did for my clients)

    thats it. now they are happily communicating :-)



  • Uhm that's interesting, thanks for sharing. The client shouldn't even receive those execute::command messages if the SSL handshake fails. Are you sure you've looked into the correct logs on this exact client?