Skip to main content
Question

CMA - Peer name is not in peer certificate

  • August 27, 2026
  • 1 reply
  • 30 views
Forum|alt.badge.img

Hello,

I’m testing Windows monitoring through CMA but I keep getting errors when using TLS.

Configuration : 

  • Connection : Agent to poller
  • Encryption : TLS
  • Public certificate : /etc/pki/cma/server.crt (644)
  • Private key : /etc/pki/cma/server.key (644)
  • CA : Left blank (as per the documentation)

When using the poller’s FQDN (server.domain.corp) in the agent’s config, I get these errors on the agent’s side :

[2026-08-27 17:29:10.422] [centreon-monitoring-agent] [error] [bireactor.cc:98] 0x195a862a240 client peer:server.domain.corp:4317 fail read from stream
[2026-08-27 17:29:10.484] [centreon-monitoring-agent] [error] [bireactor.cc:148] 0x195a862a240 client peer server.domain.corp:4317 fail write to stream
[2026-08-27 17:29:10.484] [centreon-monitoring-agent] [error] [bireactor.cc:189] 0x195a862a240 peer:server.domain.corp:4317 client::OnDone(failed to connect to all addresses; last error: UNKNOWN: ipv4:x.x.x.x:4317: Peer name server.domain.corp is not in peer certificate)

and this error log on the poller’s side :

[2026-08-27T17:29:05.756+02:00] [grpc] [error] [12427] No match found for server name: server.domain.corp


When using the poller’s IP address (x.x.x.x) in the agent’s config, I only get these errors on the agent’s side :

[2026-08-27 17:39:33.853] [centreon-monitoring-agent] [error] [bireactor.cc:148] 0x1ad8a8df270 client peer x.x.x.x:4317 fail write to stream
[2026-08-27 17:39:33.853] [centreon-monitoring-agent] [error] [bireactor.cc:98] 0x1ad8a8df270 client peer:x.x.x.x:4317 fail read from stream
[2026-08-27 17:39:33.853] [centreon-monitoring-agent] [error] [bireactor.cc:189] 0x1ad8a8df270 peer:x.x.x.x:4317 client::OnDone(failed to connect to all addresses; last error: UNKNOWN: ipv4:x.x.x.x:4317: Peer name x.x.x.x is not in peer certificate)

The server’s certificate is signed by our Intermediate CA and contains FQDN in the Subject and both the IP and FQDN in the SAN : 

Certificate:
    Data:
        Version: 3 (0x2)
[...]
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = XX, DC = corp, DC = xxx, O = XXX, OU = XXX, CN = XXX Intermediate CA
        Validity
            Not Before: Aug 27 13:36:06 2026 GMT
            Not After : Aug 26 13:36:06 2028 GMT
        Subject: C = XX, ST = XXX, L = XXX, O = XXX, OU = XXX, CN = server.domain.corp, emailAddress = xxx
[...]
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:server.domain.corp, IP Address:x.x.x.x
[...]

Both the Root CA and the Intermediate CA are trusted by the agent.

Did anyone else encounter and managed to solve this issue ?

Centreon v25.10.16
Centreon Monitoring Agent v25.10.8

1 reply

lpinsivy
Centreonian
Forum|alt.badge.img+21
  • lpinsivy
  • Centreonian
  • August 31, 2026

Hi ​@Selgie ,

Thanks for the very detailed report — the logs actually point to a specific piece of the configuration rather than a bug.

In "Agent to poller" mode, the poller is the TLS server (it presents server.crt/server.key), and the agent (the host side, in the Windows host's agent configuration) is the one that must verify that certificate — which requires the CA field to be filled in.

Looking at the certificate documentation, there's actually no scenario where that field should be left empty:

  • Certificate signed by a CA → host side needs the CA certificate file
  • Self-signed certificate → host side points to the public certificate itself
  • Wildcard certificate → host side points to the wildcard file

Since your certificate is signed by an intermediate CA, the CA field on the agent/host side should have been filled in with that intermediate CA (or the full intermediate + root chain, in PEM), not left blank. Having the CA trusted in the Windows certificate store doesn't help here: CMA relies on gRPC/BoringSSL and only trusts what's explicitly configured in its own settings — it doesn't read the OS trust store.

This also fits the No match found for server name you're seeing on the poller side: without a valid trust chain configured on the agent, the hostname/peer verification fails and gRPC surfaces the generic "Peer name X is not in peer certificate" error instead of a clearer chain-of-trust error.

Suggested fix:

  1. Fill in the CA field in the agent/host configuration with your intermediate CA certificate (or the intermediate + root chain).
  2. Redeploy the configuration, then restart the Centreon Monitoring Agent service on the Windows host — and make sure the poller's centreon-engine service was restarted after the last deploy too, since /etc/centreon-engine/otl_server.json is only picked up on restart.
  3. If it still fails, check what the poller is actually presenting on port 4317:
    openssl s_client -connect <poller_ip>:4317 -servername server.domain.corp
    and confirm the returned certificate is really server.crt with the expected SAN.
  4. "Insecure TLS" + a Common Name override is available as a fallback for cases where one certificate must cover multiple pollers without matching SANs, but you shouldn't need it here since your SAN already includes both the FQDN and the IP.

Let us know if filling in the CA field resolves it.

Terms & ConditionsAccessibility statement