Add environment variables that enable to trust additional certificates from the file system.

[tmds]

With OpenSSL the SSL_CERT_DIR and SSL_CERT_FILE envvars enable overriding the system certificates trusted by the .NET application.

This is a request to, instead of overriding all system certificates, enable adding additional certificates from the file system using environment variables:

• DOTNET_SSL_CERT_DIRS: a colon separate list of directories certificates are loaded from.
• DOTNET_SSL_CERT_FILES: a colon separate list of files certificates are loaded from.

Having a 'simple' way to extend the trusted certificates may provide a more secure alternative than opting into to insecure communication (e.g. NuGet/Home#12542).

cc @bartonjs @vcsjones @blowdart

[ghost]

Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

Issue Details

---

With OpenSSL the SSL_CERT_DIR and SSL_CERT_FILE envvars enable overriding the system certificates trusted by the .NET application.

This is a request to, instead of overriding all system certificates, enable adding additional certificates from the file system using environment variables:

• DOTNET_SSL_CERT_DIRS: a colon separate list of directories certificates are loaded from.
• DOTNET_SSL_CERT_FILES: a colon separate list of files certificates are loaded from.

Having a 'simple' way to extend the trusted certificates may provide a more secure alternative than opting into to insecure communication (e.g. NuGet/Home#12542).

cc @bartonjs @vcsjones @blowdart

Author:	tmds
Assignees:	-
Labels:	area-System.Security
Milestone:	-

[joelverhagen]

Yes, I love this idea. Would there be an expectation that DOTNET_SSL_CERT_DIRS and DOTNET_SSL_CERT_FILES work the same on Windows? Or would this be an OpenSSL-only hook? Perhaps I am wrong but SSL_CERT_DIR and SSL_CERT_FILE only for macOS and Linux?

[tmds]

The proposal is meant for this to work cross-platform, so on Windows too.

[jeffhandley]

Anything where .NET augments or changes the logic for trusted certificate comes with the risk of support or security issues, so it's ideal if we're delegating that work to the underlying system as much as possible, keeping it as predictable and consistent as we can.

Instead of using an environment variable to inform .NET how to augment the list of trusted certificates, would it be possible in these scenarios to add the additional certificates into the system's trusted certificate store? Are there other processes running that should not respect the additional certificates as trusted?

[ghost]

This issue has been marked needs-author-action and may be missing some important information.

[tmds]

Instead of using an environment variable to inform .NET how to augment the list of trusted certificates, would it be possible in these scenarios to add the additional certificates into the system's trusted certificate store? Are there other processes running that should not respect the additional certificates as trusted?

I think the main issues are:

• permission: you need root to add certificates.
• UX: it depends on the distro how to do this, and users don't know how to do it.

Unfortunately, this makes users go for the "--insecure" option when it is available (NuGet/Home#12542).

[tmds]

Note that handing of SSL_CERT_DIR (with OpenSSL) is handled by runtime itself. So any security considerations already apply to that.

The request here is for something that it additive, and that works cross-platform.

[jeffhandley]

Assigned to @bartonjs to revisit triage of this. Do you think we'd consider this, @bartonjs?

[tmds]

In #92920 we've added support for SSL_CERT_DIR to accept multiple directories. This enabled the use-case on Linux and also on container-based systems (Kubernetes, CI, ...).

Perhaps that is sufficient to close this issue.

[joelverhagen]

IMO this issue is about cross-platform support (full runtime support, all platforms). If is #92920 is Linux + container specific, then Windows and macOS are still not able to override trusted certificates with an environment variable (apologies if I misunderstood). For that reason, it seems like this issue stay open.

In particular, if you want to trust an internal NuGet package feed with a private CA for SSL certs, you have to "mess up" your Windows trust store, rather than being able to scope the trust change to one process with an env var.

[bartonjs]

I don't think we have enough evidence that this would be goodness/desired on Windows. We only support SSL_CERT_DIR because our position on Linux is "behave like other things using system crypto", and those environment variables generally control OpenSSL under the hood.

If there's a strong cry for it, we'd definitely consider it; but for now, no.