Updating dotnet dev-certs https to better support expanded scenarios

[benjaminpetit]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

It would be helpful to be able to retrieve and generate dev certs programmatically.

Currently, we have to use some hacky way to retrieve it programmatically (see https://github.com/dotnet/aspire-samples/pull/667/files).

Another limitation of the current situation is that since the cert is only valid for localhost, so if an app is running in a container and needs to access another service on the host, there will be an SSL error since requests will be done against https://host.docker.internal. Same issue with other container services running with short names, like https://catalog for example.

Describe the solution you'd like

• A public interface to interact with the dev cert (at least get the current one)
• Ideally a way to add alternative subject name to support the container case.

Additional context

No response

[DamianEdwards]

The code in question is currently shared between dotnet dev-certs and Kestrel itself, and it's internal in both places. Making it public would require a pretty extensive API review and we'd need to decide where it would even live such that things like Aspire could use it. Note that the Aspire app host project doesn't even reference ASP.NET Core today so wouldn't be able to use the API from Kestrel even if it were public.

My preference for the Aspire scenario (dotnet/aspire#7756) is that we rely on the command line tool, rather than try introduce another party this code needs to be shared/synced with. Orchestrating external tools is very much what Aspire does already for lots of things and I think it's simpler approach in this case (but I'm willing to be convinced otherwise).

That said, to better support this model, I think dotnet dev-certs should support a structured output mode (like other dotnet CLI commands do) so that it's more reliable to orchestrate it. E.g. right now it doesn't output the actual certificate details (like the thumbprints) unless run with the -v flag, and the output isn't at all friendly to tooling.

RE the subject alternative names, we simply need the two known container host network hostnames (host.docker.internal and host.containers.interanl) to be supported as SANs for the HTTPS dev cert, so the simplest thing would be to just version the cert and adds those two SANs. They're both local only and use the newly reserved .internal sub-domain so there aren't new concerns introduced related to having the cert support non-local domains (as this cert is self-signed and trusted as part of our standard dev experience flows, we're particular about what hosts it's valid for from a security point of view, /Cc @blowdart). In the future there might be scope to expand the SANs to better support other more advanced local development scenarios using hostnames other than "localhost", but that's not today.

The dotnet dev-certs https and Kestrel dev cert support already supports the idea of versioning the cert without changing the OID, and the code is written such that the version check is a >= so if you have a newer version than the code knows about, it's still considered valid. That said, we'll need to consider scenarios such as running with a new ASP.NET Core version (runtime) than SDK version, as today the code is simply shared and there's no provision for each to support a different min version, but that shouldn't be a complicated change (we just need to know to consider it). I think we essentially need to increment the version used by dotnet dev-certs (i.e. for creating, trusting, exporting, etc. the cert), but not the version used by ASP.NET Core for finding and loading the cert. That way, a patched Kestrel will honor the existing cert, even if the SDK on the machine hasn't been updated and thus the new version of the cert laid down.

Also, the Aspire scenario we want to enable with these changes needs to work for the .NET 8 or .NET 9 SDKs too (as Aspire supports those versions) so these changes need to backported to 8.0.1xx and 9.0.1xx so they're available everywhere.

[blowdart]

As Damian says, the dev-certs tool is limited to a limited range of certificates on purpose, due to security concerns

If you want to start issuing trusted certificates for old host then I suggest using OpenSSL to generate a root CA and then issue certificates from that.

[EmperorArthur]

@DamianEdwards Was about to open a new issue, but I think this is the same issue I am experiencing. Maybe it should be re-named to "Allow dotnet dev-certs https to Import/Export via standard input/output"

The default Visual Studio aspnetcore / Angular project has to export the cert to a file, and it's then used by the JavaScript development server. This is more finicky than it should be, and I've seen it break in multiple ways. I also ran into an issue when dealing with something like #50335 where I would have loved to be able to just pipe the exported cert to a different command.

[DamianEdwards]

@EmperorArthur our current plan is to add support for a hidden flag that changes the output of the dev-certs command to JSON for better integration with other tools, but it doesn't include the actual certificate in the export case I believe, just the metadata like thumbprint, result message, etc. Supporting export to std out is a good idea that I'm supportive of but it's not clear when we'd be able to prioritize that at the moment.