[
https://issues.apache.org/jira/browse/CASSCPP-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bret McGuire updated CASSCPP-8:
-------------------------------
Fix Version/s: 2.18.0
> 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
> Priority: Normal
> Fix For: 2.18.0
>
>
> 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]
