Not a customer? Click the 'Start a free trial' link to begin a 30-day SaaS trial of our product and to join our community.
Existing Cisco AppDynamics customers should click the 'Sign In' button to authenticate to access the community
on
09-06-2019
03:57 PM
- edited on
07-01-2021
04:41 PM
by
Claudia.Landiva
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: 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:
sun.security.validator.ValidatorException:
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.
keytool -import -alias <any_alias> -file <path_to_root_cert> -keystore <controller_home>/appserver/glassfish/domains/domain1/config/cacerts.jks
If this is a SaaS controller, 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.
Useful information. Thanks.
Pleased to know it's useful, @Mondli.Mabaso! Thanks for letting us know.
C: @Eric.Hansen
Thank you! Your submission has been received!
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form