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: [email protected]
For additional commands, e-mail: [email protected]
