The domain name of a Dynatrace Managed cluster is not a cosmetic detail. It is the address your users type, the one hundreds of OneAgents carry to reach the cluster, the one referenced by ActiveGates, DynaKube resources, automation scripts and API integrations. And it is the Dynatrace Managed SSL certificate bound to that name that assures all these clients they are really talking to your cluster.
In many installations, the cluster starts with the dynatrace-managed.com subdomain and certificate managed automatically by Dynatrace (or, without that automatic management, a self-signed certificate), and the switch to a proper name such as dynatrace.{your-company}.com with a certificate from the internal authority is left for « later ». That later often arrives as an emergency: browser warnings, a security policy that bans untrusted certificates, or a certificate that expires on a Monday morning.
This article explains how to choose the cluster’s domain name, prepare and install an SSL/TLS certificate, and organise renewal so that it never becomes an incident again.
Understand who connects to what
Before changing anything, map out the clients of the domain name:
- Users’ browsers: CMC and environments at
https://{your-domain}/e/{environment-id}. - OneAgents: they connect to the cluster nodes or to ActiveGates, depending on the list of communication endpoints they receive.
- ActiveGates: Cluster ActiveGates (port 9999 by default) often act as the entry point for agents outside the cluster’s network.
- API clients: automation on
https://{your-domain}/api/cluster/v2/…and…/e/{id}/api/v2/…. - Kubernetes:
apiUrlin eachDynaKube(see Dynatrace Operator with Managed).
A name change affects all these clients; a certificate change affects every client that verifies the chain of trust.
Choosing the domain name and the Dynatrace Managed SSL certificate
The name
Choose a stable name, independent of the nodes’ hostnames, that can survive a server replacement or a cluster expansion. Your DNS resolves this name to a load balancer in front of the nodes, or directly to the nodes (multiple records).
The certificate type
| Option | Pros | Cons |
|---|---|---|
| Automatic management (dynatrace-managed.com subdomain) | No effort, trusted certificate | Imposed name, depends on the Mission Control connection |
| Self-signed (automatic management turned off) | No effort | Browser warnings, rejected by strict clients |
| Internal corporate PKI | Trusted by internal workstations and servers | Root must be distributed to clients outside the domain (containers, partners) |
| Public authority | Trusted everywhere | Public name required; poorly suited to a purely internal cluster |
The certificate must cover the cluster name in the Subject Alternative Name (SAN) field. If OneAgents also reach the nodes by their own names, include those names in the SAN. The certificate is in fact installed node by node in the CMC, and the documentation suggests one subdomain per node (n01.{your-domain}…) for load-balancer routing.
Step-by-step tutorial
Step 1 — Create the DNS record
Create the record for {your-domain} and check resolution from a user workstation, a cluster node and a monitored host:
dig +short {your-domain}
getent hosts {your-domain}
Step 2 — Generate the key and certificate signing request
On a secure admin workstation, create an OpenSSL configuration file that includes the SAN:
cat > csr.cnf <<'EOF'
[req]
distinguished_name = dn
req_extensions = ext
prompt = no
[dn]
CN = {your-domain}
O = {your-organisation}
[ext]
subjectAltName = DNS:{your-domain},DNS:{node-name-1},DNS:{node-name-2}
EOF
openssl req -new -newkey rsa:2048 -nodes -keyout cluster.key -out cluster.csr -config csr.cnf
openssl req -in cluster.csr -noout -text | grep -A1 "Subject Alternative Name"
Submit cluster.csr to your PKI. Protect the private key (chmod 600 cluster.key) and never send it by email.
Step 3 — Prepare the full chain
Combine the server certificate and the intermediate certificates, then check that the key and certificate match:
cat cluster.crt intermediate.crt > cluster-fullchain.pem
openssl x509 -in cluster.crt -noout -subject -enddate
openssl x509 -in cluster.crt -noout -modulus | sha256sum
openssl rsa -in cluster.key -noout -modulus | sha256sum
The two fingerprints must be identical. The CMC expects PEM files with full BEGIN/END headers and an unencrypted private key; if yours is password-protected:
openssl rsa -in cluster-encrypted.key -out cluster.key
Step 4 — Declare the domain name in the CMC
In the Cluster Management Console, first turn off Manage domain name and SSL certificates (Settings > Preferences), then open Settings > Public endpoints and enter {your-domain} as the usual address of the web interface. In your DNS, create an A record pointing to each node. This setting drives the generated URLs (links in notifications, SAML metadata, installers).
Step 5 — Install the certificate
Still in the CMC, from the home page, open each node, then Edit SSL certificate on its details page: paste the private key, the server certificate and the chain (root and intermediates), then save. Repeat for each node. If a load balancer terminates TLS in front of the cluster, the certificate is installed on the load balancer; in that case, make sure traffic to the nodes stays encrypted and that the forwarded headers match the documentation. To be safe, schedule the operation in a maintenance window.
Step 6 — Check from the clients
openssl s_client -connect {your-domain}:443 -servername {your-domain} </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -enddate
curl -sS -o /dev/null -w "%{http_code}\n" --cacert {pki-root}.pem \
-H "Authorization: Api-Token {token}" \
"https://{your-domain}/e/{environment-id}/api/v2/entities?entitySelector=type(%22HOST%22)&pageSize=1"
Then check in an environment that OneAgents and ActiveGates stay connected. For Cluster ActiveGates, also check the certificate exposed on their port (9999 by default).
Step 7 — Update clients that reference the old name
-
apiUrlof theDynaKuberesources:https://{your-domain}/e/{environment-id}/api. - URL variables in your pipelines and automation tools.
- PKI root added to the trust stores of containers and servers outside the domain.
Best practices
- A stable, generic name, decoupled from the nodes’ hostnames.
- Expiry alert at least 30 days before the deadline, for example via a synthetic monitor or a scheduled
opensslscript. - A tested renewal runbook, listing the components involved (cluster, load balancer, ActiveGates).
- A protected private key, stored in a vault, never in a code repository.
- Always supply the full chain: a missing intermediate is the most common cause of client-side errors.
Frequently asked questions
What should the certificate’s SAN field contain?
At least the cluster name. If OneAgents also reach the nodes by their own names, add those names to the SAN or plan one certificate per node, depending on your architecture.
Why do clients reject a certificate that is valid?
Most often the chain is incomplete: the intermediate certificate was not supplied. Another common cause is the internal PKI root missing from the trust store of containers or servers outside the domain.
How do I stop expiry from catching me out?
Set an alert at least 30 days before the deadline, with a synthetic monitor or a scheduled openssl script, and keep a renewal runbook listing the cluster, load balancer and ActiveGates.
Conclusion
A well-chosen domain name and a certificate issued by a trusted authority turn your Managed cluster from a technical tool into a trusted enterprise service. By mapping the clients first, checking the chain carefully with openssl and automating expiry monitoring, you turn a dreaded operation into an annual routine with no surprises.
span.observer is an independent community blog, not affiliated with Dynatrace LLC. Dynatrace is a trademark of Dynatrace LLC. Always check values (ports, versions, sizes) against the official documentation for your Managed version.
Originally published on span.observer. French version: https://span.observer/fr/certificats-ssl-domaine-cluster/.
Top comments (0)