Summary

Currently the dev certificate is only valid for localhost. When running in a container, an app tryting to access the host will try to do it via host.docker.internal or host.containers.internal.

Motivation and goals

Since the dev cert isn't valid for host.docker.internal or host.containers.internal, TLS validation will fail, even if the certificate is trusted.

In scope

1. Add host.docker.internal and host.containers.internal as SAN in the dev certificate generated by the dev-certs tool
2. Add an option to produce an easy to parse output, for external tools (a json output is probably the best)

Out of scope

When container are linked or are aprt of the same network, they can be joined via their name, like https://myservice. We will not support such scenarios.

Risks / unknowns

We need to raise the version number of the certificate (currently version 2) so that newer version of the tool can create the cert with these additional SAN. However, Kestrel should still
consider version 2 certificate as valid, to avoid any issue when the user update the runtime before updating the SDK.

Examples

Example of "parsable output":

dotnet dev-certs https -c --parsable
[
  {
    "Thumbprint": "7FFF3291425E30CFCA0671AE5EB891BB62DD13A9",
    "Subject": "CN=localhost",
    "X509SubjectAlternativeNameExtension": [
      "localhost",
      "host.docker.internal",
      "host.containers.internal"
    ],
    "Version": 3,
    "ValidityNotBefore": "2025-03-19T20:53:48+01:00",
    "ValidityNotAfter": "2026-03-19T20:53:48+01:00",
    "IsHttpsDevelopmentCertificate": "true",
    "IsExportable": "true"
  }
]