AppDynamics Platform: Best Practices and Guidance for SNI Checks

[#1]

• SNI checks
• How it works
• SNI Checks in AppDynamics components
• Resolving Issues with AppDynamics SNI checks
• Verifying hostname configurations to ensure proper functionality of SNI (Server Name Indication) che...
• Disabling the SNI checks.
• On-prem environments.
• 1. Event Service
• 2. Controller
• 3.EUM server
• OVA environments.
• 1. Event Service OVA component
• 2. Controller OVA component
• 3. EUM OVA component

SNI checks

An SNI (Server Name Indication) check is a security validation performed during the TLS (SSL) handshake. It verifies that the hostname a client is trying to connect to matches one of the domain names listed in the server's SSL certificate. This mechanism allows a single server to host multiple secure websites on the same IP address, as the client explicitly indicates which website it intends to reach, enabling the server to present the correct certificate.

How it works

SNI works by having the client include the hostname it is trying to connect to at the very beginning of the TLS handshake process.

1. Client Initiates TLS Handshake,
2. ClientHello Message with SNI. As mentioned above, as part of the initial "ClientHello" message, the client includes an SNI extension. This extension contains the domain name (hostname) of the server it intends to reach.
3. Server Selects Certificate. The destinaction server receives the ClientHello message and, using the hostname provided in the SNI field, identifies which of its multiple SSL certificates is appropriate for that specific domain. It then iterates through the certificates avlible in the trustore, and examines their Subject Alternative Name (SAN) field. The SAN field can contain multiple DNS entries (domain names). The server looks for a direct match between the SNI hostname and any of the DNS entries in the certificate's SAN field.
4. Server performs the SNI checks
   1. If there is no match between the Hostname received in the ClientHello Message and the certificate SAN list, the server throws SNI Error,
   2. If there is a match between the Hostname received in the ClientHello Message and the certificate SAN list, the Server Presents Correct Certificate. The server than sends back the correct SSL certificate to the client. The rest of the TLS handshake proceeds as usual, establishing a secure, encrypted connection.

SNI Checks in AppDynamics components

The newest version of AppDynamics components usually come bundled with the Java 17 version. OpenJDK 17 and later versions enforce SNI restrictions more strictly than previous Java versions. Java 17+ enforces that SNI hostnames must contain at least one dot, unlike Java 11 (and lower) which was less restrictive. This means that even if Jetty's internal SNI logic hasn't changed drastically, the underlying Java platform's behavior can make SNI checks appear stricter.

Upgrading, for example, the AppDynamics Event Service to a version that utilizes Java 17 can lead to Server Name Indication (SNI) checks errors, especially if the previous deployment used Java 8. This issue typically manifests in the logs with entries similar to the following:

[ERROR] [quota-cache-refresher-1] [c.a.a.p.event.meter.DefaultMeters] Error attempting to get document fragments used count for account [<account-name>] event type [<event-type>]. Defaulting to [0]
com.appdynamics.analytics.client.common.exceptions.BadRequestRestException: Status code: [400], Message: Invalid SNI

This problem most commonly happens because the server certificate lacks the appropriate Subject Alternative Name (SAN) domain entries. While the same certificate configuration might have functioned correctly with older Event Service versions and services running Java 11 (or older), AppDynamics 24.10 versions (and newer) releases bundle newer Java versions that enforce stricter SNI validation requirements, causing the previous setup incompatible.

Note: SNI will not be sent if the destination host is localhost or an IP address; a hostname is required for the SNI checks to be triggered. This means that if you are using raw IP addresses in your environment, you won't be impacted by an issues with SNI checks.

Resolving Issues with AppDynamics SNI checks

In order to address this issue, you can either fix the hostnames and SAN list in your certificate configuration, or disable the SNI checks for AppDynamics components.

Verifying hostname configurations to ensure proper functionality of SNI (Server Name Indication) checks.

If you want to use the SNI check in your environment for security reasons, you need to ensure that the certificate used by the AppDynamics services contains appropriate hostnames in the CN or SAN sections.

1. First of all, check the exact hostnames with domain names used by your servers in the cluster:

hostname -f
hostname --fqdn

2. Next, check the SAN list in the certificate the server uses for communication:

openssl x509 -in certificate.pem -text -noout

Look for the "Subject Alternative Name" section within the output presented by the command above.

3. Ensure that the Subject Alternative Name within your certificate has appropraite hostnames with domain names configured. The SAN section of the certificate should contain all of the hostnames.domain you are using in your cluster. Example output:

X509v3 Subject Alternative Name:
         DNS:<controller-hostname>.domain.name, DNS:<eum-hostname>.domain.name DNS:<es-node-1-hostname>.domain.name, DNS:<es-node-2-hostname>.domain.name ,DNS:<es-node-3-hostname>.domain.name

Please make sure that the SAN section of your certificate contains the correct hostname, together with the appropriate domain. Java 17+ enforces that SNI hostnames must contain at least one dot, unlike Java 11 which was less restrictive. Make sure that you are using hostnames together with domain names in your environment, in case you want to use the SNI checks appropriately.

Disabling the SNI checks.

You can simply disable the SNI checks by changing the AppDynamics components configuration. Please remember to take a back up of the configuration files before making any changes.

In both on-prem and OVA environments, a service restart is required for configuration changes to take effect. After applying the changes below, restart the environment to ensure the new settings are applied.

If you modify the SNI checks setting for the Event Service only, you only need to restart the Event Service component—there is no need to restart the Controller or EUM. The same applies if you change the SNI checks setting exclusively for the Controller or EUM; only the affected component requires a restart.

On-prem environments.

1. Event Service

You can disable the SNI checks by modifying the 

appdynamics/platform/product/events-service/processor/conf/events-service-api-store.yml

file, and adding disableSniHostCheck: true under the server -> applicationConnectors section. See this link for more details:
https://www.dropwizard.io/en/stable/manual/configuration.html

Sample configuration:

     server:
       applicationConnectors:
         - type: https
           port: ${ad.dw.http.port}
           disableSniHostCheck: true

2. Controller

You can disable the SNI checks by opening the 

<controller_home>/appserver/jetty/etc/jetty-ssl.xml

with an editor, and updating the sniHostCheck value from "default=true" to "default=false":

Before:

<Arg name="sniHostCheck" type="boolean"><Property name="jetty.ssl.sniHostCheck" default="true"/></Arg>

After:

<Arg name="sniHostCheck" type="boolean"><Property name="jetty.ssl.sniHostCheck" default="false"/></Arg>

3.EUM server

You can disable the SNI checks by modifying the

appdynamics/EUM/eum-processor/bin/eum-processor-launcher.vmoptions

file and adding

-Djetty.ssl.sniHostCheck=false

OVA environments.

1. Event Service OVA component

Navigate to the OVA installation directory for the Event Service templates, and edit the following file with text editor:

<OVA installation path>/appd-charts/charts/events/templates/events-service-configmap.yml

Add the disableSniHostCheck: true configuration under the server -> applicationConnector sub-section in `events-service-api-store.yml:` section. See this link for more details:
https://www.dropwizard.io/en/stable/manual/configuration.html

Sample configuration:

     server:
       applicationConnectors:
         - type: https
           port: ${ad.dw.http.port}
           disableSniHostCheck: true

2. Controller OVA component

Navigate to the OVA installation directory for the Controller templates, and edit the following file with a text editor:

<OVA installation path>/appd-charts/charts/controller/templates/controller-configmap.yml

Update the sniHostCheck  value from "default=true" to "default=false" under the jetty-ssl.xml section:

Before:

<Arg name="sniHostCheck" type="boolean"><Property name="jetty.ssl.sniHostCheck" default="true"/></Arg>

After:

<Arg name="sniHostCheck" type="boolean"><Property name="jetty.ssl.sniHostCheck" default="false"/></Arg>

3. EUM OVA component 

Navigate to the OVA installation directory for the EUM templates, and edit the following file with a text editor:

<OVA installation path>/appd-charts/charts/eum/templates/eum-configmap.yml

Add the -Djetty.ssl.sniHostCheck=false configuration under the eum-processor-launcher.vmoptions section.

In case of any issues, feel free to reach out to the AppDynamics support organization for further support.