NNMi cluster fails to start after generating new self-signed certs and merging process.

I have two NNMi 10.30 serversrunning on RHEL6.10 that had been operating in application failover mode, after a issue on the primary forced a reinstall and I re-did the cert merge process, the fresh install primary server started the cluster fine, but the cluster process would not start on the secondary server. When running 'nnmcluster -daemon' on secondary I got no error but then if I ran 'nnmcluster -display' I received the following: "error: The nnmi.keystore file does not contain a key matching the SSL alias in the nms-local.properties file."

I've attempted following the processes for deleting the existing keys on both servers and generating new self-signed certificates per the MF documentation pages here:

Using Certificates with the PKCS #12 Repository (microfocus.com)

But now, after completing the certificate merge process I am receiving that same error message on both the primary and secondary NNMi servers when running the 'nnmcluster' command.

I found the following knowledge article referencing the error and am fairly certain that when I created the latest self-signed certs for both servers and did the cert merge, the cluster daemon process was not running, although it MAY have been running back when I had the initial issue only on the secondary server - prior to generating all new self-signed certs.

The nnm.keystore file does not contain a key matching the SSL alias in the nms-local.properties file. (microfocus.com)

This article does not explain how to recover from the issue at hand. Am I to assume that re-creating new self-signed certificates again and ensuring that all nnm processes are stopped at the time the certs are generated and merged will resolve the issue?

Thank you,


  • Additional info:

    I forgot to mention in the initial post but also found this odd. When merging the secondary server's nnm-trust.p12 file with the primary's, I got the following message:

    Merging the following files into the nnm truststore:
    The selfsigned key alias: <serverName>.selfsigned exists in both keystores but is not being overwritten.
    Alias: <serverName>.selfsigned already existed in the active truststore, not merging.

    I'm unsure if this would be an indication of an issue with the new certificates or not. When creating the new self-signed certificates, I used the alias name format <serverName>-date rather than <serverName>.selfsigned

    Could that cause a problem? The instructions in the documentation stated that either alias convention could be used for creating a new self-signed certificate (fqdn.selfsigned or fqdn.date).

  • Hello Scott,

    right now I'm confused about the keystore setup.

    Are you working on (the old) JKS keystores? (because you mentioned nnm.keystore)

    Or do you have a setup with (the new) PKCS12 keystores? (indicated by nnm-trust.p12)

    I'm not sure, with which version the change from JKS to PKCS happened in NNM, but since you "reinstalled" your primary server, this (new) server migth now use PKCS12, while the old one still works on JKS...

    Could you please check the "server.properties" file in "/var/opt/OV/nmsas/nms" on both servers?

    (I hope the path is correct, I'm working on Windows and NNM 2021.11 right now.)

    Whithin this file the keystores and aliases are defined.



  • Hallo Karsten,

    hello Scott,

    you can check this with this command on each node:

    nnmprops -l | grep -i store

    HTH and best regards


  • I was confused by the error message as well, since the application on both servers are properly configured to use the PKCS12 certificates. After some digging I came across this article which explains the error.

    Confusing error messages by nnmcluster when using PKCS12 certificate stores (microfocus.com)

    Based on the article, the error message simply was not updated after they changed the certificate type used by the software so it continues to reference the old keystore files even though properly updated to utilize the new PKCS format. It would appear as though the solution is to 'import' the new key into the trust file but I don't see instructions for how to accomplish that in either the knowledge document or the documentation referenced within my initial post. The MF certificate documentation does not reference a need to import keys after generating new self-signed certificates, it simply states that once new self-signed certs are created, start the NNM processes and everything will be awesome. That does not appear to be the case. At least not when working with an AF pair.