Click or drag to resize

CertificateManagerValidateCertificates Method (ListX509Certificate2, String, String, Int32, CertificateManagerCertificateValidatorCompletionHandler)

Performs a trust validation of a certificate chain to determine if the secure connection with the peer can be trusted.

Namespace:  Avaya.ClientServices
Assembly:  AvayaClientServices (in AvayaClientServices.dll) Version: 550.0.60.0
Syntax
C#
public void ValidateCertificates(
	List<X509Certificate2> certificateChain,
	string expectedServiceDomain,
	string expectedHostname,
	int port,
	CertificateManagerCertificateValidatorCompletionHandler completionHandler
)

Parameters

certificateChain
Type: System.Collections.GenericListX509Certificate2
Certificate chain subjected to validation
expectedServiceDomain
Type: SystemString
The domain the server is expected to be authoritative for.
expectedHostname
Type: SystemString
The hostname that was used to connect to the server that provided the certificates.
port
Type: SystemInt32
The port number that was used to connect to the server that provided the certificates.
completionHandler
Type: Avaya.ClientServicesCertificateManagerCertificateValidatorCompletionHandler
The completion handler for this operation.
Remarks

While establishing secure connection, the certificate chain is received as part of SSL Handshake that can be validated using this method. The validation result determines if the connection is secure and peer can be trusted. This method performs trust validation asynchronously and upon completion a result is reported through completionHandler argument.

As per RFC 5280, the trust validation involves a certificate chain building which leads up to a trusted anchors. For client application, if the private trust store has been configured, it will be solely used to build a certificate chain. In a case when the private trust store is unavailable, the system certificate stores will be used. This method does not fall back between the certificate stores (private trust store vs system certificate stores) or shares them while looking for the trusted anchors.

As part of the trust validation, this method performs an extended hostname validation (known as "server identity validation") by matching different identifiers as explained below. The configured hostname is internally supplied by each "Service" or "Provider" calling this method. The client application can configure a policy to ignore the hostname validation errors. Such policy can be set via ContinueOnTlsServerIdentityFailure property. By default, this method currently ignores all hostname validation errors.

The hostname is matched as per the following order of identifiers:

  • The match is performed against identifiers like DNS name and IP address from certificate's subject alternative name (SAN) attribute.
  • If subject alternative name attribute is unavailable, the match is performed against certificate's common name (CN) attribute.
For SIP service domains, a full match is performed against URI and DNS parameters value from certificate's subject alternative name attribute.

For Wildcard certificates, a partial matching for DNS hostname is supported except for SIP service domains (RFC 5922). Following rules apply for partial matching:

  1. The match is performed at a single level sub-domain.
    *.example.com
    matches with
    foo.example.com
    *.*.example.com
    does not match with
    foo.bar.example.com
  2. Internet TLDs (Top Level Domains) do not match.
    *.com
    does not match with
    example.com
    *.co.in
    does not match with
    example.co.in
  3. Partial domain name match is not supported.
    f*.example.com
    does not match with
    foo.example.com
  4. Partial matching for SIP service domain is not supported.

This method allows client application to supply various hostname identifiers to be used while performing hostname validation.This method can be substituted for any existing hostname validation method. The client application that wants perform hostname validation using service type can use expectedServiceDomain parameter leaving expectedHostname empty and vice versa. These two fields are mutually exclusive.

This method verifies certificate's revocation status, however, this feature is not supported on iOS. The revocation status of an entire certificate chain is verified using OCSP or CRL. The revocation check using OCSP is preferred over CRL. The client application can configure the security policy to be used while processing the revocation errors. The security policy can be configured by setting RevocationCheckPolicy.

See Also