Customers in the AppDynamics SaaS environment occasionally utilize third party services to export data from the AppDynamics APM service.
An example would be an external monitoring/alerting service. To properly do this, the SaaS controller would need to send a message to an external service. As this data should always be encrypted, the SaaS controller needs to create an SSL session to the external service. If the controller does not trust the Root Certificate Authority certificate in the external service’s certificate chain, this results in a connection failure and an error in the controller logs.
One of the key components of SSL is “trust.” The source/client (Controller in this scenario) must trust that the destination/server (external service) is who it says it is, so that the two parties can agree to transmit data securely. This trust is established via an SSL certificate supplied by the server, which is validated by the client via a “trust store” which exists on the client system and contains a list of Root Certificate Authority certificates which the client trusts to identify that servers are authentic.
In the AppDynamics controller configuration, this list of certificates is managed by the APM application running on the controller.
Note that the only certificates that should be installed in the controller's trust store are Root CA certificates. These Root CAs are often valid for decades and sign certificates for Intermediate CAs, which are still valid for a long period of time but are meant to be slightly more interchangeable. Web server administrators deploy Host certificates to their system and those certificates are signed by an Intermediate CA. Any public-facing server hosting SSL services is responsible for supplying both the Host and Intermediate CA certificates to the client during the SSL handshake. The client uses those two certificates to construct a chain of certificates along with the Root CA certificate in its local trust store.
AppDynamics SaaS Operations makes their best effort to keep the controller’s trust store up to date with the industry standard list of trusted Root CAs maintained by Mozilla. However, there are instances when a public-facing service is issued an SSL certificate signed in a Root’s chain before that Root’s CA certificate can be installed in the controller’s trust store.
If the controller attempts to create an SSL connection to a third party service whose SSL certificate belongs to a chain signed by a Root that the controller does not trust, you will see an error in the controller logs that looks something like this:
PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target
The solution to this error is to install the Root CA certificate in the controller’s trust store.
If this is an on-premise controller, you can install the certificate in the trust store with the following command:
keytool -import -alias <any_alias> -file <path_to_root_cert> -keystore <controller_home>/appserver/glassfish/domains/domain1/config/cacerts.jks
After installing the certificate in the trust store, restart the controller for it to begin using the new certificate in its trust validation.
If this is a SaaS controller, please create a ticket with AppDynamics support and supply:
As long as the Root CA certificate that signs the server’s Intermediate certificate is in the Mozilla Included CA Certificate List, AppDynamics SaaS Operations can install the certificate in the controller’s trust store to enable this communication.