KB 242 - PowerConnect Cloud Outbound TLS Connection Verification

KB 242 (CLOUD): PowerConnect Cloud Outbound TLS Connection Verification

TLS verification for outbound connections

Applies to: 9.2.0 · Category: Security · Action required: none for most deployments

Do you need to do anything?

Likely not. Anything reached over a publicly trusted certificate - Splunk Cloud,
Dynatrace SaaS, and any endpoint with a certificate from a public CA -
continues to work with no configuration change.

The one-minute check: list the endpoints your outputs target. If every one is a
public SaaS service, or an internal endpoint whose certificate was issued by a public CA,
there is nothing to do.

Only these need attention before upgrading:

• Dynatrace ActiveGate still using the self-signed certificate it ships with, rather
  than one issued by your own CA

• On-premise Splunk (indexers, heavy forwarders, HEC) using a self-signed or internal-CA
  certificate

• Any endpoint whose certificate comes from a corporate CA that is not in the Java trust
  store

For those, decide in advance whether you will import the certificate or assign a dedicated
profile, and have the certificate file to hand. Everything below is for that case only.

Where a certificate cannot be validated, the connection fails and logs:

Server certificate not trusted by cacerts or the imported certificates

What changed

9.2.0 introduces connection profiles - reusable HTTP settings (proxy, TLS, pooling,
timeouts, retries) that inputs and outputs select between, managed under
Configuration → Connections.

TLS is now part of that configuration, and certificate verification is applied
consistently across all outbound connections. Both built-in profiles - Default (inputs)
and Default (outputs) - ship with verification enabled, and it can be adjusted per
profile where an endpoint requires it.

What to do if an endpoint is affected

Recommended: import the endpoint's certificate from the failed test

You do not need to obtain the certificate yourself. Edit the affected input or output and
press Test:

1. The test fails, and a Certificate tab appears showing the certificate the endpoint
   presented - subject, issuer, alternative names, expiry and SHA-256 fingerprint - along
   with why it was rejected.

2. Check the fingerprint against the endpoint. This is the one step that matters: it is
   what tells you the certificate is the endpoint's own and not something in the middle.

3. Press Import Certificate.

The certificate is then trusted in addition to the standard public CAs, and affected
connections pick it up without restarting the engine. In a clustered deployment the import
is replicated to every node automatically; it only needs to be done once, on any node.
Press Test again to confirm.

Importing requires an administrator, and the tab appears for inputs and outputs that
connect over HTTP. Where the connection profile routes through a proxy the certificate
cannot be read this way, and the tab says so.

Alternative: upload the certificate by hand

Where the above does not apply - a proxied endpoint, or preparing before the upgrade:

1. Export the certificate from the endpoint (for ActiveGate, the certificate it presents
   on its HTTPS port).

2. Go to Configuration → Certificates → Import Certificate and upload it.

Both routes end in the same place, and both keep verification enabled.

Note on hostname matching. Importing establishes trust, but the hostname you connect
to must also match the certificate's Common Name or Subject Alternative Name. Where it
cannot — a Dynatrace ActiveGate's default certificate is issued to
*.clients.dynatrace.org regardless of the hostname it answers on - create a dedicated
connection profile for that endpoint and tick Accept an imported certificate on any
hostname.

That option keeps certificate verification on: the endpoint must still present a
certificate you imported, which requires its private key. It only stops the name being
checked, and only for the inputs and outputs assigned to that profile.

Use a dedicated profile rather than a default one. The option applies to every
certificate you have imported, so on a shared profile the holder of any imported
certificate's key could impersonate any endpoint that profile connects to.

If the endpoint's certificate is later replaced, import the new one — connections fail
until you do. Dynatrace documents replacing the ActiveGate self-signed certificate with
your own, which remains the better long-term option.

Last resort: relax verification for that endpoint only

If importing a certificate is not practical by either route above:

1. Go to Configuration → Connections and create a new connection profile — for
   example dynatrace-activegate.

2. Tick Disable TLS verification (insecure).

3. Assign that profile to the specific inputs or outputs that target the endpoint.

Create a dedicated profile rather than changing Default (outputs). Editing a built-in
default applies to everything that inherits it, including connections to public endpoints.