Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplified SSL option value for cacerts? #8598

Open
zmstone opened this issue Jun 19, 2024 · 7 comments
Open

Simplified SSL option value for cacerts? #8598

zmstone opened this issue Jun 19, 2024 · 7 comments
Assignees
Labels
enhancement team:PS Assigned to OTP team PS

Comments

@zmstone
Copy link
Contributor

zmstone commented Jun 19, 2024

When one wants to use system default trusted certs to verify peer.
There seems to be only two options:

  1. Extract the trusted CA certificates in a file, and provide cacertfile option
  2. Trust ALL default ca certs from the OS: {cacerts, public_key:cacerts_get()}

I'd like to have option 2 simplified as {cacerts, system_defaults} or similar so OTP's ssl lib can call public_key:cacerts_get() for me.

This is necessary because public_key:cacerts_get() is often a quite bloated term.
And SSL options are usually passed around and stored in various process states.
When process crashes or when exceptions with SSL options in the context are caught and dumped to logs,
the options are printed to the logs which in turn bloats the logs quite much.

@IngelaAndin IngelaAndin added the team:PS Assigned to OTP team PS label Jun 22, 2024
@zmstone
Copy link
Contributor Author

zmstone commented Jun 22, 2024

A further enhancement is probably not to turn system_defaults into public_key:cacerts_get(),
but use it as an indication to search for certs in certificate store which is periodically refreshed thus to ensure certificate renewal is smooth.

@IngelaAndin IngelaAndin self-assigned this Aug 27, 2024
@IngelaAndin
Copy link
Contributor

Thank you for you input. We definitely will consider doing changes in this direction. We also have our own thoughts of a "caching mechanism" for cert provided as DER directly. Can not give you any estimates of when it can be prioritized.

@zmstone
Copy link
Contributor Author

zmstone commented Aug 29, 2024

@IngelaAndin thank you.
If the "caching mechanism" means passing a reference but not a large term, that's great.
I am unsure why it's limited to DER format, but it could be a good start. Thanks.

Another point I added was the support for root CA certificates renewal (without having to restart).
The current cacertfile solution has support for it (ssl lib periodically reloads it), but public_key:cacerts_get() is a immutable term.
If the OS trusted certifcates can be loaded into a "cache", and then application can use a reference for it, I would wish this cache to be periodically refreshed.

@dgud
Copy link
Contributor

dgud commented Aug 30, 2024

The result of public_key:cacerts_get() is stored on the literal area so it never is a bloated term, until it is printed that is.
But until then it doesn't cost any memory and is already cached between users.

@IngelaAndin
Copy link
Contributor

Well I guess we have three things, if certs are provided as DER in options we want to create a cache. In public_key:get_cacerts case we want the cache to be refreshable as the PEM cache is. We also want #8741 so that public_key:get_cacerts will not be printed by SASL progress reports.

@IngelaAndin
Copy link
Contributor

@zmstone As I said #8741 should fix you log problem, cacerts are not not printed in error reports already today so it is just the progress reports. For certs provided by cacerts that is not public_key:cacerts_get() but raw DER is the caching improvement I was thinking about. For PEM-files we have a really not disruptive cache refresh mechanism, but for system defaults as @dgud mentions is implemented differently. And maybe we need to think about if this should be handled by user application by calling
public_key:cacerts_clear/0 instead? I am not sure about the tradeoffs here!?

@zmstone
Copy link
Contributor Author

zmstone commented Sep 7, 2024

It's often more than SASL progress which may print the certs.
When a config is constructed at application level, and passed down the abstraction layers,
each layer may have its own idea about error handling and logging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement team:PS Assigned to OTP team PS
Projects
None yet
Development

No branches or pull requests

3 participants