Trait rustls::server::danger::ClientCertVerifier

pub trait ClientCertVerifier: Debug + Send + Sync {
    // Required methods
    fn root_hint_subjects(&self) -> &[DistinguishedName];
    fn verify_client_cert(
        &self,
        end_entity: &CertificateDer<'_>,
        intermediates: &[CertificateDer<'_>],
        now: UnixTime,
    ) -> Result<ClientCertVerified, Error>;
    fn verify_tls12_signature(
        &self,
        message: &[u8],
        cert: &CertificateDer<'_>,
        dss: &DigitallySignedStruct,
    ) -> Result<HandshakeSignatureValid, Error>;
    fn verify_tls13_signature(
        &self,
        message: &[u8],
        cert: &CertificateDer<'_>,
        dss: &DigitallySignedStruct,
    ) -> Result<HandshakeSignatureValid, Error>;
    fn supported_verify_schemes(&self) -> Vec<SignatureScheme>;

    // Provided methods
    fn offer_client_auth(&self) -> bool { ... }
    fn client_auth_mandatory(&self) -> bool { ... }
}

Something that can verify a client certificate chain

Required Methods

fn root_hint_subjects(&self) -> &[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 ClientCertVerifier::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 verify_client_cert( &self, end_entity: &CertificateDer<'_>, intermediates: &[CertificateDer<'_>], now: UnixTime, ) -> Result<ClientCertVerified, Error>

Verify the end-entity certificate end_entity is valid, acceptable, and chains to at least one of the trust anchors trusted by this verifier.

intermediates contains the intermediate certificates the client sent along with the end-entity certificate; it is in the same order that the peer sent them and may be empty.

Note that none of the certificates have been parsed yet, so it is the responsibility of the implementor to handle invalid data. It is recommended that the implementor returns an InvalidCertificate error with the BadEncoding variant when these cases are encountered.

fn verify_tls12_signature( &self, message: &[u8], cert: &CertificateDer<'_>, dss: &DigitallySignedStruct, ) -> Result<HandshakeSignatureValid, Error>

Verify a signature allegedly by the given client certificate.

message is not hashed, and needs hashing during the verification. The signature and algorithm are within dss. cert contains the public key to use.

cert has already been validated by ClientCertVerifier::verify_client_cert.

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, message: &[u8], cert: &CertificateDer<'_>, dss: &DigitallySignedStruct, ) -> 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 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 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 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().

Implementors

impl ClientCertVerifier for NoClientAuth

impl ClientCertVerifier for WebPkiClientVerifier