Captain
Captain
359 views

iSPI QA wont connect to NNMi - certificate_unknown

Jump to solution

Hello, I have a ticket open with support already but am curious if anyone else has run into this and possibly solved it? We have NNMi running using an internal CA, the Root and Issuing CA Certs are in the trust file in /var/opt/OV/shared/nnm/certificates, as is the server key in the key file. iSPI QA is a fresh install and iSPI Performance is running properly and logging data to NPS. On startup the qa.log file reports...

 

 

2020-11-17 12:11:47,482 INFO  [com.hp.ov.nms.spi.qa.manager.NnmRegistration] Invoking addServer....
2020-11-17 12:11:48,911 SEVERE [com.hp.ov.nms.spi.utils.services.ExtendedPropertiesImpl] exportProperty failed with exceptionjavax.xml.ws.WebServiceException: java.net.ConnectException: Handshake failure connecting to nnmi.domain.com
	at ...
Caused by: java.net.ConnectException: Handshake failure connecting to nnmi.domain.com
	at ...
Caused by: javax.net.ssl.SSLException: Received fatal alert: certificate_unknown
        at ...

 

 

I can't see anywhere that the certificate might be unknown, other than maybe adding the server cert to the trust file too. QA is pointed and the password correct to the same keystores in the /opt/OV/qa/server/server.properties file as NNMi uses.

0 Likes
1 Solution

Accepted Solutions
Captain
Captain

Issue ended up being that the SSL Certificate for the server did not have the clientAuth extendedKeyUsage token.

I found the answer to this by a random google that ended up with the pdf linked below (p. 31)

https://community.softwaregrp.com/dcvta86296/attachments/dcvta86296/itrc-165/162330/1/Certificates%20and%20NNMi.pdf

 

I am not sure what post that attachment came from but thanks Dave Young!

View solution in original post

4 Replies
Micro Focus Expert
Micro Focus Expert

Hi,

That was a problem of lower versions. Actually the message misleads - not that certificate is unknown, but the server.properties points to the wrong folder, file or the keystore. You should check all files under that name in whole subfolder structure - there are two, /var/opt/OV/shared/nnm and /opt/OV/nmsas/ for both /NNM and /QA. Finally, take a closer look on /log/nmsas.stdout for the key_alias and KEY_ALIAS - the first should set, but the seconds is depreciated for PKCS12, so that's better to delete the line if the keystore has been migrated from JKS on new format.

BR,

Captain
Captain

Thanks, I will take a further look into this as it did come from an older version updated over time. 

In the nmsas.stdout I do not see lines for key_alias, but do see KEY_ALIAS which is blank, as is the setting for nmsas.server.security.keystore.alias -- maybe i should be setting this? I pretty much followed https://docs.microfocus.com/itom/Network_Node_Manager_i:2019.11/ManageCertificates to a T when switching to the PKCS12 key/trust stores

output for both nmsas.stdout match, other than  com.hp.ov.nms.ssl.KEY_ALIAS = which is not in the qa/nmsas.stdout file but is in nnm/nmsas.stdout and reference the PKCS12 key/trust files.

 

    javax.net.ssl.keyStore                                        = /var/opt/OV/shared/nnm/certificates/nnm-key.p12
    javax.net.ssl.keyStorePassword                                = ********
    javax.net.ssl.keyStoreType                                    = PKCS12
    javax.net.ssl.trustStore                                      = /var/opt/OV/shared/nnm/certificates/nnm-trust.p12
    javax.net.ssl.trustStorePassword                              = ********
    javax.net.ssl.trustStoreType                                  = PKCS12
    nmsas.server.security.keystore.alias                          =
    nmsas.server.security.keystore.cred                           = ********
    nmsas.server.security.keystore.file                           = /var/opt/OV/shared/nnm/certificates/nnm-key.p12
    nmsas.server.security.keystore.type                           = PKCS12
    nmsas.server.security.truststore.cred                         = ********
    nmsas.server.security.truststore.file                         = /var/opt/OV/shared/nnm/certificates/nnm-trust.p12

 

Micro Focus Expert
Micro Focus Expert

There is no issue on the given output, no KEY_ALIAS, and the .alias it Okay if equal to ""

nmsas.server.security.keystore.alias                          =
0 Likes
Captain
Captain

Issue ended up being that the SSL Certificate for the server did not have the clientAuth extendedKeyUsage token.

I found the answer to this by a random google that ended up with the pdf linked below (p. 31)

https://community.softwaregrp.com/dcvta86296/attachments/dcvta86296/itrc-165/162330/1/Certificates%20and%20NNMi.pdf

 

I am not sure what post that attachment came from but thanks Dave Young!

View solution in original post

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.