Dotnet Dev Certs host.docker.internal support

[NapalmCodes]

I am creating my first Aspire resource using a container available on Docker hub. SSL development on local works great for all things running locally as dev certs if installed via dotnet CLI and trusted work for localhost. However, the container has its own trusted certificate authorities and its own isolated network (thus its own localhost). When it makes calls into OTLP (the dashboard) Aspire correctly gives it the host.docker.internal endpoint env var for the OTEL collector when the resource is defined as an IResourceWithEnvironment. Only one problem, the collector uses the dev certs which are only minted for localhost. Given the DNS is different SSL traffic is rejected.

I would like to propose dev certs mint a certificate for host.docker.internal and localhost to make this easier for developers. In addition, I think there is potential here for Aspire to maybe do some of the heavy lifting involved with mounting dev certs in a bind mount volume/updating the container's trusted certs by overriding the entrypoint, performing the update and ultimately launching the original entrypoint?

What are the team's/community's thoughts on this? The only other idea I have is baking my own docker image from the original docker hub image, but that seems a little heavy handed.

What can we do to make this experience better and assist with the local SSL based development experience?

[NapalmCodes]

@maddymontaquila any chance someone from the team might have some insight here?

[timheuer]

@DamianEdwards is your experiment with dev-cert and the one container maybe similar here?

[DamianEdwards]

Kinda, yeah. Communications from containers to resources running on the host has some rough edges today and this is one of them. We've talked about simplifying the injection of the dev cert into containers so that they can host their own HTTPS endpoints that are trusted by apps running on the host, but communicating from the container to HTTPS endpoints on the host is more complicated, including the host name problem pointed out here, but also some container runtime environments don't allow this kind of communication by default.

@davidfowl recently suggested that perhaps we reconsider using HTTPS on the OTLP endpoint the dashboard hosts so that pushing telemetry to it from non-project resources is easier. Of course we'd need to revisit the security review that lead us to putting it on there in the first place. We could possibly make it opt-in.

[DamianEdwards]

Also we've discussed future updates to dotnet dev-certs that would change to generating a self-signed root CA (that would be trusted) and then issuing HTTPS certs from that as required that only live as long as the resource. There's no timeline for that right now but it would most likely be .NET 10 at the earliest (unless we push for it to be updated in a feature band).

[joelrb]

The urgency of a solution to this problem is now apparent. I hope the team will take action asap, as this is a blocker for Aspire.NET adoption.

I just hit this roadblock and I couldn't find any solution. Our product launch is fast approaching and we thought of testing finally not from our local computer but on Azure.

I successfully published a .NET Minimal API with Aspire.NET Orchestrator Support to Azure Container App. I have setup the custom domain and added in SSL certificate. The endpoint is secured (see screenshot).

But the app doesn't run due to dev cert issue (see screenshot). I tried using the console in the Azure container app so I can do 'dotnet dev-certs https --trust' or whatever works for Linux, but there's an error so I couldn't get in (see screenshot).

Any solution to this? I just couldn't find an answer the past days.

By the way, Aspire.NET is great!

Unhandled exception. System.InvalidOperationException: Unable to configure HTTPS endpoint. No server certificate was specified, and the default developer certificate could not be found or is out of date. To generate a developer certificate run 'dotnet dev-certs https'. To trust the certificate (Windows and macOS only) run 'dotnet dev-certs https --trust'.

[NapalmCodes]

Ah my mistake. Yes I am aware the dev certs are for local. However, as you suggest, using Let's Encrypt between containers inside the cluster and the automation it provides in doing this may be necessary for some tightly controlled industries.

That aside I still see value in supporting the local ssl experience end to end.

[joelrb]

Thanks for your reply. Here's the appsettings. You mean I don't need to set the Kestrel endpoint anymore?

The ASP.NET Core apps shouldn't be attempting to listen on HTTPS once deployed to ACA. In ACA the HTTPS is handled by the ingress system and your actual app process doesn't deal with HTTPS or certificates at all. Note the dotnet dev-certs command should only ever be run in non-production scenarios as it's only intended to help facilitate HTTPS during local development for the localhost address. ASP.NET Core shouldn't even be attempting to use the developer certificate unless it's in the "Development" environment.

Can you share the environment variables configuration for the application after it's deployed to ACA?

/Cc @davidfowl

[davidfowl]

Yea this configuration will not work in environments where the certificates have not been provided.

Nothing is provided out of the box for this in asp.net core nor aspire outside if development certs.

The simplest workaround is to use launchSettings for your https configuration. Aspire will delegate https on azure container apps to the ingress instead of having your application handle it.

[joelrb]

Wuhooo! That works! First Aspire.NET successful deployment for our team (a beta, but a good step). The first of many. Kudos to Team Aspire.NET.

Aspire significantly reduced the amount of time we spent configuring Docker for deployment, telemetry and many others to track our microservices. We just added Aspire Orchestrator Support to our existing API (and we have many to move over to Aspire), and boom, all done, except for this issue of dev-cert.

One curious thing, the launch settings in the AppHost. Is that for local development only?

Yea this configuration will not work in environments where the certificates have not been provided.

Nothing is provided out of the box for this in asp.net core nor aspire outside if development certs.

The simplest workaround is to use launchSettings for your https configuration. Aspire will delegate https on azure container apps to the ingress instead of having your application handle it.

[DamianEdwards]

Yes, launchSettings.json is a development-time artifact only. It's read by dev tools like dotnet run and Visual Studio only.

[NapalmCodes]

@DamianEdwards given this discussion seems to have turned into a troubleshooting thread, do we think this is worth entering an issue to sort out in a future Aspire release?

[DamianEdwards]

If you mean to capture the feature request of having Aspire help with setting up HTTPS between container and non-container resources (and vice-versa), then sure.