🚨 Kafka Error Guide: 'CertificateExpiredException' Certificate Has Expired

Exact Error Message

When a certificate in the chain has passed its validity window, the handshake fails with a clear expiry message:

[2026-06-29 06:01:17,455] ERROR [Producer clientId=audit-producer] Connection to node
-1 (broker-01.kafka.internal/10.0.4.21:9093) failed authentication due to: SSL handshake
failed (org.apache.kafka.clients.NetworkClient)

org.apache.kafka.common.errors.SslAuthenticationException: SSL handshake failed
Caused by: java.security.cert.CertificateExpiredException: NotAfter: Sat Jun 27
23:59:59 UTC 2026
    at sun.security.x509.CertificateValidity.valid(CertificateValidity.java:277)
    at sun.security.x509.X509CertImpl.checkValidity(X509CertImpl.java:629)

openssl reports the same condition during verification:

Verify return code: 10 (certificate has expired)

Related variants include “certificate has expired”, CertificateNotYetValidException (a cert not yet valid, often from clock skew), and the fatal alert certificate_expired on the peer.

What the Error Means

CertificateExpiredException means the chain is otherwise well-formed and trusted, but one certificate in it is outside its validity window — its NotAfter date is in the past (or NotBefore is in the future for the “not yet valid” sibling). The TLS layer validates time as part of certificate checking, so even a perfectly trusted CA chain is rejected once any link expires.

This is distinct from a trust failure (PKIX path building failed, where the CA is missing) and a negotiation failure (handshake_failure, where protocols/ciphers do not match). Here, trust and negotiation are fine; only the clock disagrees. The fix is rotation of the expired certificate — or, occasionally, correcting a wrong system clock that makes a valid certificate appear expired or not-yet-valid.

Common Causes

• Expired broker (leaf) certificate — the most common, especially with short-lived certs and a missed rotation.
• Expired client certificate in an mTLS setup, surfacing as a broker-side alert.
• Expired intermediate or root CA, which invalidates everything beneath it at once.
• Failed automated rotation: a cert-manager/ACME renewal that silently stopped, so the old cert ran out.
• Clock skew: a broker or client with a wrong system time treats a currently-valid cert as expired or not-yet-valid.
• Reused keystore carried over from a prior deployment whose certs have since lapsed.

How to Reproduce the Error

Point a client at a broker whose certificate has passed NotAfter (e.g. a test listener with an intentionally expired cert):

cat > /tmp/expired-test.properties <<'EOF'
security.protocol=SSL
ssl.truststore.location=/etc/kafka/ssl/truststore.jks
ssl.truststore.password=changeit
EOF

kafka-broker-api-versions.sh --bootstrap-server broker-expired.kafka.internal:9093 \
  --command-config /tmp/expired-test.properties

The handshake fails with CertificateExpiredException: NotAfter: ..., naming the exact expiry date of the offending certificate.

Diagnostic Commands

All commands below are read-only.

# Show the broker leaf cert's validity window (dates)
openssl s_client -connect broker-01.kafka.internal:9093 </dev/null 2>&1 | \
  openssl x509 -noout -dates -subject

# Check every cert in a keystore for its expiry date
keytool -list -v -keystore /etc/kafka/ssl/keystore.jks -storepass changeit | \
  grep -E 'Alias name|Valid from'

# Verify the full chain and surface "certificate has expired"
openssl s_client -connect broker-01.kafka.internal:9093 -showcerts </dev/null 2>&1 | \
  grep -E 'Verify return code|subject='

# Confirm system clocks are correct (skew can fake expiry)
timedatectl status | grep -E 'Local time|NTP|synchronized'

# When did the broker log the handshake failure?
sudo journalctl -u kafka --since "30 min ago" | grep -iE "expired|SSL handshake"

openssl x509 -noout -dates shows notBefore/notAfter directly, so you can confirm whether the cert is truly expired or the clock is wrong.

Step-by-Step Resolution

1. Confirm expiry, not trust or negotiation. CertificateExpiredException / Verify return code: 10 means a date problem, not a missing CA (PKIX) or protocol mismatch (handshake_failure).
2. Identify which cert expired — leaf, intermediate, or root — using openssl x509 -noout -dates and keytool -list -v. An expired CA invalidates everything under it.
3. Check the clock first. Run timedatectl; if NTP is unsynchronized and the cert is actually within its window, fix time sync rather than the cert.
4. Rotate the expired certificate (operator/mutating step): issue a new cert, rebuild the keystore with the full chain, and reload it.
5. For mTLS, rotate the expired client certificate too; a broker certificate_expired alert points at the client side.
6. Verify renewal automation resumed — a stalled cert-manager/ACME job is the usual reason a cert lapsed at all.
7. Re-test with openssl s_client until Verify return code: 0 (ok), then kafka-broker-api-versions.sh.

Prevention and Best Practices

• Monitor certificate expiry with alerts firing well before NotAfter (e.g. 30/14/7 days) for broker, client, and CA certificates.
• Automate rotation (cert-manager, ACME, internal PKI) and alert when a renewal job fails, not just when the cert expires.
• Run NTP on every broker and client so clock skew never masquerades as expiry or “not yet valid”.
• Track CA expiry explicitly — root/intermediate lapses are rarer but take down everything at once.
• Include cert dates in deployment validation so a stale keystore is rejected before it ships. The free incident assistant can read the NotAfter line and confirm the rotation needed.

Related Errors

• PKIX path building failed — the CA is missing/untrusted, not expired.
• SSLHandshakeException: handshake_failure — protocol/cipher negotiation failure.
• CertificateNotYetValidException — a cert whose NotBefore is in the future, usually clock skew.
• No subject alternative names found — a valid, unexpired cert that fails hostname verification.

Frequently Asked Questions

Which certificate actually expired? Use openssl s_client | openssl x509 -noout -dates for the leaf and keytool -list -v for the keystore. An expired intermediate or root invalidates all certs beneath it.

The cert dates look fine but it still says expired. Why? The system clock is probably wrong. Check timedatectl; an unsynchronized clock can make a valid cert appear expired or not-yet-valid.

Why did this happen suddenly with no deploy? Certificates expire on a fixed date. A missed or failed automated renewal means the existing cert simply ran out of validity.

Is rotating the leaf enough? Only if the intermediate and root are still valid. If a CA expired, you must rotate the CA and reissue everything chaining to it.

Can I check expiry without connecting? Yes. keytool -list -v -keystore <ks> prints each entry’s Valid from/until dates directly from the keystore file.