Important: Upcoming New Relic server certificate update will impact most users of Java agent version 6.1, and a few users of Java agent version 6.2.0 to 6.4.2

Summary: On April 12 (changed from April 6) at approximately 10am Pacific Time, New Relic will be updating the certificate for *.newrelic.com.

This should not impact you, unless you are using Java agent v6.1; or, in a rare agent configuration, if you are running Java agent v6.2 to 6.4.2.

Background

Java APM agents v6.1.0 to v6.4.2 shipped with an included SSL certificate from New Relic that, if configured, could be used as an alternative to the SSL certificates provided by the OS or JRE/JDK trust stores.

This certificate will expire in April 2021. If your agent is using this certificate, you will be affected, as the agent will no longer be able to establish a secure connection to New Relic.

Who is affected?

  • Almost all services using Java agent v6.1 are affected.

    • The only exception to this is if the agent configuration file has ca_bundle_path to specify the path to a certificate bundle. This is not the default configuration.
  • Java agent v6.2 to 6.4.2 versions are affected ONLY if the use_private_ssl configuration in the newrelic.yml is set to true.

    • This is not the default setting, only a few accounts have agents using this setting.
  • Earlier Java agent versions are not affected.

  • Other agents are not affected.

How can I check if I am affected?

We’ve implemented a change to catch affected agents. As of March 27th at 3pm UTC , all agents will have gone through a connect cycle and if an agent is affected, it will be identified by this change. At that point:

  1. Logs of affected agents will include a message ACTION IS REQUIRED - YOUR AGENT WILL FAIL TO CONNECT AFTER…

  2. Running the following query on a Master account will give you a full list of impacted services on all sub-accounts, this query can also be run on individual sub-accounts:

    SELECT * FROM NrIntegrationError WHERE name = 'ConfigurationChangeRequired' LIMIT MAX SINCE 3 days ago

At any time (not affected by the change above), you can use the following query from your master billing account to check for all Java agent v6.1 across your master and all sub-accounts:

  • FROM NrDailyUsage SELECT consumingAccountId, apmAppName SINCE yesterday WHERE productLine='APM' WHERE apmLanguage='java' AND usageType = 'Application' WHERE apmAgentVersion = '6.1.0' LIMIT MAX

And, you can use the following query to check the agent versions within an account:

  • SELECT * FROM ApplicationAgentContext WHERE agent.language = 'java' LIMIT MAX SINCE 1 week ago

If I am affected, what steps do I need to take ?

We recommend that you immediately take action to avoid any downtime. The options are detailed below depending on the agent version that you are currently using:

  • Java agent v6.1.0: If neither config option (use_private_ssl/ca_bundle_path) is specified, the default behavior of the agent should be to use the truststore bundled with the JRE/JDK. However, because of a configuration bug in this agent version, it will use the shipped certificate by default and fail the SSL handshake. Solutions:

    • Upgrade to a newer version of the agent (v6.2.0+) that addresses the configuration bug, in which case the agent will use the JRE/JDK truststore by default (unless use_private_ssl or ca_bundle_path are explicitly configured).

    • Or, continue to use Java agent v6.1.0 by explicitly using ca_bundle_path to specify a custom certificate bundle and override the default behavior, thereby avoiding use of the certificate shipped with the Java agent. If needed, the DigiCert Global Root CA certificate can be downloaded and used by the agent to establish a secure connection.

  • Java agent v6.2.0 through 6.4.2: If neither config option (use_private_ssl/ca_bundle_path) is specified, the default behavior of the agent will be to use the truststore bundled with the JRE/JDK.

    • If you are currently using the use_private_ssl configuration, simply remove it or set it to false and let the agent use the JRE/JDK truststore by default.

    • Or, explicitly use ca_bundle_path to specify a custom truststore and override the default behavior, thereby avoiding using the certificate shipped with the Java agent. If needed, the DigiCert Global Root CA certificate can be downloaded and used by the agent to establish a secure connection.

Note: future versions of the Java agent will no longer include security certificates, and will remove the use_private_ssl configuration.

Why are we updating the *.newrelic.com SSL certificate?

SSL Certificates have a certain period of validity and must be replaced regularly. New Relic is completing this routine update to ensure connections continue to be secure and trusted by clients.

