Skype for business/Lync之证书解析（一）：证书原理

 

---by 老朱

Skype for business server 2015（以下简称SFB 2015）已经出来一段时间了，接下来微软还有一大批的东西来袭，已经有很多朋友要么忙着测试，要么忙着部署SFB 2015了。不管是部署SFB，还是以前的LYNC，一个绕不开的东西就是证书，不要说LYNC绕不过，现在几乎所有微软产品都绕不过，像邮件、远程桌面服务、私有云、混合云等，都将用到证书，其实不光微软，微软之外很多产品与解决方案都绕不过证书这东西，谁叫它是一个基础的东西呢？虽然很多人通过折腾LYNC与exchange等，已经对证书比较熟悉了，但我发现很多朋友仍然不明其理，一有变动就有点晕头，这里也借SFB这个风，顺便把证书的相关原理讲一下，然后再讲SFB的证书问题，并在后面举一些例子，让大家举一翻三，不管是在SFB中，还是邮件中，还是与其他第三方解决方案互通，都能够顺利面对证书配置，我相信真正理解了证书原理，不管在什么环境中，通常10分钟都能够搞定问题，至少能够准确地发现问题所在。

由于下面的文章是我原来在内部技术交流的一个PPT，所以文章主要以图为主，对于需要说明的部分我再配以文字。

要说证书，实际上先得说公钥技术，严格来说，他们是有区别的，但有时我们习惯把证书、公钥、PKI、CA说成一个东西，怎么说我倒觉得不重要，只是在不同的语境下要会分辨。

上图是大家经常遇到的，为什么会报这个错呢？不用我这里先做解释，读完此文，你自己就知道了，如果还不知道，那就。。再读一遍呗。

单密钥的缺点是怎么安全地分发。

公钥解决了分发问题，因为公钥谁都可以知道，而且就是要别人知道。

上图警察为了把消息安全地告诉局长，于是他就用局长的公钥加密消息（记住，公钥就是给别人的，就是要让别人知道的），局长接着用自己的私钥解开。

那你会说为什么警察（周缙）要用局长的公钥加密，而不用自己的私钥加密再发给局长呢？不是一样的吗？当然不一样，因为我们说过公钥别人知道，你用私钥加密那不是人人都可以用公钥解密，这就相当于没有加密了，所以私钥是不会用来加密的，只有公钥才会用来加密。

但是，虽然私钥不用来加密，但由于私钥只有当事人有，所以它可以用来进行身份认证，还是上面的例子，局长收到了一条他公钥加密的消息，但由于别人都有他的公钥，谁都可以发消息给他啊，怎样来保证这个消息就是警察周缙发的，而不是其他人发的假消息呢？（比如说是周克华发的，骗局长鸣金收兵：））这时周缙就可以用自己的私钥签个名，然后局长用周缙的公钥解密，由于只有周缙的公钥才能解密，也就证明了此消息是周缙发出的，确认了消息的真实性。

当然，公钥也可以用来认证，后面会讲到，当他与安全个体对应，成为安全个体证书的一部分时，就有此功能了，具体下面会讲到。

 

既然单密钥技术和公钥技术各有优缺点，何不把二者结合起来，既然公钥加解密速度慢，那何不用公钥加密单密钥（毕竟单密钥很短，要加密的文档或信息通常很大），然后用单密钥来加解密文档或信息，这样不就把单密钥的分发和公钥加解密速度问题都解决了？实际上SSL就是这样来处理的。

当然用私钥加密同样面临速度慢的问题，那私钥怎样来实现签名（本质是加密）呢？由于直接签名（加密）整个文档太慢，那就把文档提取个散列，然后签名这个散列吧，这样就解决了这个问题。大家下载软件时，经常看到有个MD5的文件，大家就可以通过MD5工具对下载的软件生成一个MD5散列值，然后与MD5文件中的值对比，如果一致，表明你下载的软件没有被篡改（比如被人挂马）。

 

前面讲了，虽然公钥可以发给任何人，但怎样确认你就是这个公钥的主人呢？这个问题就像邮件如果没有SPF检测，你可以冒充微软、冒充IBM，冒充任何公司或个人给别人发邮件了。其实在这里我想也可以模仿邮件的SPF机制，比如你收到张三的公钥，那怎样来判断这个公钥就是张三的呢？那你可以先计算出公钥的散列，然后到张×××司的DNS服务器查询张×××钥的散列（比如是一条TXT记录），如果二者相匹配，则表明是张三的公钥，如果不匹配，则表明是仿冒的。哈哈，我是不是想得太简单了，不过，现在的世界是怎样来解决这个问题的呢？现在的世界就是引入了证书，引入了证书认证机构CA，所谓证书者，证明之用也，就是把安全个体与公钥绑定，证明此公钥就是安全个体的，当然，如何证明，就由CA等的证书基础架构来实现了。

证书包含公钥，但不等于公钥。

大家的SFZ其实就是一份证书，证书也就是一个SFZ。

比如证书里面的版本就相当于SFZ的第几代，而序列号就相当于SFZ号码，颁发者相当于签发机关，有效期相当于SFZ的有效期限，而上级CA的签名相当于国徽（代表国家）。而使用者相当于姓名。

记住证书包含的三个最重要的部分：安全个体（CN），公钥，上级认证（签名）。比如CN是www.sina.com.cn，而你访问时不是用这个域名访问，而是用域名对应的IP去访问，仍然会报证书错误的，因为安全个体没有对应上。

现实世界申请证书是一件严肃的事情，就像办SFZ一样的道理，注意，你申请证书时是不用把私钥提交给CA的，因为私钥只应该你自己知道和保存，所以你在购买公网证书服务时通常最后有个合成操作，就是把本地的私钥和证书进行合成，以便导入相关的服务器。

 

从证书的验证过程注意到根证书是很重要的，因为一个证书是否合法，最终都会由它进行验证。这也是为什么为了信任服务器证书，而经常要在客户端导入根证书的原因，因为没有根证书，根本无法验证服务器证书的真实性。经常看到一个无意义的操作就是把服务器证书导入客户端，其实这没有意义，因为没有信任根证书，你把服务器证书放在哪里都无用。

 

同样，购买公用证书时，证书链的层次越少越好，因为一般系统只内置了根证书，如果中间证书链多的话，还需要到网上去取，这样必定增加连接时间，再加上这些机构一般在国外，你可能会遇到什么连接超时等问题，这种坏的结果是你应用根本没法用。

 

证书吊销列表也是在证书实施中经常遇到的问题，很多报错与它就相关，有些应用有相关选项来配置是否检查CRL，如IE，而有些应用则必须要求检查CRL，这时就要注意CRL的正确发布了，比如通常CA在内部，CRL也在内部，那如果有应用要从外部访问CRL时，如果没有发布CRL，是根本不可能访问到的，这也就出现了CRL问题。

注意，通常我们的SSL，也就是HTTPS，通常只验证服务器的身份，服务器会把它的证书传给客户端，客户端会调用本地根证书进行验证。类似我们访问普通的网银。

而我们插U卡的网银，则是不仅仅要验证服务器是不是假冒的，还要验证客户端这边的身份，这就是双向验证。

好了，关于公钥与证书的基本原理就讲到这里，如果有疑惑，欢迎提问。

“51cto十周年博客活动”正在进行，你也来参加吧~

   活动地址：http://51ctoblog.blog.51cto.com/26414/1679643

转载于:https://blog.51cto.com/ultradream/1654190