CertificateManagerValidateCertificates Method (ListX509Certificate2, String, String, Int32, CertificateManagerCertificateValidatorCompletionHandler) |
Namespace: Avaya.ClientServices
public void ValidateCertificates( List<X509Certificate2> certificateChain, string expectedServiceDomain, string expectedHostname, int port, CertificateManagerCertificateValidatorCompletionHandler completionHandler )
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:
For Wildcard certificates, a partial matching for DNS hostname is supported except for SIP service domains (RFC 5922). Following rules apply for partial matching:
*.example.com
foo.example.com
*.*.example.com
foo.bar.example.com
*.com
example.com
*.co.in
example.co.in
f*.example.com
foo.example.com
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.