YugabyteDB TLS connections accept revoked certificates: no revocation-check option in client drivers

Answer

As of YugabyteDB 2.20+/2024.x releases, neither the Java nor the Go client driver exposes a dedicated flag to enable CRL or OCSP revocation checking. Revocation validation must be handled by the underlying TLS library or by the application itself.

Java driver (JDBC)

• The driver is a fork of the PostgreSQL JDBC driver and uses Java’s JSSE for TLS.
• Revocation checking is controlled by JVM system properties, not by driver‑specific options:
• -Dcom.sun.net.ssl.checkRevocation=true enables both CRL and OCSP checks.
• You must also configure an OCSP responder (via -Dcom.sun.net.ssl.enableOcsp=true and -Dcom.sun.net.ssl.ocsp.responder=URL) or provide a CRL file through the standard Java security properties.
• If the JVM cannot reach the responder or the responder returns "unknown", the check may fail silently; you should verify the setup with a revoked test certificate.

Go driver (pgx‑based)

• The Go driver relies on the standard crypto/tls package, which does not perform CRL/OCSP verification by default.
• To enforce revocation you must supply a custom VerifyPeerCertificate function in tls.Config that checks the certificate chain against an OCSP responder or CRL.
• Without this custom verification, a revoked certificate will be accepted silently.

Inter‑node (node‑to‑node) TLS

• YugabyteDB uses OpenSSL‑based settings (--use_node_to_node_encryption, --certs_dir) for replication traffic.
• OpenSSL does not validate CRL/OCSP unless explicitly configured via SSL_CTX_set_verify with a verification callback, which YugabyteDB does not expose.
• Thus inter‑node TLS also accepts revoked certificates by default; hardening requires either short‑lived certificates or an external TLS terminator that performs revocation checks.

DNS TTL handling after node IP changes

• Java driver: Relies on the JVM’s address cache. Successful lookups are cached indefinitely unless you set the security property networkaddress.cache.ttl (e.g., to 60 seconds). Changes to a node’s A record will not be seen until the cache expires.
• Go driver: The Go net resolver performs a fresh DNS lookup for each connection; it does not cache results, so IP changes are seen immediately without additional configuration.

Verification steps (if you can adjust the environment)

1. Java: Start the JVM with -Dcom.sun.net.ssl.checkRevocation=true and point to a valid OCSP responder. Attempt a TLS connection using a certificate that has been revoked; the handshake should fail with a PKIX error.
2. Go: Write a small test program that sets tls.Config.VerifyPeerCertificate to perform OCSP/CRL checks, then connect with a revoked cert; expect an error from the handshake.
3. Inter‑node: Enable OpenSSL debugging (export SSL_DEBUG=1) on a YB‑TSERVER, restart with a revoked server certificate, and observe whether the TLS handshake proceeds; absence of failure indicates no revocation check.
4. DNS TTL: Change the A record of a YB‑node to a new IP, wait less than the JVM TTL setting, then open a new connection from each driver. The Java driver will still reach the old IP if the cache hasn’t expired; the Go driver will reach the new IP immediately.

Missing diagnostic detail

Do you have the ability to set JVM system properties or modify the Go driver code (e.g., add a custom VerifyPeerCertificate)? If not, the only practical workaround is to terminate TLS externally (e.g., with a load balancer or sidecar proxy) that performs revocation checking.