-
Notifications
You must be signed in to change notification settings - Fork 797
Description
When aspire run is executed, the Aspire CLI currently checks the status of the dev-cert by shelling out to dotnet dev-certs https --trust --check and inspecting the exit code. If it's non-zero, it assumes the check failed and shells to dotnet dev-certs --trust to perform the certificate trust (and creation if necessary).
This has some issues, particularly on Linux, where the dev-certs trust check will always fail if the SSL_CERT_DIR environment is not set, but the trust operation will succeed whether it's set or not. This leads to a situation where aspire run tries to trust the cert, thinks that's trusted because the trust operation "succeeds", but a subsequent trust check still fails, meaning the check and trust are performed on every single run, until the SSL_CERT_DIR environment variable is manually set to the correct value.
We're making a change in dotnet dev-certs to improve the messages shown by default when the trust operation results in the cert only being "partially" trusted which is an improvement, but we can do more in aspire run to ensure the SSL_CERT_DIR is properly set for the launching AppHost project.
The CLI can be changed to shell to dotnet dev-certs https --check-trust-machine-readable (available since .NET 10 SDK) which gives a JSON blob with details of all dev-certs found:
dotnet dev-certs https --check-trust-machine-readable
[
{
"Thumbprint": "027C7563CA3D34B0D9164311DC122991D2BB4128",
"Subject": "CN=localhost",
"X509SubjectAlternativeNameExtension": [
"localhost",
"*.dev.localhost",
"*.dev.internal",
"host.docker.internal",
"host.containers.internal"
],
"Version": 5,
"ValidityNotBefore": "2025-12-17T16:07:07-08:00",
"ValidityNotAfter": "2026-12-17T16:07:07-08:00",
"IsHttpsDevelopmentCertificate": true,
"IsExportable": true,
"TrustLevel": "Partial"
}
]The "TrustLevel": "Partial" there indicates that the certificate isn't fully trusted due to SSL_CERT_DIR not being configured. If the highest versioned valid certificate in the list is fully trusted, then run can continue. If it's not trusted at all, then aspire run should run dotnet dev-certs https --trust. If it's partially trusted (or still partially trusted after the trust operation was run) then aspire run should attempt to set/update SSL_CERT_DIR so that it includes the ~/.aspnet/dev-certs/trust folder if not already included. This way, the AppHost should launch with a fully trusted dev-cert even if the user hasn't manually updated their profile to set SSL_CERT_DIR correctly.