Expected Behavior
When the local-store certificate provider reloads a changed client root CA bundle, new TLS connections should verify servers using the refreshed root pool without requiring a process restart or recreating the client TLS configuration. Existing established connections should remain unaffected.
Actual Behavior
The local-store provider reloads CA files in the background, but newClientTLSConfig stores the initial RootCAs pool in a long-lived tls.Config. New handshakes therefore continue using the old roots after a refresh.
Additionally, the provider only parses the first certificate from each PEM file for change detection. During a staged rotation from old CA to old CA + new CA, the parsed certificate set appears unchanged and the cached pool is not replaced.
Steps to Reproduce the Problem
- Configure local-store client TLS with a root CA file and enable host verification.
- Create a client TLS configuration and successfully connect to a server signed by the original CA.
- Replace the CA bundle with a new CA, wait for the configured TLS refresh interval, and connect to a server signed by the new CA using the same client configuration.
- Observe that verification still uses the original root pool until the client configuration or process is recreated.
Specifications
- Version: current
main
- Platform: all deployments using the local-store TLS provider
Proposed direction
Resolve the provider’s cached root pool for each new handshake while retaining file reads on the existing background refresh path. Parse all certificates from PEM bundles so overlapping CA rotations are detected. This should not reset existing connections or add filesystem I/O to connection establishment.
Expected Behavior
When the local-store certificate provider reloads a changed client root CA bundle, new TLS connections should verify servers using the refreshed root pool without requiring a process restart or recreating the client TLS configuration. Existing established connections should remain unaffected.
Actual Behavior
The local-store provider reloads CA files in the background, but
newClientTLSConfigstores the initialRootCAspool in a long-livedtls.Config. New handshakes therefore continue using the old roots after a refresh.Additionally, the provider only parses the first certificate from each PEM file for change detection. During a staged rotation from
old CAtoold CA + new CA, the parsed certificate set appears unchanged and the cached pool is not replaced.Steps to Reproduce the Problem
Specifications
mainProposed direction
Resolve the provider’s cached root pool for each new handshake while retaining file reads on the existing background refresh path. Parse all certificates from PEM bundles so overlapping CA rotations are detected. This should not reset existing connections or add filesystem I/O to connection establishment.