You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add support for trusting dev certs on linux (dotnet#56582)
* Add support for trusting dev certs on linux
There's no consistent way to do this that works for all clients on all Linux distros, but this approach gives us pretty good coverage. In particular, we aim to support .NET (esp HttpClient), Chromium, and Firefox on Ubuntu- and Fedora-based distros.
Certificate trust is applied per-user, which is simpler and preferable for security reasons, but comes with the notable downside that the process can't be completed within the tool - the user has to update an environment variable, probably in their user profile. In particular, OpenSSL consumes the `SSL_CERT_DIR` environment variable to determine where it should look for trusted certificates.
We break establishing trust into two categories: OpenSSL, which backs .NET, and NSS databases (henceforth, nssdb), which backs browsers.
To establish trust in OpenSSL, we put the certificate in `~/.dotnet/corefx/cryptography/trusted`, run a simplified version of OpenSSL's `c_rehash` tool on the directory, and ask the user to update `SSL_CERT_DIR`.
To establish trust in nssdb, we search the home directory for Firefox profiles and `~/.pki/nssdb`. For each one found, we add an entry to the nssdb therein.
Each of these locations (the trusted certificate folder and the list of nssdbs) can be overridden with an environment variable.
This large number of steps introduces a problem that doesn't exist on Windows or macOS - the dev cert can end up trusted by some clients but not by others. This change introduces a `TrustLevel` concept so that we can produce clearer output when this happens.
The only non-bundled tools required to update certificate trust are `openssl` (the CLI) and `certutil`. `sudo` is not required, since all changes are within the user's home directory.
* Also trust certificates in the Current User/Root store
A belt-and-suspenders approach for dotnet trust (i.e. in addition to OpenSSL trust) that has the notable advantage of not requiring any environment variables.
* Clarify the mac-specific comments in GetDevelopmentCertificateFromStore
(cherry picked from commit 27ae082)
Copy file name to clipboardExpand all lines: src/Servers/Kestrel/Core/src/Internal/LoggerExtensions.cs
+3Lines changed: 3 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -40,4 +40,7 @@ internal static partial class LoggerExtensions
40
40
41
41
[LoggerMessage(8,LogLevel.Warning,"The ASP.NET Core developer certificate is not trusted. For information about trusting the ASP.NET Core developer certificate, see https://aka.ms/aspnet/https-trust-dev-cert.",EventName="DeveloperCertificateNotTrusted")]
[LoggerMessage(9,LogLevel.Warning,"The ASP.NET Core developer certificate is only trusted by some clients. For information about trusting the ASP.NET Core developer certificate, see https://aka.ms/aspnet/https-trust-dev-cert",EventName="DeveloperCertificatePartiallyTrusted")]
0 commit comments