Struct SkipVerification 

struct SkipVerification {
    provider: Arc<CryptoProvider>,
}

TLS certificate verifier that skips all verification. Testing only.

Fields

provider: Arc<CryptoProvider>

The provider whose signature schemes this verifier advertises.

Held rather than hardcoded because supported_verify_schemes is not a claim about what this verifier checks — it checks nothing — but about what the ClientHello offers. See that method for why the distinction has teeth.

Implementations

impl SkipVerification

fn new() -> Self

Use whichever provider this process installed, falling back to the one this crate compiles with.

Taking the installed provider rather than naming ring unconditionally keeps the verifier’s advertised schemes in step with the schemes the rest of the handshake was actually built from, however the embedding binary configured rustls.

Trait Implementations

impl Debug for SkipVerification

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

Formats the value using the given formatter.

impl ServerCertVerifier for SkipVerification

fn supported_verify_schemes(&self) -> Vec<SignatureScheme>

Every scheme the active provider can verify.

This looks like dead weight on a verifier that verifies nothing, and it is not: rustls sends this list as the ClientHello’s signature_algorithms extension, so it decides which certificates a server is willing to offer us — before this verifier is consulted at all.

Read off the provider rather than written out by hand, because a hand-written list omits whatever it forgets — ECDSA_NISTP521_SHA512 is the easy one to miss. A relay with a P-521 leaf would then fail a verification-disabled connection because of what this client offered, not because of anything wrong with the relay — and for the conformance probe that consumes this crate, a failure it manufactured itself is the one result it must never record.

The provider’s own list is the floor, so the offer widens whenever the provider’s does. It is not the ceiling, because it cannot be: ring does not implement P-521 at all, so deferring to it alone still leaves that certificate unreachable. That constraint does not apply here — this verifier accepts every certificate without looking at it, so a scheme it could not check is one it never needs to. Advertising a superset is exactly right for a verifier that verifies nothing, and would be wrong for any verifier that does.

fn verify_server_cert( &self, _end_entity: &CertificateDer<'_>, _intermediates: &[CertificateDer<'_>], _server_name: &ServerName<'_>, _ocsp_response: &[u8], _now: UnixTime, ) -> Result<ServerCertVerified, Error>

Verify the end-entity certificate end_entity is valid for the hostname dns_name and chains to at least one trust anchor.

fn verify_tls12_signature( &self, _message: &[u8], _cert: &CertificateDer<'_>, _dcs: &DigitallySignedStruct, ) -> Result<HandshakeSignatureValid, Error>

Verify a signature allegedly by the given server certificate.

fn verify_tls13_signature( &self, _message: &[u8], _cert: &CertificateDer<'_>, _dcs: &DigitallySignedStruct, ) -> Result<HandshakeSignatureValid, Error>

Verify a signature allegedly by the given server certificate.

fn requires_raw_public_keys(&self) -> bool

Returns whether this verifier requires raw public keys as defined in RFC 7250.

fn root_hint_subjects(&self) -> Option<&[DistinguishedName]>

Return the [DistinguishedName]s of certificate authorities that this verifier trusts.