Automation Studio (ASAP) - Failed to contact Nolio Server

Products

CA Release Automation - Release Operations Center (Nolio) CA Release Automation - DataManagement Server (Nolio)

Issue/Introduction

When launching Automation Studio (ASAP) it returns the following error after supplying our User Name, Password and clicking Submit/Retry:
Failed to contact Nolio Server.

However, we can login through the ROC without issue.

As part of troubleshooting, we enabled the Java trace and show console to capture more information:

[GSignalsDispatcher] WARN (LoginDialog.java:650) - Failed to contact server [https://nolioserver.domain.com:8443].

org.springframework.remoting.RemoteAccessException: Could not access HTTP invoker remote service at [https://nolioserver.domain.com:8443/datamanagement/remoting/LoginHelpService]; nested exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Environment

Release : 6.6

Component : CA Release Automation Release Operations Center

Cause

The most common cause for the "Failed to contact Nolio Server" error is that the Management Server is not yet ready yet. There are a few reasons why it may not be ready yet. But the key behind this most frequent cause is finding the "I am active" message in the NOLIO_HOME/logs/nolio_dm_all.log* files. This message should appear after starting the mgmt server service. If you have recently started the mgmt server AND the nolio_dm_all.log* files haven't rolled over AND you don't see this message then the remainder of this article is not going to help you. To address this reason/cause for the problem wait/focus on getting that message and then try again. The mgmt server service can take a few minutes to startup. If you're still not seeing this message after a few minutes then you need to solve whatever startup problems the mgmt server service might be having and the rest of this article will not help with that.

Some other notes of importance - as it relates to the remainder of this article:

In this case, logging in via the ROC works. It is likely that logging into ASAP would have worked if the URI schema was changed from https to http and the port was changed from 8443 to 8080.
The HTTPS protocol is being used with its respective port.
Custom certificates were implemented in this environment.

The underlying cause of this problem is that the customized nolio.jks file inside of the RA_HOME/webapps/nolio-app/apps/v2.0.0/lib/custom-truststore.jar file did not match the custom key/cert used by the management server.

Specifically, we found that the certificate used in the nolio.jks file (in the custom-truststore.jar) was for a different server. This was evident in the verbose (keytool -list -v -keystore nolio.jks) output of the nolio.jks's certificates attributes:

Owner
SubjectAlternativeName

Resolution

Recreate the nolio.jks file and custom-truststore.jar file as outlined here: Secure Communications
Additional/detailed steps for Securing Automation Studio are available in the "Securing Automation Studio (ASAP):" section in this article: Secure Communications With Signed Certificates

Once the nolio.jks was created using the certificate matching that used by the mgmt server (as shown in the conf/server.xml's Connector, SSLEnabled -> keystoreFile), the custom-truststore.jar file was newly created with a copy of this file, the custom-truststore.jar file was signed and copied to the appropriate lib directory. The mgmt server server did not need to be restarted for these specific changes. Other changes do require the mgmt server service to be restarted.

Please note that the custom-truststore.jar file must be named exactly that. If it is not the same then you will get the following error: JAR resources in JNLP file are not signed by same certificate

Additional Information

A detailed description of the steps involved for securing the management server and automation studio, with CA signed certificates, can be found here: https://knowledge.broadcom.com/external/article?articleId=10870