ASP.NET Core HTTPS dev cert should set the SKI and AKI extensions to avoid issues with OpenSSL #64261
Description
The ASP.NET Core HTTPS dev cert does not currently set values for the Subject Key Identifier (SKI) or Authority Key Identifier (AKI) extensions, which leads to issues when the cert is used in scenarios that involve stacks using OpenSSL (e.g. Python, Node.js, VS Code, etc.) if there are multiple trusted CA certs with the same subject available to OpenSSL. The matching logic OpenSSL uses is ambiguous in this case and can result in the wrong certificate being selected for validation, resulting in failures.
This is impacting scenarios in Aspire regarding orchestration of Python and Node.js apps (along with others) as these apps fail to establish connections to the OpenTelemetry OTLP endpoint hosted by the Aspire dashboard (dotnet/aspire#4131). It's also impacting scenarios involving locally hosted MCP servers over HTTPS using the dev cert being accessed by VS Code GHCP agent mode (microsoft/vscode#248170).
The resolution suggested by OpenSSL (openssl/openssl#16304) is to ensure that the certificates have appropriate values for the SKI and AKI extensions set so that the correct certs are loaded when building the cert chain for validation.
In the case of the ASP.NET Core HTTPS dev cert, which is a self-signed server authentication cert, this means that the AKI and SKI extensions should be set to the same value (derived using the process specified in RFC 5280 section 4.2.1.2. (1) when created via the dotnet dev-certs https tool.