🚨 Telegraf Error Guide: 'outputs.influxdb x509: certificate signed by unknown authority' — Fix TLS

Overview

When Telegraf writes to InfluxDB over HTTPS, it validates the server certificate against a trusted CA set. If the signing CA is not trusted, the TLS handshake fails before any metric is sent:

E! [outputs.influxdb] When writing to [https://influxdb:8086]: Post "https://influxdb:8086/write?db=telemetry": x509: certificate signed by unknown authority

Related TLS handshake failures from the same plugin:

E! [outputs.influxdb] ... x509: certificate is valid for influxdb.internal, not influxdb
E! [outputs.influxdb] ... x509: certificate has expired or is not yet valid

These are retryable connection errors — Telegraf buffers and retries — but no data will ever land until trust is established.

Symptoms

• x509: certificate signed by unknown authority every flush over an https:// URL.
• curl to the same URL without --cacert also fails; with the CA it succeeds.
• InfluxDB uses a self-signed cert or one issued by an internal/private CA not in the system trust store.
• Works on a host with the CA installed, fails on one without it.

Common Root Causes

• Private/internal CA not trusted by Telegraf’s host or container.
• Self-signed InfluxDB certificate with no tls_ca configured in the plugin.
• Missing intermediate certificate — the server sends a leaf but not the intermediate that chains to the root.
• tls_ca path wrong or unreadable by the Telegraf user.
• SAN/hostname mismatch (valid for X, not Y) — connecting by an address not in the certificate’s SANs.
• Expired certificate on the InfluxDB side.

Diagnostic Workflow

Inspect the certificate the server actually presents and its chain:

openssl s_client -connect influxdb:8086 -servername influxdb </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -subject -dates -ext subjectAltName

Note the issuer (the CA) and the SANs. Reproduce the trust check with curl:

# Fails the same way as Telegraf if the CA is untrusted
curl -i --cacert /etc/telegraf/ca.pem \
  -XPOST "https://influxdb:8086/write?db=telemetry" --data-binary 'probe value=1'

Point the plugin at the CA bundle that signed the InfluxDB cert:

[[outputs.influxdb]]
  urls = ["https://influxdb:8086"]
  database = "telemetry"
  tls_ca = "/etc/telegraf/ca.pem"
  # insecure_skip_verify = true   # last resort, disables verification

Confirm the Telegraf user can read the CA file:

sudo -u telegraf test -r /etc/telegraf/ca.pem && echo readable || echo "unreadable by telegraf"

If curl --cacert succeeds but Telegraf still fails, the tls_ca path or permissions are wrong. If the error is valid for X, not Y, connect using a hostname present in the SANs rather than adding insecure_skip_verify.

Example Root Cause Analysis

An organization rotated its internal CA and re-issued the InfluxDB certificate. Telegraf agents immediately logged x509: certificate signed by unknown authority. openssl s_client showed the new issuer was the rotated CA, whose root was not yet distributed to the Telegraf hosts. curl with the old ca.pem failed; with the new root it returned 204. The fix was to push the new root bundle to /etc/telegraf/ca.pem via config management and reload Telegraf. They also switched tls_ca to reference the OS trust anchor directory kept current by the CA-distribution tooling, so future rotations propagate without touching Telegraf config.

Prevention Best Practices

• Distribute your internal CA root to every Telegraf host’s trust store (or a pinned tls_ca) via config management, and update it on CA rotation.
• Ensure InfluxDB serves the full chain (leaf + intermediates), not just the leaf.
• Issue certificates with SANs covering every address Telegraf uses to connect, so you never need insecure_skip_verify.
• Treat insecure_skip_verify = true as a temporary diagnostic only; it disables authentication of the server and exposes credentials to MITM.
• Monitor certificate expiry and alert well before renewal to avoid has expired handshake failures.

Quick Command Reference

# Inspect the served cert, issuer, SANs, and dates
openssl s_client -connect influxdb:8086 -servername influxdb </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -subject -dates -ext subjectAltName

# Reproduce the trust check
curl -i --cacert /etc/telegraf/ca.pem \
  -XPOST "https://influxdb:8086/write?db=telemetry" --data-binary 'probe value=1'

# Confirm Telegraf can read the CA
sudo -u telegraf test -r /etc/telegraf/ca.pem && echo readable || echo unreadable

# Watch for the error live
journalctl -u telegraf -f | grep x509

Conclusion

outputs.influxdb x509: certificate signed by unknown authority is a TLS trust failure: Telegraf does not trust the CA that signed InfluxDB’s certificate. Inspect the chain with openssl s_client, reproduce with curl --cacert, and point tls_ca at the correct CA bundle — distributing your internal root to every host rather than resorting to insecure_skip_verify. For SAN mismatches, connect by a name in the certificate. For plain (non-TLS) connectivity failures, see the could not write guide. More fixes in the Telegraf guides.