🚨 OpenTelemetry Error Guide: 'x509: certificate has expired or is not yet valid' — Fix OTLP TLS Certs

Overview

This error appears when the exporter trusts the CA and the hostname matches, but the certificate is outside its validity window — either it has expired or the client’s clock is set before the cert’s notBefore time. It shows up in SDK stderr and in the Collector’s otlp exporter logs:

error	exporterhelper/queue_sender.go:128	Exporting failed. Dropping data.	{"kind": "exporter", "data_type": "traces", "name": "otlp", "error": "rpc error: code = Unavailable desc = connection error: desc = \"transport: authentication handshake failed: x509: certificate has expired or is not yet valid: current time 2026-07-12T09:14:03Z is after 2026-07-01T00:00:00Z\""}

The HTTP/OTLP variant reads:

traces export: Post "https://otel-gateway.example.com:4318/v1/traces": tls: failed to verify certificate: x509: certificate has expired or is not yet valid: current time 2026-07-12T09:14:03Z is after 2026-07-01T00:00:00Z

x509: certificate has expired or is not yet valid: current time ... is after ... means TLS verification failed on time: the server cert (or an intermediate) is expired, or a skewed client clock puts “now” outside the valid range.

Symptoms

• Exports that worked yesterday fail fleet-wide starting at a specific timestamp — the moment a cert expired.
• The error prints the current time and the boundary (is after for expiry, is before for not-yet-valid).
• A “not yet valid” variant appears only on hosts with a clock set in the past (bad NTP).
• openssl x509 -noout -dates shows a notAfter in the past or a notBefore in the future.
• Rotating the cert or fixing NTP immediately restores exports.
• Both the leaf and any intermediate in the chain must be in-window; an expired intermediate triggers it too.

Common Root Causes

• Expired leaf certificate — the Collector’s server cert passed its notAfter and was never rotated.
• Expired intermediate CA — a mid-chain cert expired even though the leaf looks valid, failing the whole chain.
• Client clock skew — the exporter host’s clock is wrong (NTP down), so a valid cert reads as expired or not-yet-valid.
• Missed renewal automation — cert-manager or a cron rotation stalled, so the cert lapsed silently.
• Freshly issued cert with a future notBefore — deployed before its validity window opens, on a host whose clock is behind.
• Stale cert baked into an image — a container image pinned an old cert that expired after the image was built.

Diagnostic Workflow

First read the certificate’s validity window straight from the endpoint and compare it to the host’s clock:

# What window is the presented cert valid for?
openssl s_client -connect otel-gateway.example.com:4317 -servername otel-gateway.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -dates -subject

# What does this host think the time is, and is NTP synced?
date -u
timedatectl status | grep -i 'System clock\|NTP'

If notAfter is in the past, the cert is genuinely expired — rotate it. If the dates are fine but the host clock is wrong, fix time sync first:

# Correct clock skew (systemd-timesyncd)
sudo timedatectl set-ntp true
sudo systemctl restart systemd-timesyncd

After rotating certificates on the Collector, point the receiver and exporter at the new files. The receiver serves the fresh leaf and key:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
        tls:
          cert_file: /etc/otelcol/certs/server.crt   # freshly rotated leaf + chain
          key_file: /etc/otelcol/certs/server.key

Exporters trust the (possibly new) CA. If you rotated the CA as well, ship the new bundle before the leaf expires:

exporters:
  otlp:
    endpoint: otel-gateway.example.com:4317
    tls:
      insecure: false
      ca_file: /etc/otelcol/certs/server-ca.crt      # includes valid intermediates

Validate and confirm the error clears:

otelcol-contrib validate --config /etc/otelcol/config.yaml
journalctl -u otelcol-contrib --since '10 min ago' | grep -i 'expired\|not yet valid\|x509'

Example Root Cause Analysis

Traces stopped arriving from every agent at exactly 00:00 UTC on July 1st. The Collector’s otlp exporter logs filled with x509: certificate has expired or is not yet valid: current time ... is after 2026-07-01T00:00:00Z. Running openssl x509 -noout -dates against the gateway showed a notAfter of 2026-07-01T00:00:00Z: a one-year manually issued cert had lapsed, and the renewal ticket had been missed.

The fix had two parts. First, the gateway’s leaf and intermediate were reissued with a fresh window, and the receiver’s cert_file/key_file were updated and the Collector reloaded, which restored exports within minutes. Second, to prevent a repeat, the team moved issuance to cert-manager with a 90-day cert and auto-renewal at 30 days remaining, and added an alert on certificate expiry so a lapse would page days ahead instead of causing a hard outage at midnight.

Prevention Best Practices

• Automate certificate issuance and renewal (cert-manager or ACME) so certs rotate well before notAfter.
• Alert on days-to-expiry for both leaf and intermediate certs, paging at least a week ahead of expiry.
• Keep NTP running and monitored on every exporter and Collector host so clock skew never fakes an expiry.
• Prefer short-lived certs with automated rotation over long manual ones that invite missed renewals.
• Rotate the CA bundle to clients before the old chain expires so exporters never lose trust mid-rotation.
• Don’t bake certs into container images; mount them from secrets so a rebuild isn’t required to rotate.

Quick Command Reference

# Read the presented cert's validity window
openssl s_client -connect otel-gateway.example.com:4317 -servername otel-gateway.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -dates -subject

# Check this host's clock and NTP sync
date -u; timedatectl status | grep -i 'NTP'

# Force NTP resync if the clock is skewed
sudo timedatectl set-ntp true

# Validate config after rotating certs
otelcol-contrib validate --config /etc/otelcol/config.yaml

# Watch the expiry error clear
journalctl -u otelcol-contrib -f | grep -i 'expired\|not yet valid'

Conclusion

x509: certificate has expired or is not yet valid: current time ... is after ... is a validity-window failure, and it has exactly two causes: a lapsed certificate or a wrong clock. Read the window with openssl x509 -noout -dates and compare it to the host’s synced time. If the cert expired, rotate the leaf and any intermediate and reload the Collector; if the clock is skewed, fix NTP. The permanent cure is automated, short-lived certificates with expiry alerting and healthy time sync — so a midnight cert lapse never becomes a telemetry outage.

Related

• OpenTelemetry Error Guide: ‘x509: certificate signed by unknown authority’
• OpenTelemetry Error Guide: ‘connection refused’ to the Collector
• OpenTelemetry Error Guide: ‘no more retries left; dropping data’