reconsider individual trust store certificates

[tlazar]

Description

This is a follow-up to #54, #86, and #89. To summarize, some customers use a custom trust store and then the NewRelic agent fails to trust NewRelic endpoints. (NewRelic is like other SaaS API offerings; customers who remove the standard trust stores will have the same problem with any public API.) The approach taken in your responses and pull requests is to individually trust specific leaf certificates instead of DigiCert Global Root CA, the trust anchor for all NewRelic certificates. That approach has a couple weaknesses:

1. NewRelic has no way to revoke those certificates if compromised since you are defining the leaf certificates as trust anchors
2. Customers who rely on your approach now must upgrade before those certificates expire. newrelic-com.pem expires in less than four months.

Expected Behavior

I would expect one of the following two approaches:

1. Instead of adding the three certificates, include your trust anchor, DigiCert Global Root CA (serial 83BE056904246B1A1756AC95991C74A), which is good until 2031.
2. Remove these additional certificates entirely and advise customers that if they define their own trust stores, they need to include DigiCert Global Root CA in their trust store.

If you are interested in the first proposed approach, I am willing to open a pull request to implement it.

[tspring]

Hi @tlazar , Thanks for the input. I agree it's not a particularly good solution, unfortunately there are company concerns about adding the DigiCert Global Root CA to the agent/application trust store.

The inclusion New Relic specific certs in the trust store are currently gated by the use_private_ssl configuration to alleviate installation/usability issues. I'd be interested in hearinng your thoughts or concerns about this.

That said, I do think our documentation around this should be improved and that use_private_ssl should be discouraged in favor of adding the DigiCert Global Root CA via the ca_bundle_path option and will look into doing that.

[tlazar]

Thanks @tspring for the quick response and for explaining your constraint of not bundling DigiCert Global Root CA with your agent. Customers tinkering with their JRE's trust store should know better than to remove trust anchors and expect their https connections to work, but I understand the need to support customers who misstep.

I like the idea of a NewRelic-specific trust store which differs from the JRE's. I can imagine you have customers where most https endpoints should be internal endpoints with trust anchored only by an enterprise CA, but want to allow the NewRelic agent to use a different anchor.

As a customer, I'll really avoid relying on use_private_ssl to make sure we don't all wake up on April 17 to discover we can no longer publish to NewRelic because we didn't upgrade our NewRelic agent. I also wouldn't want to be forced to upgrade the agent by a few minor versions in dev through prod in a short period. I assume you won't renew the *.newrelic.com certificate much more than 45 days before its expiration and will need some time for the release and distribution process. I realize you may get a limited certificate for only rpm.newrelic.com earlier and, if so, this would be a bit less of a concern.

[jasonjkeller]

As of Java agent 6.5.0 there are no longer any SSL certs bundled with the agent: https://docs.newrelic.com/docs/release-notes/agent-release-notes/java-release-notes/java-agent-650/