Trait ClientVerifier 

pub trait ClientVerifier:
    Debug
    + Send
    + Sync {
    // Required methods
    fn verify_identity(
        &self,
        identity: &ClientIdentity<'_>,
    ) -> Result<PeerVerified, Error>;
    fn verify_tls12_signature(
        &self,
        input: &SignatureVerificationInput<'_>,
    ) -> Result<HandshakeSignatureValid, Error>;
    fn verify_tls13_signature(
        &self,
        input: &SignatureVerificationInput<'_>,
    ) -> Result<HandshakeSignatureValid, Error>;
    fn root_hint_subjects(&self) -> Arc<[DistinguishedName]>;
    fn supported_verify_schemes(&self) -> Vec<SignatureScheme>;

    // Provided methods
    fn client_auth_mandatory(&self) -> bool { ... }
    fn offer_client_auth(&self) -> bool { ... }
    fn supported_certificate_types(&self) -> &'static [CertificateType] { ... }
}

Something that can verify a client certificate chain

Required Methods

fn verify_identity( &self, identity: &ClientIdentity<'_>, ) -> Result<PeerVerified, Error>

Verify the client’s identity.

Note that none of the certificates have been parsed yet, so it is the responsibility of the implementer to handle invalid data. It is recommended that the implementer returns a CertificateError::BadEncoding error when these cases are encountered.

fn verify_tls12_signature( &self, input: &SignatureVerificationInput<'_>, ) -> Result<HandshakeSignatureValid, Error>

Verify a signature allegedly by the given client certificate.

If and only if the signature is valid, return Ok(HandshakeSignatureValid). Otherwise, return an error – rustls will send an alert and abort the connection.

This method is only called for TLS1.2 handshakes. Note that, in TLS1.2, SignatureSchemes such as SignatureScheme::ECDSA_NISTP256_SHA256 are not in fact bound to the specific curve implied in their name.

fn verify_tls13_signature( &self, input: &SignatureVerificationInput<'_>, ) -> Result<HandshakeSignatureValid, Error>

Verify a signature allegedly by the given client certificate.

This method is only called for TLS1.3 handshakes.

This method is very similar to verify_tls12_signature, but note the tighter ECDSA SignatureScheme semantics in TLS 1.3. For example, SignatureScheme::ECDSA_NISTP256_SHA256 must only validate signatures using public keys on the right curve – rustls does not enforce this requirement for you.

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

Returns the DistinguishedName subjects that the server will hint to clients to identify acceptable authentication trust anchors.

These hint values help the client pick a client certificate it believes the server will accept. The hints must be DER-encoded X.500 distinguished names, per RFC 5280 A.1. They are sent in the certificate_authorities extension of a CertificateRequest message when ClientVerifier::offer_client_auth is true. When an empty list is sent the client should always provide a client certificate if it has one.

Generally this list should contain the DistinguishedName of each root trust anchor in the root cert store that the server is configured to use for authenticating presented client certificates.

In some circumstances this list may be customized to include DistinguishedName entries that do not correspond to a trust anchor in the server’s root cert store. For example, the server may be configured to trust a root CA that cross-signed an issuer certificate that the client considers a trust anchor. From the server’s perspective the cross-signed certificate is an intermediate, and not present in the server’s root cert store. The client may have the cross-signed certificate configured as a trust anchor, and be unaware of the root CA that cross-signed it. If the server’s hints list only contained the subjects of the server’s root store the client would consider a client certificate issued by the cross-signed issuer unacceptable, since its subject was not hinted. To avoid this circumstance the server should customize the hints list to include the subject of the cross-signed issuer in addition to the subjects from the root cert store.

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

Return the list of SignatureSchemes that this verifier will handle, in verify_tls12_signature and verify_tls13_signature calls.

This should be in priority order, with the most preferred first.

Provided Methods

fn client_auth_mandatory(&self) -> bool

Return true to require a client certificate and false to make client authentication optional. Defaults to self.offer_client_auth().

fn offer_client_auth(&self) -> bool

Returns true to enable the server to request a client certificate and false to skip requesting a client certificate. Defaults to true.

fn supported_certificate_types(&self) -> &'static [CertificateType]

Returns which CertificateTypes this verifier supports.

Returning an empty slice will result in an error. The default implementation signals support for X.509 certificates. Implementations should return the same value every time.

See RFC 7250 for more information.

Implementors

impl ClientVerifier for NoClientAuth

impl ClientVerifier for WebPkiClientVerifier