Validating X509 Certificates for SSL over HTTP in Exchange 2010
Last modified: September 29, 2010
Applies to: Exchange Server 2007 | Exchange Server 2010
The computer that is running Microsoft Exchange Server 2010 uses self-signed X509 certificates to authenticate calls to Exchange Web Services (EWS) proxy classes. You must create a certificate validation callback method for your application; otherwise, calls to EWS will fail with a certificate error.
The ServicePointManager class in the Microsoft .NET System.Net namespace enables you to hook up a validation callback method by setting the ServerCertificateValidationCallback property. This topic provides information about how to set up your application to use a certificate validation callback method. The code example in this topic shows how to create a method that examines the certificate that is returned in a call to an EWS operation.
To create an X509 certificate validation callback method
Include references to the required Microsoft .NET Framework namespaces.
using System.Net; using System.Net.Security; using System.Security.Cryptography.X509Certificates;Create a certificate validation callback method that your application can call. For an example of a certificate validation callback method, see the code example later in this topic.
Before calling EWS, set the ServerCertificateValidationCallback property of the ServicePointManager class to your certificate validation callback method.
ServicePointManager.ServerCertificateValidationCallback = CertificateValidationCallback;
The following example shows how to create an X509 certificate validation callback method. This method will validate an X509 certificate. This method only returns true if either of the following criteria are met:
The certificate is valid and signed with a valid root certificate.
The certificate is self-signed by the server that returned the certificate.
.gif "Security note") Security Note |
|---|
The certificate validation callback method in this example may provide sufficient security for development and testing of EWS applications. However, it may not provide sufficient security for your deployed application. You should always make sure that the certificate validation callback method that you use meets the security requirements of your organization. |
private static bool CertificateValidationCallBack(
object sender,
System.Security.Cryptography.X509Certificates.X509Certificate certificate,
System.Security.Cryptography.X509Certificates.X509Chain chain,
System.Net.Security.SslPolicyErrors sslPolicyErrors)
{
// If the certificate is a valid, signed certificate, return true.
if (sslPolicyErrors == System.Net.Security.SslPolicyErrors.None)
{
return true;
}
// If there are errors in the certificate chain, look at each error to determine the cause.
if ((sslPolicyErrors & System.Net.Security.SslPolicyErrors.RemoteCertificateChainErrors) != 0)
{
if (chain != null && chain.ChainStatus != null)
{
foreach (System.Security.Cryptography.X509Certificates.X509ChainStatus status in chain.ChainStatus)
{
if ((certificate.Subject == certificate.Issuer) &&
(status.Status == System.Security.Cryptography.X509Certificates.X509ChainStatusFlags.UntrustedRoot))
{
// Self-signed certificates with an untrusted root are valid.
continue;
}
else
{
if (status.Status != System.Security.Cryptography.X509Certificates.X509ChainStatusFlags.NoError)
{
// If there are any other errors in the certificate chain, the certificate is invalid,
// so the method returns false.
return false;
}
}
}
}
// When processing reaches this line, the only errors in the certificate chain are
// untrusted root errors for self-signed certificates. These certificates are valid
// for default Exchange Server installations, so return true.
return true;
}
else
{
// In all other cases, return false.
return false;
}
}
For information about certificate validation code, see ServerCertificateValidationCallback.