Configure custom TLS certificates for SQL Extension Executor pods

• Latest Dynatrace
• How-to guide
• 3-min read
• Published Aug 25, 2026

You can provide TLS certificates to the SQL Extension Executor pod via:

You can also combine both approaches. When both individual certificates and a truststore are provided, the SQL Extension Executor imports the certificate files on top of the provided truststore.

Mount custom certificates

The SQL Extension Executor reads all valid, non-expired certificates found in /app/user/ssl-certs. Any Kubernetes volume type that exposes files at that path works. Common options are Kubernetes Secrets and PersistentVolumes.

The SQL Extension Executor supports certificate bundles in PEM format. In such cases, each certificate within the bundle is imported separately.

spec:
  extensions:
    databases:
    - id: default
      replicas: 1
      volumeMounts:
      - mountPath: /app/user/ssl-certs
        name: user-ssl-certs
      volumes:
      - name: user-ssl-certs
        secret:
          secretName: user-ssl-certs

Mount a custom truststore

If you already manage a PKCS12 truststore, you can mount it directly. To create a new one, follow the same process as described for ActiveGate-based SQL monitoring and mount the file in the location listed below.

spec:
  extensions:
    databases:
    - id: default
      replicas: 1
      volumeMounts:
      - mountPath: /app/user/truststore/
        name: custom-truststore
        readOnly: true
      volumes:
      - name: custom-truststore
        secret:
          secretName: custom-truststore

Automatic certificate reload

When mounted certificate files or the truststore change, the SQL Extension Executor automatically restarts to apply the updated certificates. No manual action is required, and monitoring resumes automatically afterward.

The restart is typically triggered within five minutes of a detected change. Logs for the affected extension configuration show the scheduled time. Brief metric gaps may occur in the meantime.