For more information, see Networks | New Relic Documentation

Thank you and feel free to ask questions below.

6 Likes

Hello,

Does it affect java agent versions < 6.1 if use_private_ssl is set to true and a ca_bundle_path is in use?
Please note that we are not explicitly trusting the DigiCert Global Root CA certificate currently.

1 Like

No, it does not affect Java agent versions before 6.1 - note that 6.0 did not include an SSL certificate. Java agent versions <6.0 shipped with a certificate will continue to be valid for connection to New Relic after the *.newrelic.com certificate update.

What’s impact for the apps which use java agent 6.1 don’t have the above action?

Will it cause the app to crash or just not able to report app metrics to NewRelic?

Thanks!

Kelvin Li

Manulife

Hello, we are under v5.11.0 and as I see we seems to not be affected but login into our account we see the warning message and your message specify that if we see the message, we are indeed affected

I’m quite confused

Are we affected or not ?

Best regards

1 Like

We have a customers with a big set mobile devices which run Android 5.1 (API level 22) so we’re can’t update to agent version 6+ because that’s only compatible for Android 7+
Will there also be an update for the agent version 5 to still support Android 4/5 devices?

My application in Newrelic is using agent 5.8.0 with use_private_ssl: true and 6.4.1 I do not see the use_private_ssl tag in the newrelic.yml

Same for me too . am using apm Java agent version 5.9.0 still receiving this alert message. Is it going to affect if I do not upgrade within the time specified?

Here at WW we are using agent version 6.4.2.
Our newrelic.yml does NOT have use_private_ssl or ca_bundle_path
Why would our service be flagged with this notification?

Hi @Kelvin_J_Li,

It will just not be able to establish a connection to New Relic. Application performance data collected by the agent will be lost.

Jodee

1 Like

Hi @craynaudcoco-ext, @shagufa.nausheen, @wasiyur.shariffn, @david.lu,

The initial warning message was too broad. This was quickly fixed. You should no longer be seeing any warning message unless you do indeed have a Java agent of version and configuration settings that need updating.

If you are still seeing the message, try the query in the account that is displaying the message:

  • SELECT * FROM NrIntegrationError WHERE name = 'ConfigurationChangeRequired' LIMIT MAX SINCE 3 days ago
    `

is there way we can query this field use_private_ssl fi this has been set as true or false ?
Java agent v6.2 to 6.4.2 versions are affected ONLY if the use_private_ssl configuration in the newrelic.yml is set to true .

Thank you for your confirmation! @jvarney

1 Like

Let us know if you need anything else!

@Satya.Prakash You can see it on the Environment page for a given service. You can’t query it directly.

But, you can use this query to find all services in an account that are affected, the ‘ConfigurationChangeRequired’ event is driven by the specific agent version and configurations that are affected:

  • SELECT * FROM NrIntegrationError WHERE name = 'ConfigurationChangeRequired' LIMIT MAX SINCE 3 days ago

so this ^^ can be used and then filtered by agent versions that are NOT 6.1.0 and you will get a list of services using java agent v 6.2.0 to 6.4.2 that have use_private_ssl set to true.

If our agents are configured to use a proxy to access the new relic collectors via ssl, need we be concerned at all?

Example config:
-Dhttp.proxyHost=squid.xx.xxx, -Dhttp.proxyPort=3128, -Dhttps.proxyHost=squid.xx.xxx, -Dhttps.proxyPort=3128

@jgillotti it all depends on your agent configuration - if you are using one of the affected agent versions and have the configuration set as mentioned to use the bundled certificate, then you will be impacted by the issue - even if you use a proxy.

Hi Joedee,
Thanks for confirmation.

Given that it’s a short notification and the internal requirement for change management process, can we extend the ssl certificate renewal 1 or 2 weeks later? We have about > 350 apps requires app re-stage which causes app downtime.

Is the cert ( *.newrelic.com) renewal is global or specific to customer? I believe our apps are using collector.newrelic.com to send application metrics.

Thank you!

Kelvin J Li

Manulife

Can I know if this affects app after April 12th if we didn’t update agent version .?

Hi @Kelvin_J_Li , unfortunately the expiration is an inherent part of the certificate definition - there is no way to extend it, it has to be replaced.

1 Like