Linux agent Discovery issue on SCOM 2019

Question

Hi Everyone,

We have followed the steps mentioned in the below link, yet our issue is unresolved, please assist us with the same.

The certificate Common Name (CN) does not match when deploying the Operations Manager Linux agent

https://learn.microsoft.com/en-us/troubleshoot/system-center/scom/deploy-linux-agent-fails

We have resolved the issue with pinging Linux agent.
However, we are facing the below issue when we try to discover the Linux machine using discovery method.
(We have installed the agent manually before)
We are now able to discover the Linux agent, but after clicking manage we get the sign certificate Manage failure message.

We are using the following steps/command to create Vaid certificate from ManagementServer1 for the Linux host authentication.

Is it possible to add the ManagementServer2 also in the above command, as we have 2 management servers configured for Managing SCOM agent, (Part of the Unix/Linux resource pool)

Error:
Agent verification failed. Error detail: The server certificate on the destination computer linuxagent.com:1270) has the following errors:
The SSL certificate contains a common name (CN) that does not match the hostname.
It is possible that:

1. The destination certificate is signed by another certificate authority not trusted by the management server.
2. The destination has an invalid certificate, e.g., its common name (CN) does not match the fully qualified domain name (FQDN) used for the connection. The FQDN used for the connection is: abc.com.
3. The servers in the resource pool have not been configured to trust certificates signed by other servers in the pool.

Thanks in advance,
Sushanth S K

Answer 1

Hi @Kadam, Sushanth ,

can you please check if both your management sevrers have the X..plat certificate of all other resource pool members on them?

from:
Monitoring UNIX/Linux with OpsMgr 2016
https://kevinholman.com/2016/11/11/monitoring-unix-linux-with-opsmgr-2016/

To configure for high availability, each management server in the resource pool must have all the root certificates that are used to sign the certificates that are deployed to the agents on the UNIX and Linux computers. Otherwise, if a management server becomes unavailable, the other management servers would not be able to trust the certificates that were signed by the server that failed.
We provide a tool to handle the certificates, named scxcertconfig.exe. Essentially what you must do, is to log on to EACH management server that will be part of a Unix/Linux monitoring resource pool, and export their SCX (cross plat) certificate to a file share. Then import each others certificates so they are trusted.

After you have checked this, can you please cleanup as per the article you have posted:

Remove the existing contents of the agent directory on the server and reinstall the agent RPM.

After reinstalling the agent you can run:

openssl x509 -noout -in /etc/opt/microsoft/scx/ssl/scx.pem -subject -issuer -dates  

and then:

Generate the certificate, making sure to use the correct host name:
/opt/Microsoft/scx/bin/tools/scssslconfig -f -h <hostname>

Afterwards you should be able to sign the certificate. Please let me know how this looks, Thanks!

----------

(If the reply was helpful please don't forget to upvote and/or accept as answer, thank you)
Regards
Stoyan Chalakov