EzHttp 使用Https协议时证书如何部署

标签：return   函数   替换   get   mrti   ssl   blank   end   打包   

今天为EzHttp增加了https支持, EzHttp介绍见这里：使用EzHttp框架 开发基于HTTP协议的CS轻应用

服务端启动时会创建自签名证书，并将其绑定到启动参数url对应的端口上。

服务端导出的cer文件（证书的公钥部分）位于服务端程序运行目录下。

复制该文件到客户端目录并调用指定证书文件的初始化函数即可。

问：为什么需要手动部署而不使用客户端连接服务端自动下载？

答：因为是自签名证书，通过标准http协议传输有被劫持的风险。

如12306这种，中间人可以伪造一个名称和创建时间一样的证书替换来欺骗客户端。

所以如果发布客户端，最好是在客户端程序打包时一并打包。

部署方式

服务端不需要额外的处理。

将cer文件复制到客户端目录后，通过调用如下方法对客户端进行初始化即可。

EzClient.Initialize("https://127.0.0.1:9555/", ".\\ezhttp.cer");

服务安全性小贴士

大家可能都应该了解，一般C#客户端在使用https请求时，如果网站证书是无效证书（自签名、过期等），我们就需要添加一个证书回调函数来决定是否通过服务端证书验证

public RemoteCertificateValidationCallback ServerCertificateValidationCallback { get; set; }

一般我们写的工具的时候，回调实现都是这样的，因为网上的代码基本上都是这样的，于是越来越多的程序里面的回调函数也是如此简单而粗暴，所以这就带来了安全性问题。

private bool ServerCertificateValidationCallback(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors)
        {
            return true;
        }

这表示什么呢？这表示客户端接受一切服务端证书，不管真假。

但这在开发我们自己的基于https的服务时是绝对不可取的，特别是使用自签名证书的时候，操作系统通过回调将验证服务器证书的任务交给了客户端程序。

我们开发时候要保证客户端请求发送的目的地是我们自己web服务而不是某个中间人。

因此，我在开发EzHttp的时候，通过从服务端导出的客户端证书来验证服务端的合法性。遵循了基于https的服务的证书验证的最佳实践。

EzHttp 使用Https协议时证书如何部署

标签：return   函数   替换   get   mrti   ssl   blank   end   打包   

原文地址：http://www.cnblogs.com/mrtiny/p/6773458.html