Skip to content

Ordering of X509Chain.ChainElements #11359

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
tyb-dev opened this issue May 28, 2025 · 1 comment
Open

Ordering of X509Chain.ChainElements #11359

tyb-dev opened this issue May 28, 2025 · 1 comment
Labels
area-System.Security Issues related to security practices for .NET developers. untriaged New issue has not been triaged by the area owner

Comments

@tyb-dev
Copy link

tyb-dev commented May 28, 2025

Describe the issue or suggestion

The current documentation for X509Chain.ChainElements does not specify the ordering of the returned certificates. Consumers of the API need to know whether element 0 is the leaf (end-entity) certificate or the root (trust anchor), and how intermediate certificates are ordered in between.


Suggested Improvements

  1. Add explicit ordering guarantee
    Include a statement such as:

    “The ChainElements collection is ordered from the end-entity (leaf) certificate at index 0, through any intermediates, to the trust anchor (root certificate) at the final index.”

  2. Link to authoritative references

    • On Windows, CERT_CHAIN_CONTEXT guarantees that rgpChain[0] is the end certificate and rgpChain[cChain–1] is the final chain element (root) (see CERT_CHAIN_CONTEXT struct).
    • On Linux, OpenSSL’s X509_STORE_CTX_get0_chain() returns a STACK_OF(X509) ordered from leaf to root.
  3. Include a minimal example or unit test snippet
    Demonstrate that:

    using var chain = new X509Chain();
    chain.Build(serverCertificate);
    // chain.ChainElements[0] is the leaf cert
    // chain.ChainElements[^1] is the root cert

Rationale

  • Clarity & Reliability: Making the ordering contract explicit in the XML docs prevents accidental misuse and reduces reliance on implementation details or platforms.
  • Cross-Platform Consistency: Consumers targeting multiple runtimes (Windows, Linux, macOS) will have confidence that the API behaves identically everywhere.
  • Ease of Testing: Documenting this behavior enables straightforward unit tests and validation.
@github-actions github-actions bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label May 28, 2025
@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label May 28, 2025
@PranavSenthilnathan PranavSenthilnathan added area-System.Security Issues related to security practices for .NET developers. and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels May 28, 2025
Copy link
Contributor

Tagging subscribers to this area: @dotnet/area-system-security, @vcsjones

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-System.Security Issues related to security practices for .NET developers. untriaged New issue has not been triaged by the area owner
Projects
None yet
Development

No branches or pull requests

2 participants