This creates a problem when new root certificates are added. In our case, it happens on a regular basis when clients add intermediate/root certificates to the system via a separate component and then all other components that run in separate processes are expected to make use of them. This is currently not possible.
We are currently re-implemented Root Certificate loading logic by cutting and pasting the code from this library into our codebase and create our own certPool() for every request that requires the ca-chain refresh.
Add ReloadRootCertificates() call and call it as needed - backward compatible but still the source of gotchas.
Do not use the global state and singleton and parse the certificate chain on each request - may have an unexpected performance impact.
Make the method for creating the root certificate pool public.
Add root certificate cache expiry timeout that can go all the way to 0 triggering cert chain reload on each request.
The text was updated successfully, but these errors were encountered:
I'd like to see this issue moving forward as this is directly affecting developer's ability to react to changes in the system's certificate pool.
Is there any interest in a contribution here?
I do fancy the original posts' idea of the addition of a ReloadRootCertificates() (maybe named x509.ReloadSystemCertPool()?) function as it's backwards compatible without restrictions and offers developers to address the issue in a number of different ways, e.g.:
reload each time before retrieving the SystemCertPool
This is a workaround for Golang's missing feature of reloading system
The built in system certs pool is initialized only once on startup and
there is no option for reloading it when new certs are installed.
The problem is known upstream and tracked at
The cert_pool.go is almost 1:1 copy of original library code but exposes
needed functionality. It can be removed when upstream fixes the problem.