Avaya Client Services API Reference (Windows)
Avaya Client Services API Reference (Windows)
Avaya.ClientServices
CertificateManager Class
CertificateManager Methods
ValidateCertificates Method
ValidateCertificates Method (List(X509Certificate2), CertificateManager.CertificateValidatorCompletionHandler)
ValidateCertificates Method (List(X509Certificate2), String, String, Int32, CertificateManager.CertificateValidatorCompletionHandler)

# CertificateManager ValidateCertificates Method (List X509Certificate2 , String, String, Int32, CertificateManager CertificateValidatorCompletionHandler)

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#
Copy

    public void ValidateCertificates(
    	List<X509Certificate2> certificateChain,
    	string expectedServiceDomain,
    	string expectedHostname,
    	int port,
    	CertificateManagerCertificateValidatorCompletionHandler completionHandler
    )

#### Parameters

certificateChain
  Type: System.Collections.Generic
  List
  X509Certificate2
  Certificate chain subjected to validation
expectedServiceDomain
  Type: System
  String
  The domain the server is expected to be authoritative for.
expectedHostname
  Type: System
  String
  The hostname that was used to connect to the server that provided the certificates.
port
  Type: System
  Int32
  The port number that was used to connect to the server that provided the certificates.
completionHandler
  Type: Avaya.ClientServices
  CertificateManager
  CertificateValidatorCompletionHandler
  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.
   Copy

       *.example.com

   matches with
   Copy

       foo.example.com

   Copy

       *.*.example.com

   does not match with
   Copy

       foo.bar.example.com

2. Internet TLDs (Top Level Domains) do not match.
   Copy

       *.com

   does not match with
   Copy

       example.com

   Copy

       *.co.in

   does not match with
   Copy

       example.co.in

3. Partial domain name match is not supported.
   Copy

       f*.example.com

   does not match with
   Copy

       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

#### Reference

CertificateManager Class
ValidateCertificates Overload
Avaya.ClientServices Namespace

© 2017 Avaya LLC. All Rights Reserved.