Update minimum certificate version check behavior to support certs from as far back as the 10.0.100 SDK.

[danegsta]

Allow ASP.NET Core Development Certificates from older tooling in newer runtimes.

Support dev certs from 10.0.100 or later at runtime

Description

The dev cert version has been bumped a few times recently to better support various scenarios such as containers and Linux OpenSSL environments, but this has lead to a few issues with scenarios where the tooling and runtime are out of sync (pinned SDK due to global.json, preview SDKs without the latest servicing bits, and nuget packages that ship as self-contained apps to name a few). Some users have been getting into a situation where their SDK tooling claims the dev cert is created and trusted (and it is, but with the version supported in that tooling), while the runtime throws an error about not being able to find a valid development certificate because the certificate version when the runtime was built was higher than what their active SDK tooling was built against.

This change sets the minimum certificate version back to version 4 (the version that shipped with the 10.0.100 SDK and 10.0.0 runtime) while keeping the version produced by tooling the same and enforces the minimum version in runtime code paths that retrieve valid dev certs, while updating the code paths that produce a certificate to still upgrade if the certificate present is older than the latest version. It also adds some additional logging to differentiate between development certificates that were considered invalid due to being out of date vs. being rejected due to being below the minimum supported version.

Fixes #65052

[Copilot]

Pull request overview

This PR updates the ASP.NET Core development certificate version checking behavior to support certificates generated by older SDK tooling. The change addresses scenarios where the SDK and runtime are out of sync by reducing the minimum required certificate version from 6 to 4 (which corresponds to SDK 10.0.100), while keeping the current certificate generation version at 6.

Changes:

• Reduced CurrentMinimumAspNetCoreCertificateVersion from 6 to 4 to support certificates from SDK 10.0.100 and later at runtime
• Refactored certificate validation to separate version filtering from other validity checks, with improved logging to differentiate between invalid certificates and those below the minimum version
• Updated certificate upgrade logic in EnsureAspNetCoreHttpsDevelopmentCertificate to trigger regeneration only for certificates below version 6

[DamianEdwards]

@danegsta we have files called CertifcateManagerTest.cs and CertificateManagerTests.cs in the same folder 😱

[danegsta]

@danegsta we have files called CertifcateManagerTest.cs and CertificateManagerTests.cs in the same folder 😱

Yeah, that's an ugly name combo; I'm renaming the new test implementation of CertificateManager to TestCertificateManager to make it less confusing.

[danegsta]

Looks like the first run tests make an assumption that first run won't generate a new certificate if an existing one meets the minimum version. It seems like a reasonable distinction to have different min-version behavior for first run vs. explicitly running dotnet dev-certs https --trust.

In non-interactive mode (first run) the certificate will only be re-generated if the minimum version isn't met, while in interactive mode (dotnet dev-certs https --trust) the certificate will be re-generated if it's older than the latest version even if it's still newer than the minimum version.

So with these latest changes if a user has a version 4 certificate, first run, Kestrel, etc. will consider the certificate valid and leave it alone, but if they then run dotnet dev-certs https --trust it'll generate a new version 6 certificate for them. First run would only update the certificate if they had a certificate older than version 4.