Your data. Anywhere you go.

New Relic for iOS or Android

Download on the App Store    Android App on Google play

New Relic Insights App for iOS

Download on the App Store

Learn more

Close icon

SSL Certificate Update for - FAQs


SSL Certificate Update for - FAQs

On Monday, April 9, 2018 between 10 AM - 11 AM PDT, New Relic will be updating the certificate for *

Ruby APM agents will be impacted.

  • Ruby agent - versions older than (Link to update your Ruby agent)
    If you are using this version of the Ruby APM language agents action is required

What is this change?

Following industry best practice, New Relic secures communications between customers and our infrastructure using TLS. Previously Symantec’s GeoTrust was used as New Relic’s certificate provider and it will be transitioning to Digicert. This is in response to Chrome’s decision to distrust Symantec issued certificates (

Why are we updating the * SSL certificate?

SSL Certificates have a certain period of validity and must be replaced every couple years if not sooner. We are replacing the certificates for the domains above ahead of the Chrome 77 beta release because they are nearing their certificate expiration date. New Relic is completing this routine update to ensure connections continue to be secure and trusted by clients.

What is the timing for this change?

On Monday, April 9, 2018 New Relic will begin using a new certificate for * Customers should prepare for this update, as it may require action on your end.

How will this impact me?

Customers should ensure their agents are up to date and properly configured to guarantee uninterrupted service. In most cases, New Relic agents will rely on the system’s certificate store for what certificates they should trust. However, in some cases, New Relic packages a certificate bundle in the agent and this is used in place of a system’s certificate store.

If you or your organization have security policies/procedures in place to modify what certificates your agents, browsers, etc. can trust, then you should make sure that the new chain will be trusted.

After the update is made, if your system/agent does not have the new root in it’s trust store, then data will be lost until the new root is trusted.

In order to help customers identify if they will be impacted, New Relic has set up an endpoint with this new certificate for you to test against, see below:


curl -v

Invoke-WebRequest -Verbose -Uri

Thank you and feel free to ask questions below.

SSL certificate updates: (April 2018)
Cloned Servers Stay Active But Source Servers Become NOT REPORTING (DEV-839)

will the infra agent be affected?


Will this change impact synthetics?


Hi there, we use the JAVA Agents. Can you tell me starting on which version the new CA is included? We would like to check if any of our 3000 java containers use an older newrelic agent that would stop working.

Thanks & Regards


Echoing what Reto posted, having to update our agents would be a huge task for my team too. Would be very helpful to know what version of Java agent, as well as Servers and Infrastructure, have the new CA.
Also, is there an easy way to tell whether an agent is using the system cert or its own?


Will it have impact to Java and NodeJS agents?


Do we need to update mobile Agents to latest before that date?


Hi @ashraf.jaddo, @vipul, @szymansm, @reto.lehmann -

To clarify, Infrastructure, Synthetics, Servers, and Mobile will not be affected by this update. They all use the built-in certificate store.

Java agents may be impacted if you have altered the configuration to the JVM trust store in a way that is not standard. You can read more about configuring your SSL certificates here.

Regarding the node agent: previous to v1.4.0, the Node agent did not have SSL support. Beginning with v1.4.0 the Node agent bundles it’s own certificate bundle, which we have confirmed has the correct root certificate. You can view the node release notes here.


What about .net agent? We still have few 5.12.13 that are hard to update rapidly.
From what .net agent version the certificate was bundle in the agent?


Hi @cperellis

I believe the v1.4.0 is for the Node.js node agent.
Can you please share the version for the java node agent that has this bundled as well?



Hi @guy_roy and @Kirti.Lalwani -

For the Java agent, the default JVM trust store has contained the Digicert cert by default for all versions of Java beginning with v1.6. You can view the Java release notes here.

.NET uses the systems built in trust store, and there is no certificate bundled with it. We highly recommend .NET customers that customize the system built in trust store to verify their system trust store contains the Digicert root certificate by running the connection test mentioned above.


PST is not active right now. Is the change occurring at 10 AM PST or 10 AM PDT?


There was a banner on the site last week that referenced this change (I opted to hide it), but others on my team never saw it. Was the banner removed already?


Good catch, @cgerken! The update will begin at 10 AM PDT. The post has been updated to reflect that time. Additionally, we’ll be continuing to post banner notifications for a few days at a time leading up to the update, but the banner has been removed at this time.


Hey there,

Will this affect the Python agent too?


Hi @kirkiris - Customers using Python agent versions greater than v2.58.2 (released in November 2015) should not be impacted by this update.


We are using Newrelic PHP agents, servers and infrastructure. Is there any impact on PHP newrelic agent ? All servers are ubuntu & Amazon linux
Newrelic rpm versions
New Relic Version (“pipher” - “22bc2bd494bc”)
New Relic Version (“yershova” - “5fedc700f64a”)
New Relic Version (“driscoll” -

  1. We have some custom plugin agent’s using the ruby plugin SDK , would that be affected .
  2. We are using defaults for Java agent so have not configured anything related to SSL , can you tell me what is the default value for property ‘use_private_ssl’.


Hi there - Ruby’s default behavior is to default to the system certificate store. There is no impact to Ruby plugins as long as your system default certificate contains Digicert. You can test this using the connection test linked above.

The default behavior for use_private_ssl is false, and the default JVM certificate store included with Java contains the necessary certificate. As long as you’re not customizing the JVM certificate store, no action should be necessary.


The cert bundle has been in our PHP agent since 2014, so you should be all set! No action required for those versions.