Filter dev certs without X509SubjectKeyIdentifierExtension when any cert has it

[Copilot]

Description

When loading developer certificates, if any certificate contains an X509SubjectKeyIdentifierExtension, exclude all certificates lacking this extension from the trust set. This prevents conflicts between legacy certificates and modern SKI-enabled certificates, particularly with OpenSSL's first-match validation behavior.

Changes:

• Modified DeveloperCertificateService.cs certificate loading logic to filter certificates based on SKI extension presence
• If any valid certificate has SKI extension, exclude all certificates without it before grouping and ordering
• No behavior change when all certificates are homogeneous (all with or all without SKI)

Implementation:

// Get all valid ASP.NET Core development certificates
var validCerts = store.Certificates
    .Where(c => c.IsAspNetCoreDevelopmentCertificate())
    .Where(c => c.NotBefore <= now && now <= c.NotAfter)
    .ToList();

// If any certificate has a Subject Key Identifier extension, exclude certificates without it
if (validCerts.Any(c => c.HasSubjectKeyIdentifier()))
{
    validCerts = validCerts.Where(c => c.HasSubjectKeyIdentifier()).ToList();
}

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No
• Does the change require an update in our Aspire docs?
  • Yes
  • No

Original prompt

---

This section details on the original issue you should resolve

<issue_title>If there are dev certs with X509SubjectKeyIdentifierExtension, only include certificates with X509SubjectKeyIdentifierExtension in the trust set</issue_title>
<issue_description>In DeveloperCertificateService.cs, if any developer certificate includes an X509SubjectKeyIdentifierExtension, we need to exclude any dev certs that don't include the extension from the final set.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes If there are dev certs with X509SubjectKeyIdentifierExtension, only include certificates with X509SubjectKeyIdentifierExtension in the trust set #13666

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 13667

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 13667"

[Copilot]

Pull request overview

This PR implements a fix for filtering developer certificates to ensure that when any certificate has an X509SubjectKeyIdentifier extension, only certificates with this extension are included in the final trust set. This prevents legacy certificates without SKI from causing conflicts in OpenSSL certificate validation.

Key Changes

• Extracted certificate filtering into an intermediate validCerts list to enable conditional filtering before grouping
• Added logic to check if any valid certificate has a Subject Key Identifier extension
• If SKI is present on any certificate, filters out all certificates without it

[Copilot]

The new filtering logic that excludes certificates without Subject Key Identifier when at least one certificate has it lacks test coverage. Consider adding unit tests that verify the filtering behavior with scenarios such as:

• All certificates have SKI: all should be included
• Some certificates have SKI, some don't: only those with SKI should be included
• No certificates have SKI: all should be included
• Mixed valid/invalid SKI values

This would ensure the filtering logic works correctly across different certificate store states.

[danegsta]

I'm not quite ready to add tests that write certificates to the store to make these tests viable.

[davidfowl]

Confirmed this works

[davidfowl]

@danegsta What happens if they only have an older dev cert?

[danegsta]

@danegsta What happens if they only have an older dev cert?

If there’s only older dev certs (pre-10.0.101 patch), we’ll only trust a single older cert (the newest one). If there’s multiple certs from 10.0.101 or newer we can safely trust all of them.

[danegsta]

/backport to release/13.1

[github-actions]

Started backporting to release/13.1: https://github.com/dotnet/aspire/actions/runs/20414391919