CockroachDB 23.1.12 clears client-certificate expiry state on reload
SIGHUP now invalidates cached client-certificate expiration times. The change separates certificate replacement from the stale observations that could remain in monitoring.
Replacing a certificate and updating a metric about that certificate are different operations. CockroachDB 23.1.12 connects them more closely by clearing cached client-certificate expiration times when the process receives SIGHUP. An operator reloading certificate state no longer has to assume that previously observed expiration values will describe newly presented certificates without cache invalidation.
The November 13 release notes identify security.certificate.expiration.client as the affected metric. This is a change to the observation state around client certificates. The notes do not claim that it changes certificate validity rules or causes an expired certificate to become acceptable. The useful result is a clearer relationship between reload and the values monitoring reports.
I value explicit operational behavior in CockroachDB because its distributed guarantees already require keeping several kinds of state separate. Certificate material and the cached observations derived from it belong in that accounting. A successful replacement needs a monitoring path that can represent the replacement instead of retaining an earlier observation indefinitely.
The signal handler invalidates the cache before reloading
The certificate-manager implementation at 23.1.12 registers a handler for the refresh signal. When it receives that signal, it logs the reload attempt, clears the registered client-expiration cache if one exists, and then calls LoadCertificates. The order is visible in the implementation.
The same handler records whether loading succeeds. A load error produces a warning and an unsuccessful certificate-reload event containing the error. A successful load produces a successful event. That gives operators evidence about the attempted reload separately from the fact that they delivered the signal.
Cache invalidation alone does not certify that replacement certificate files were valid or loaded. The implementation can clear the observation cache and then encounter a load error. Treating the absence of an old cached value as proof that the desired certificate replacement succeeded would confuse two different outcomes of the handler.
The manager also exposes an operation that updates client-expiration observations using a normalized SQL identity and the certificate expiration value. This shows that the metric is derived through a cache of observations. It is not simply a read of every possible application client's current certificate file from the database server's filesystem.
Reload checks protect existing certificate state
LoadCertificates reads the configured certificate directory through a loader and classifies the discovered certificates. The implementation distinguishes certificate authorities, node certificates and client certificates, among other uses. It constructs the replacement state before swapping the manager's current certificate references.
If the manager has already initialized, it checks whether a reload would replace certain previously valid certificates with missing or invalid ones. That includes the node and certificate-authority state covered by those checks. A bad reload can therefore fail rather than silently discarding an existing valid configuration.
This behavior reinforces the distinction between a reload request and a completed change. The refresh signal initiates work. Loading and validation determine whether the certificate manager can adopt the replacement state. The new client-expiration invalidation is one step in that sequence, with its own monitoring consequence.
My preference is to use that sequence when interpreting a certificate-rotation alert. The signal, reload result and later metric observations each provide evidence for a different stage. None should be inferred solely from seeing that a deployment copied new files into place.
Observation has its own lifecycle
The release note is narrowly worded because cache lifetime is the issue it changes. An earlier client-expiration observation can remain relevant to monitoring until invalidated or replaced according to the cache's rules. Clearing it on reload gives the process a defined boundary after which stale observations do not have to remain the basis of the reported expiration state.
This does not require treating the client metric as a complete certificate inventory. The source shows a cache registered with the manager and updated with client identity and expiration values. It supports reasoning about observed clients, without establishing that the server knows every certificate distributed to applications that have not connected.
The change is consequently useful during rotation while retaining the scope of the metric. Monitoring can respond to refreshed observations after cache invalidation. Inventory of certificates held by disconnected applications remains a separate administrative source of information.
Other monitoring changes retain similar timing distinctions
The same release adds changefeed.lagging_ranges, with a threshold and polling interval controlling when a lagging range becomes visible in the metric. The notes explicitly explain that polling adds delay beyond the configured lag threshold. This is another example where the time of a condition and the time of its observation differ.
For certificate expiration, 23.1.12 provides an explicit invalidation event through SIGHUP. For lagging ranges, it documents a polling delay. Both changes make the lifecycle of a metric part of its interpretation. The certificate repair specifically ensures that requesting a reload also discards the cached client-expiration state that could otherwise continue describing an earlier certificate observation.