[release/10.0] Update minimum certificate version check behavior to support certs from as far back as the 10.0.100 SDK.

[danegsta]

Backport fixes for minimum valid certificate version constraint

Backport of #65151

Updates minimum certificate version check to accept developer certificates generated by 10.0.100 tooling (or later) instead of only accepting the latest certificate version.

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

Customer Impact

Currently if the runtime and SDK tooling versions are out of sync, specifically when attempting to use an older version of the dev-certs tool with a newer runtime version (say 10.0.100 SDK with 10.0.102 runtime), the older tooling can't produce a version of the developer certificate that's considered valid by the runtime. This leads to a situation where a user runs dotnet dev-certs https --trust and it reports the certificate is trusted successfully, but their ASP.NET Core apps report no valid certificate was found.

This was caused by the runtime having the minimum supported certificate version pinned to the latest certificate version (so if you have the 10.0.2 runtime, it will only accept a version 6 certificate). On the other hand, the 10.0.100 tooling produces a version 4 certificate, hence the disconnect. By setting the minimum required certificate version to 4, the runtime will now accept a trusted version 4 certificate from the 10.0.100 SDK as valid and use it for TLS termination. The first run also won't do any certificate upgrade as that is keyed off the minimum version. Running dotnet dev-certs https --trust with newer SDK tooling will still result in the trusted development certificate being updated to the latest version.

The end result is a much less frustrating developer certificate experience for users when updating their SDK, particularly if they're using pinned SDK versions via global.json.

Regression?

• No

The previous behavior wasn't ideal, but it wasn't strictly a regression as the settings were working as intended.

Risk

• Medium

This is a change to developer certificate trust validation for both the SDK and runtime as we haven't used a split minimum and current config before, but there are a number of existing and new tests that validate the behavior.

Verification

• Manual (required)
• Automated

Unit tests are included.

Packaging changes reviewed?

• N/A

[dotnet-policy-service]

Hi @@danegsta. Please make sure you've updated the PR description to use the Shiproom Template. Also, make sure this PR is not marked as a draft and is ready-to-merge.

To learn more about how to prepare a servicing PR click here.

[Copilot]

Pull request overview

This PR fixes a developer certificate validation issue where SDK and runtime version mismatches caused certificate rejection. The fix allows the runtime to accept development certificates from SDK 10.0.100 (version 4) or later while still generating version 6 certificates with newer tooling.

Changes:

• Split certificate version constraints: minimum accepted version is now 4 (from 10.0.100 SDK) while generated version remains 6
• Interactive mode (dotnet dev-certs) requires current version certificates, non-interactive mode (first run) accepts minimum version
• Added enhanced logging to distinguish certificates below minimum version from other invalid certificates

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
src/Shared/CertificateGeneration/CertificateManager.cs	Updated minimum certificate version constant to 4, added version filtering in ListCertificates, separated IsValidCertificate logic from version checks, added interactive/non-interactive filtering logic, enhanced documentation, added new logging events, fixed Event ID mismatch on line 1407
src/Shared/test/Shared.Tests/TestCertificateManager.cs	Added comprehensive test helper class for certificate management testing with in-memory certificate store simulation and version manipulation capabilities
src/Shared/test/Shared.Tests/CertificateManagerTests.cs	Added 6 new test cases covering minimum version filtering, interactive vs non-interactive behavior, and certificate upgrade scenarios