[jira] [Created] (CASSCPP-8) SSL context does not reload certificates when underlying files change, preventing rotation of short-lived client certificates

["Yifan Cai (Jira)" <ji...@apache.org>]

Yifan Cai created CASSCPP-8:
-------------------------------

             Summary: SSL context does not reload certificates when underlying files change, preventing rotation of short-lived client certificates
                 Key: CASSCPP-8
                 URL: https://issues.apache.org/jira/browse/CASSCPP-8
             Project: Apache Cassandra C/C++ driver
          Issue Type: Improvement
            Reporter: Yifan Cai


Summary
The C++ driver builds a fixed SSL_CTX (via OpenSSL) at startup when SSL is configured using CassSsl. Once constructed, this context is never refreshed — even if the certificate files on disk are replaced. As a result, applications using short-lived client certificates (e.g. in mTLS deployments) cannot rotate their credentials without restarting the driver process. Future reconnections will fail once the loaded certificate has expired.

This mirrors a fixed issue in the Java driver (CASSJAVA-24)

Problem
When a user calls cass_ssl_set_cert() and cass_ssl_set_private_key() (or provides PEM paths through a custom SSL factory), the driver loads the certificate material once and holds it for the lifetime of the CassSsl object. The underlying SSL_CTX is never updated:

If the certificate on disk is rotated (e.g. renewed by a cert-management agent), the driver continues to use the stale in-memory certificate.
When the stale certificate expires, new TLS handshakes for reconnections will fail.
The only recovery path is a full process restart, which is unacceptable for always-on services.
This is especially impactful in environments deploying mutual TLS (mTLS) with Cassandra clusters running CASSANDRA-18554, where short-lived client certificates are the norm.

Expected Behavior
The driver should support reloading client certificate material from disk (or a user-supplied callback) without requiring a restart, so that:

Short-lived certificates can be rotated in-place by an external agent.
The driver picks up the new certificate material on the next reconnection or on a configurable refresh interval.
Existing open connections are unaffected until they naturally reconnect.
Proposed Approach
Introduce a certificate-reload mechanism — either a configurable periodic refresh interval or an explicit cass_ssl_reload() API — that re-reads PEM files and replaces the SSL_CTX used for new handshakes.
Alternatively, support a user-supplied callback that is invoked per-handshake to provide fresh certificate material (analogous to OpenSSL's SSL_CTX_set_client_cert_cb).
Existing behavior (load once at startup) should remain the default to preserve backward compatibility.

Motivation
Broad adoption of mTLS in Cassandra deployments (driven by CASSANDRA-18554) makes certificate rotation a first-class operational concern. Requiring a process bounce to rotate certificates is a significant operational burden and a reliability risk for high-availability services.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org