Trait rustls::server::danger::ClientCertVerifier
source · 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 { ... }
}
Expand description
Something that can verify a client certificate chain
Required Methods§
sourcefn root_hint_subjects(&self) -> &[DistinguishedName]
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.
sourcefn verify_client_cert(
&self,
end_entity: &CertificateDer<'_>,
intermediates: &[CertificateDer<'_>],
now: UnixTime,
) -> Result<ClientCertVerified, Error>
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 implementer to handle invalid data. It is recommended that the implementer returns an InvalidCertificate error with the BadEncoding variant when these cases are encountered.
sourcefn verify_tls12_signature(
&self,
message: &[u8],
cert: &CertificateDer<'_>,
dss: &DigitallySignedStruct,
) -> Result<HandshakeSignatureValid, Error>
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.
sourcefn verify_tls13_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>
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.
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.
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 self.offer_client_auth()
.