Add support for trusting dev certs on linux

[amcasey]

Overview

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.

Comparison with community tools

There are some community projects that have added this functionality, but they differ from this implementation in some notable ways:

1. We're using the same certificate as on Windows and macOS - it's not a CA
2. We're only trusting the certificate for a single-user
3. We require the additional step of setting SSL_CERT_DIR
4. We require OpenSSL 1.1.1h or greater to handle the fact that our cert is not a CA

Work outside this repo

1. We need to update the docs. Presently, they say this is impossible. Instead, they should explain limitations and provide troubleshooting steps
2. More docs: https://learn.microsoft.com/en-us/aspnet/core/security/enforcing-ssl?view=aspnetcore-8.0&tabs=visual-studio%2Clinux-ubuntu#ssl-linux
3. We need to update the docker tools docs (cc @richlander).
4. We need to write manual testing instructions for pre-release validation
5. We could consider pre-setting SSL_CERT_DIR in our official docker images
6. We could consider setting SSL_CERT_DIR in install-dotnet.sh (assuming it's already setting things like DOTNET_ROOT)

[amcasey]

FYI @tmds

[richlander]

It would be good to develop a POC for this with both Docker multi-stage build and SDK publish.

We could consider pre-setting SSL_CERT_DIR in our official docker images

I don't grasp why we would do this.

@baronfel @MichaelSimons

[amcasey]

It would be good to develop a POC for this with both Docker multi-stage build and SDK publish.

I'm not sure what these things are. I think you might be saying we should validate that the new functionality works in some specific scenarios, but I'm not familiar with those scenarios.

We could consider pre-setting SSL_CERT_DIR in our official docker images

I don't grasp why we would do this.

It's entirely possible that my comment doesn't make sense. What I had in mind is that, for OpenSSL to trust a certificate, it needs to be in a folder that is listed in the SSL_CERT_DIR environment variable. dotnet dev-certs can't set an environment variable in the containing process and adding it to the user's profile is fraught for both social and technical reasons. However, in a docker image, it seems like we could do that on the user's behalf (add our well-known trusted-certificate directory to SSL_CERT_DIR).

[javiercn]

It would be good to develop a POC for this with both Docker multi-stage build and SDK publish.

I'm not sure what these things are. I think you might be saying we should validate that the new functionality works in some specific scenarios, but I'm not familiar with those scenarios.

We could consider pre-setting SSL_CERT_DIR in our official docker images

I don't grasp why we would do this.

It's entirely possible that my comment doesn't make sense. What I had in mind is that, for OpenSSL to trust a certificate, it needs to be in a folder that is listed in the SSL_CERT_DIR environment variable. dotnet dev-certs can't set an environment variable in the containing process and adding it to the user's profile is fraught for both social and technical reasons. However, in a docker image, it seems like we could do that on the user's behalf (add our well-known trusted-certificate directory to SSL_CERT_DIR).

We can just update our Dockerfile to include it, the same way it has an instruction to expose the right ports. No need to set the environment variable in the container image directly.

[richlander]

However, in a docker image, it seems like we could do that on the user's behalf (add our well-known trusted-certificate directory to SSL_CERT_DIR).

We're unlikely to do that. We don't want to change the trust model of the container images we ship. If you can add certs in the directory, you can set the ENV.

I'm asking for E2E examples for the scenario that this feature targets. We can help you if you are not familiar with the specifics. As a general rule, high-level Linux features (and certs are pretty high-level) should be fully validated with the container workflow. I'm seeing a lot of assumptions here.

Separately, if you are just on a raw Linux box, why not use update-ca-certificates? That's the standard, tool, yes?

[amcasey]

However, in a docker image, it seems like we could do that on the user's behalf (add our well-known trusted-certificate directory to SSL_CERT_DIR).

We're unlikely to do that. We don't want to change the trust model of the container images we ship.

Fine by me.

If you can add certs in the directory, you can set the ENV.

I can't tell if you mean you, the dotnet dev-certs owner, or you, the dotnet dev-certs invoker. Somewhat moot if we're not doing it either way.

I'm asking for E2E examples for the scenario that this feature targets.

Examples in the sense of user-facing samples or in the sense of manual validation?

We can help you if you are not familiar with the specifics.

That would be great.

As a general rule, high-level Linux features (and certs are pretty high-level) should be fully validated with the container workflow.

I've been using both docker and GUI VMs for my validation, but I expect more real-world tests once it's ready for the Aspire folks to play with.

I'm seeing a lot of assumptions here.

Tell me more? This is definitely uncertain terrain, but we've been through several rounds of consultation and prototyping.

Separately, if you are just on a raw Linux box, why not use update-ca-certificates? That's the standard, tool, yes?

The main reasons are:

1. The aspnetcore dev cert is not a CA, so it doesn't play nicely with standard tools like update-ca-certificates.
2. Invoking update-ca-certificates requires sudo, which isn't a great user experience.
3. update-ca-certificates trusts the certificate for all users on a box, which has security consequences (and is just plain confusing since the cert is stored and trusted by browsers on a per-user basis).

[richlander]

Ok. I think I understand a bit better now.

Here are some workflows we documented many years ago: https://github.com/dotnet/dotnet-docker/blob/main/samples/run-aspnetcore-https-development.md#linux. I'm assuming for an environment where the browser is your local machine and the app is in a container that the new workflow would be very similar. Is that fair?

[amcasey]

Ok. I think I understand a bit better now.

Here are some workflows we documented many years ago: https://github.com/dotnet/dotnet-docker/blob/main/samples/run-aspnetcore-https-development.md#linux. I'm assuming for an environment where the browser is your local machine and the app is in a container that the new workflow would be very similar. Is that fair?

Yeah, I think you'd just additionally run dotnet dev-certs https --trust on the local machine. Of course, things get more complicated if the code running in the container is making requests with HttpClient that also need to be validated with the dev cert.

[richlander]

We can collaborate offline on a workflow / writeup if you'd like. I did the same with that doc I shared with @javiercn.

[amcasey]

Sounds great. Let me get it through threat modelling first so we don't have to redo the docs if our approach changes.

[amcasey]

Force push is a rebase on top of #56701.

[amcasey]

Force push is just picking up fresh changes from #56701, since it wasn't working on Windows.

[amcasey]

Force push just replaces the merge with a rebase. The code is the same.

[javiercn]

Looks great, left a couple of comments, but nothing major that we can't solve afterwards if we wanted to.

[dotnet-policy-service]

@amcasey, this change will be considered for inclusion in the blog post for the release it'll ship in. Nice work!

Please ensure that the original comment in this thread contains a clear explanation of what the change does, why it's important (what problem does it solve?), and, if relevant, include things like code samples and/or performance numbers.

This content may not be exactly what goes into the blog post, but it will help the team putting together the announcement.

Thanks!