This project is read-only.

Evaluating the SslPolicyErrors.RemoteCertificateNameMismatch Security Zone

Jul 24, 2013 at 1:55 PM
Previously in my ValidateServerCertificate delegate if the policy error was a RemoteCertificateNameMismatch I would evaluate the security zone. How do I obtain the Request Uri so that I can evaluate the zone using the FtpClient library?

if (sslPolicyErrors == SslPolicyErrors.RemoteCertificateNameMismatch)
{

System.Security.Policy.Zone z = System.Security.Policy.Zone.CreateFromUrl (((HttpWebRequest)sender).RequestUri.ToString());

if (z.SecurityZone == System.Security.SecurityZone.Intranet || z.SecurityZone == System.Security.SecurityZone.MyComputer)
{
  return true;
}

return false;
}
Coordinator
Jul 24, 2013 at 2:26 PM
I'm not sure what you're asking for. The only place URI's are used in this project are in the static methods that accept them and they are only used to get the connection information needed to fulfill the request. If you need a URI beyond that you need to store it somewhere accessible to your event handler.
Jul 24, 2013 at 2:42 PM
My question is simply this: Regarding the SSLPolicyError of RemoteCertificateNameMismatch when using the FtpClient component is there an example that shows how to evaluate the name mismatch more completely than a simple return true or false. This addresses
the situation where we have one set of certs for DEV and a different set for PROD - a rather common practice. The way I previously did it was to pull the request Uri to determine if the security zone was a server on our local intranet etc. Best Regards, Mark
Gillen ----- jptrosclair <[email removed]> wrote:
Coordinator
Jul 26, 2013 at 2:53 PM
I guess you need to create a ftp:// Uri object using FtpClient.Host in your certificate validation handler, to do something similar to the example above.
Coordinator
Jul 26, 2013 at 2:55 PM
Something like this:
z = System.Security.Policy.Zone.CreateFromUrl(string.Format("ftp://{0}/", ftpClient.Host))

if(z.SecurityZone == SecurityZone.Intranet...) {
     e.Accept = true;
}
Jul 26, 2013 at 3:56 PM
Yep, that's precisely the conclusion I arrived at!

Thanks