# Icinga certs questions

**URL:** <https://community.icinga.com/t/icinga-certs-questions/6421>\
**Category:** Icinga 2\
**Tags:** certificates, certificate\
**Created:** [January 8, 2021, 4:08pm UTC](https://community.icinga.com/t/icinga-certs-questions/6421 "2021-01-08T16:08:42Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![sysres-dev](https://community.icinga.com/user_avatar/community.icinga.com/sysres-dev/32/1023_2.png) [@sysres-dev](https://community.icinga.com/u/sysres-dev)\
**Post date:** [January 8, 2021, 4:08pm UTC](https://community.icinga.com/t/icinga-certs-questions/6421/1 "2021-01-08T16:08:42Z")

</div>

Hello Community and Devs,  
I have several questions about what’s possible with icinga CA.

1. Is it possible (now or in the future) to use an external CA (a company one for example) for icinga to sign endpoints csr instead of using the icinga generated one ?  
As far i understood this related post, it seems possible but may introduce unexpected behaviors which could be hard to debug and solve.  
[Own CA for Icinga Cluster/API communication?](https://community.icinga.com/t/own-ca-for-icinga-cluster-api-communication/243/2)

2. Is it possible (now or in the future) to have multiple SAN (suject alternative name, endpoint fqdn for icinga) for an endpoint certificate ?  
The idea is to have both the endpoint fqdn and an other fqdn pointing to a virtual address to ensure high availability.

Thanks by advance,

---

<div class="post-metadata">

**Author:** ![sysres-dev](https://community.icinga.com/user_avatar/community.icinga.com/sysres-dev/32/1023_2.png) [@sysres-dev](https://community.icinga.com/u/sysres-dev)\
**Post date:** [February 8, 2021, 2:17pm UTC](https://community.icinga.com/t/icinga-certs-questions/6421/2 "2021-02-08T14:17:55Z")

</div>

Hello there,  
Is there any chances this could come true in the future ?

---

<div class="post-metadata">

**Author:** ![Al2Klimov](https://community.icinga.com/user_avatar/community.icinga.com/al2klimov/32/959_2.png) [@Al2Klimov](https://community.icinga.com/u/Al2Klimov)\
**Post date:** [February 9, 2021, 10:49am UTC](https://community.icinga.com/t/icinga-certs-questions/6421/3 "2021-02-09T10:49:24Z")

</div>

Hello @sysres-dev!

1. You understand the mentioned post correctly. You _can_ use your own CA – at your own risk.
2. Please describe more detailed what you’d like to do and what for.

Best  
AK

---

<div class="post-metadata">

**Author:** ![emikulic](https://community.icinga.com/letter_avatar_proxy/v4/letter/e/ce73a5/32.png) [@emikulic](https://community.icinga.com/u/emikulic)\
**Post date:** [October 19, 2021, 6:45pm UTC](https://community.icinga.com/t/icinga-certs-questions/6421/4 "2021-10-19T18:45:52Z")

</div>

I agree. I’d like to see it just support standard Openssl and its interactions with CA’s/Cert’s. Or just use the OS Trusted CA’s and certs stores like any application basically. Linux and Windows both have them, and browsers too and its the way of the world nowdays. Only getting more so.

---

<div class="post-metadata">

**Author:** ![Tqnsls](https://community.icinga.com/user_avatar/community.icinga.com/tqnsls/32/5067_2.png) [@Tqnsls](https://community.icinga.com/u/Tqnsls)\
**Post date:** [June 25, 2025, 12:15pm UTC](https://community.icinga.com/t/icinga-certs-questions/6421/5 "2025-06-25T12:15:10Z")

</div>

> [@sysres-dev](#):
>
> Is it possible (now or in the future) to have multiple SAN (suject alternative name, endpoint fqdn for icinga) for an endpoint certificate ?  
> The idea is to have both the endpoint fqdn and an other fqdn pointing to a virtual address to ensure high availability.

> [@Al2Klimov](#):
>
> Please describe more detailed what you’d like to do and what for.

I would like to answer this question in regard of our use case:  
We have some ha clusters with two endpoints. each endpoint has an icinga agent certificate with common name equals endpoint-name.  
There is also a cluster configured in icinga (which also has an endpoint).  
The ip of the cluster is mounted as a virtual ip to one of the node endpoints. when the cluster endpoint is requested, of course a node endpoint with the endpoint certificate answers which generates a log entry similar to `warning/ApiListener: Unexpected certificate common name while connecting to endpoint 'cluster_endpoint': got 'node_endpoint'`,  
also because of the dissimilar common name the check on the cluster endpoint fails to receive an appropriate response.

My idea is that when both the node endpoints certificates contain the common name (which is the node endpoint) and as a multi san (e.g. DNS.1) the cluster endpoint name, the check could successfully connect to the cluster and receive a valid response.

I hope this is as detailed as needed.

---

<div class="post-metadata">

**Author:** ![moreamazingnick](https://community.icinga.com/user_avatar/community.icinga.com/moreamazingnick/32/7725_2.png) [@moreamazingnick](https://community.icinga.com/u/moreamazingnick)\
**Post date:** [June 26, 2025, 9:40am UTC](https://community.icinga.com/t/icinga-certs-questions/6421/6 "2025-06-26T09:40:47Z")

</div>

> [@Tqnsls](#):
>
> cluster is mounted as a virtual ip

that is ok for icingaweb2 but not for icinga2 since it manages the cluster on its own.

Your agent config should look something like this if there are no satellites involved and if the connction is established by the agent:

```auto
object Endpoint "icinga2-agent1" {
}

object Zone "icinga2-agent1" {
  endpoints = ["icinga2-agent1"]
  parent = "master"
}

object Endpoint "icinga2-master1.localdomain" {
  host = "192.168.56.101"
}

object Endpoint "icinga2-master2.localdomain" {
  host = "192.168.56.102"
}

object Zone "master" {
  endpoints = ["icinga2-master1.localdomain", "icinga2-master2.localdomain"]
}

```

the icinga agent will connect to both endpoints, if one connection is gone the other one will handle the check updates

---

<div class="post-metadata">

**Author:** ![Tqnsls](https://community.icinga.com/user_avatar/community.icinga.com/tqnsls/32/5067_2.png) [@Tqnsls](https://community.icinga.com/u/Tqnsls)\
**Post date:** [June 26, 2025, 10:02am UTC](https://community.icinga.com/t/icinga-certs-questions/6421/7 "2025-06-26T10:02:45Z")

</div>

Thanks Nick, but I am not talking about an icinga (master) cluster.  
I am talking about for example a ha webserver cluster.  
Both webserver nodes have one unique hostname / icinga-agent-endpoint (e.g. `ubuntu-apache-node1.local` and `ubuntu-apache-node2.local`) and one unique physical IP.  
Also the webserver cluster has a unique endpoint name (`ubuntu-apache-cluster.local`) and a virtual ip that resolves to `ubuntu-apache-cluster.local` and is floating between both nodes (or simply on the master while the other node is a slave).

Hope this is understandable

---

<div class="post-metadata">

**Author:** ![moreamazingnick](https://community.icinga.com/user_avatar/community.icinga.com/moreamazingnick/32/7725_2.png) [@moreamazingnick](https://community.icinga.com/u/moreamazingnick)\
**Post date:** [June 26, 2025, 10:11am UTC](https://community.icinga.com/t/icinga-certs-questions/6421/8 "2025-06-26T10:11:36Z")

</div>

your floating ip can float between 2 nodes, your icinga2 should still be reachable via individual ips that are not floating

```auto
warning/ApiListener: Unexpected certificate common name while connecting to endpoint 'cluster_endpoint': got 'node_endpoint'

```

and this means your config / and or ip addresses are not correct and will get you into trouble sooner or later.

---

<div class="post-metadata">

**Author:** ![jeanm](https://community.icinga.com/letter_avatar_proxy/v4/letter/j/6a8cbe/32.png) [@jeanm](https://community.icinga.com/u/jeanm)\
**Post date:** [June 26, 2025, 10:22am UTC](https://community.icinga.com/t/icinga-certs-questions/6421/9 "2025-06-26T10:22:05Z")

</div>

> [@Tqnsls](#):
>
> There is also a cluster configured in icinga (which also has an endpoint).

This part I don’t understand. The way we have done it is to define a Host for the cluster IP, but no Endpoint. On this Host, we have an HTTP Service (port 443), checked from the Satellite.

As Moreamazingnick stated, we do have a Host + Endpoint (agent) for each cluster member (with their individual name and IP), on which we have an HTTP Service (port 8085 for instance) checked locally by the agent, locally on the server (to avoid opening flows on the network firewalls).

---

<div class="post-metadata">

**Author:** ![Tqnsls](https://community.icinga.com/user_avatar/community.icinga.com/tqnsls/32/5067_2.png) [@Tqnsls](https://community.icinga.com/u/Tqnsls)\
**Post date:** [June 26, 2025, 10:40am UTC](https://community.icinga.com/t/icinga-certs-questions/6421/10 "2025-06-26T10:40:41Z")

</div>

> [@moreamazingnick](#):
>
> ```auto
> warning/ApiListener: Unexpected certificate common name while connecting to endpoint 'cluster_endpoint': got 'node_endpoint'
> 
> ```
> 
> and this means your config / and or ip addresses are not correct and will get you into trouble sooner or later.

I know, this was just an example to clarify the issue why checking the cluster won’t work.

> [@jeanm](#):
>
> The way we have done it is to define a Host for the cluster IP, but no Endpoint. On this Host, we have an HTTP Service (port 443), checked from the Satellite.

Yes, that is one way how we execute some checks that only work on the cluster object.  
They are no problem because no icinga-agent is involved.

What I try to approach for example are checks that would succeed on the cluster, succeed on the active master node and would fail on the inactive slave node, e.g. a `check_disk` for a cluster-resource like` /data/drbd` which is always mounted on the master node but never on the inactive one.

What were your approach for such cases? Besides for example rivad’s approach with a dummy-check combined with icinga-dsl:

> [@Set service only on active host](https://community.icinga.com/t/set-service-only-on-active-host/14463/3):
>
> I use a “virtual” Icinga host object with the HA IP. This has the 116\_cluster\_nodes variable set and the same service name as on the HA nodes with the following DSL code as check. object CheckCommand "116-cmd-only-one" { import "plugin-check-command" command = ["/usr/lib64/nagios/plugins/dummy"] timeout = 10s arguments += { "--message" = { description = "Message" required = true value = {{ var output\_status = "" …

From my point of view an icinga-agent certificate with a node’s endpoint-name as CN and the clusters endpoint-name as Subject Alternative Name were one without much icinga-dsl wizardry.

---

<div class="post-metadata">

**Author:** ![jeanm](https://community.icinga.com/letter_avatar_proxy/v4/letter/j/6a8cbe/32.png) [@jeanm](https://community.icinga.com/u/jeanm)\
**Post date:** [June 26, 2025, 11:38am UTC](https://community.icinga.com/t/icinga-certs-questions/6421/11 "2025-06-26T11:38:13Z")

</div>

You may want to read through this question: [Monitoring Avaya Communication Management - Service Monitoring - Icinga Community](https://community.icinga.com/t/monitoring-avaya-communication-management/14663)

It starts with Avaya stuff, but later in the conversation, @rivad very kindly shared his “Icinga DSL wizardry”, as you call it 🙂.

To my understanding and knowledge, there is no iso-functionality alternative.

---

<div class="post-metadata">

**Author:** ![Tqnsls](https://community.icinga.com/user_avatar/community.icinga.com/tqnsls/32/5067_2.png) [@Tqnsls](https://community.icinga.com/u/Tqnsls)\
**Post date:** [June 26, 2025, 11:52am UTC](https://community.icinga.com/t/icinga-certs-questions/6421/12 "2025-06-26T11:52:15Z")

</div>

Oh yes !🙂  
I know of his approach, already implemented it for tests as a “at least one service”-command and as his “only one service”-command and like it.  
I was trying to get into different approaches, thus the answer in this certificate-related thread