Trait rustls::verify::ClientCertVerifier
source · pub trait ClientCertVerifier: Send + Sync {
// Required methods
fn client_auth_root_subjects(&self) -> &[DistinguishedName];
fn verify_client_cert(
&self,
end_entity: &Certificate,
intermediates: &[Certificate],
now: SystemTime,
) -> Result<ClientCertVerified, Error>;
// Provided methods
fn offer_client_auth(&self) -> bool { ... }
fn client_auth_mandatory(&self) -> bool { ... }
fn verify_tls12_signature(
&self,
message: &[u8],
cert: &Certificate,
dss: &DigitallySignedStruct,
) -> Result<HandshakeSignatureValid, Error> { ... }
fn verify_tls13_signature(
&self,
message: &[u8],
cert: &Certificate,
dss: &DigitallySignedStruct,
) -> Result<HandshakeSignatureValid, Error> { ... }
fn supported_verify_schemes(&self) -> Vec<SignatureScheme> { ... }
}
Expand description
Something that can verify a client certificate chain
Required Methods§
sourcefn client_auth_root_subjects(&self) -> &[DistinguishedName]
fn client_auth_root_subjects(&self) -> &[DistinguishedName]
Returns the Subjects of the client authentication trust anchors to share with the client when requesting client authentication.
These must be DER-encoded X.500 distinguished names, per RFC 5280.
They are sent in the certificate_authorities
extension of a
CertificateRequest
message.
If the return value is empty, no CertificateRequest message will be sent.
sourcefn verify_client_cert(
&self,
end_entity: &Certificate,
intermediates: &[Certificate],
now: SystemTime,
) -> Result<ClientCertVerified, Error>
fn verify_client_cert( &self, end_entity: &Certificate, intermediates: &[Certificate], now: SystemTime, ) -> 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.
Provided Methods§
sourcefn offer_client_auth(&self) -> bool
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
.
sourcefn client_auth_mandatory(&self) -> bool
fn client_auth_mandatory(&self) -> bool
Return true
to require a client certificate and false
to make
client authentication optional.
Defaults to Some(self.offer_client_auth())
.
sourcefn verify_tls12_signature(
&self,
message: &[u8],
cert: &Certificate,
dss: &DigitallySignedStruct,
) -> Result<HandshakeSignatureValid, Error>
fn verify_tls12_signature( &self, message: &[u8], cert: &Certificate, 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.
This trait method has a default implementation that uses webpki to verify the signature.
sourcefn verify_tls13_signature(
&self,
message: &[u8],
cert: &Certificate,
dss: &DigitallySignedStruct,
) -> Result<HandshakeSignatureValid, Error>
fn verify_tls13_signature( &self, message: &[u8], cert: &Certificate, 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.
This trait method has a default implementation that uses webpki to verify the signature.
sourcefn supported_verify_schemes(&self) -> Vec<SignatureScheme>
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.
This trait method has a default implementation that reflects the schemes supported by webpki.