Struct TrustAnchor 

#[non_exhaustive]
pub struct TrustAnchor {
    pub subject: Name,
    pub subject_public_key_info: SubjectPublicKeyInfoOwned,
    pub name_constraints: Option<NameConstraints>,
}

A trust anchor used to terminate path validation.

A trust anchor is typically either a self-signed root CA certificate or a raw (name, SPKI) pair extracted from a platform trust store. The trust anchor itself is not signature-verified — it is trusted by definition (RFC 5280 §6.1.1(c)).

Validity period: RFC 5280 §6.1.1(c) explicitly excludes the trust anchor’s notBefore/notAfter from path validation. An expired root CA certificate used as a trust anchor will still anchor valid paths — this is intentional behavior, not a bug. Callers are responsible for ensuring their trust store contains the anchors they intend to trust.

PartialEq is byte-level, not semantic: The derived PartialEq compares fields verbatim. Two anchors representing the same CA may compare unequal if their DER encodings differ — for example, one AlgorithmIdentifier with explicit NULL parameters and another with absent parameters are both valid for RSA (RFC 3279 §2.3.1) but will not be equal under ==. Do not use == to deduplicate a trust store; use names_match and compare algorithm.oid plus subject_public_key bytes directly. Path validation already handles this internally, so it is not affected by this encoding difference.

Stability

TrustAnchor is #[non_exhaustive]: new fields may be added in minor versions. Construct via TrustAnchor::new, TrustAnchor::from_cert, or TrustAnchor::from/try_from. Do not use struct literal syntax.

Fields (Non-exhaustive)

Non-exhaustive structs could have additional fields added in future. Therefore, non-exhaustive structs cannot be constructed in external crates using the traditional Struct { .. } syntax; cannot be matched against without a wildcard ..; and struct update syntax will not work.

subject: Name

The subject distinguished name of the trust anchor.

subject_public_key_info: SubjectPublicKeyInfoOwned

The subject public key info of the trust anchor.

Must be a valid SPKI for the chosen signature algorithm. An empty or malformed SPKI will cause signature verification to fail with Error::NoTrustedPath (no anchor matched), not a panic.

name_constraints: Option<NameConstraints>

NameConstraints from the trust anchor certificate, if present.

When set, chain_walk seeds the initial permitted_subtrees and excluded_subtrees state from this value before walking the chain. Populated automatically by from_cert; None for programmatically constructed anchors unless explicitly set.

Implementations

impl TrustAnchor

pub const fn new( subject: Name, subject_public_key_info: SubjectPublicKeyInfoOwned, ) -> Self

Create a trust anchor from raw subject name and SPKI.

pub fn from_cert(cert: Certificate) -> Self

Extract subject name and SPKI from a certificate to create a trust anchor.

This is the typical constructor when your trust store contains full self-signed root CA certificates.

Prefer TrustAnchor::from (i.e. TrustAnchor::from(&cert)) when you need to keep cert alive after building the anchor.

Warning: malformed NameConstraints are silently dropped

If the anchor certificate contains a malformed or unparseable NameConstraints extension, from_cert silently sets name_constraints = None and continues. The resulting anchor will not enforce any name-constraint restrictions from that extension, which may widen the trust scope beyond what the certificate intended.

For strict RFC 5280 §4.2 compliance — where a critical extension that cannot be parsed MUST cause rejection — use TrustAnchor::try_from instead. That path returns Err(DerError) so the caller can reject the malformed anchor rather than silently operating without name constraints.

Trait Implementations

impl Clone for TrustAnchor

fn clone(&self) -> TrustAnchor

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for TrustAnchor

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for TrustAnchor

fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl Eq for TrustAnchor

impl From<&CertificateInner> for TrustAnchor

fn from(cert: &Certificate) -> Self

Converts to this type from the input type.

impl PartialEq for TrustAnchor

fn eq(&self, other: &TrustAnchor) -> bool

Tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl Serialize for TrustAnchor

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.

impl StructuralPartialEq for TrustAnchor

impl TryFrom<CertificateInner> for TrustAnchor

Fail-closed construction from an owned certificate.

Returns Err(DerError) if the certificate contains a NameConstraints extension with malformed DER. Use this when building a trust store that must reject certificates with unparseable critical extensions per RFC 5280 §4.2.

The error type is the opaque DerError newtype rather than der::Error so that a future major-version bump in the der crate does not cascade into a semver break here.

Why only TryFrom<Certificate> and not TryFrom<&Certificate>

TryFrom<&Certificate> would conflict with the blanket impl impl<T, U: Into<T>> TryFrom<U> provided by Rust core, because From<&Certificate> is already implemented (and From implies Into). Use TrustAnchor::try_from(cert.clone()) if you need to keep cert.

type Error = DerError

The type returned in the event of a conversion error.

fn try_from(cert: Certificate) -> Result<Self, Self::Error>

Performs the conversion.