SSL安全技术可用于大部分的网站，它主要用来处理重要的安全数据。SSL在服务器和客户端之间建立了一条安全的加密连接，最常见的是WEB服务器和浏览器或者客户端计算机上的Email客户端之间的连接。SSL被公认为一种安全性协议，因为它为加密连接指定了加密算法和必要变量，使用SSL的安全连接的目的，就是为了使数据在服务器和客户端之间传递的时候受到保护，比如信用卡号，登入凭证，以及其他的一些重要数据。
想用SSL建立一个受保护的连接，就必须在服务器上安装证书，内部CA和公共CA都可以给SSL颁发证书。对于面向internet的网站，通常会使用公共CA机构颁发的证书，因为它们颁发的证书是默认被信任的，但是你使用本地CA颁发的证书也是可以使用的。这两种CA颁发的证书都能够保障网站的安全性，但是大多数的客户端访问网站的时候，他们是无法信任使用内部CA颁发的证书的。实际上不受信任的证书仍然会对连接进行保护，但是它会在客户端连接到网站的时候发送一个警告信息给他们，很多公司都不想访问网站时出现这个警告信息，所以对于面向Internet的网站最好是使用公共证书。互联网的浏览器都会预先安装一个受信任CA的列表，它们会将这个列表中的CA保存到受信任的根证书颁发机构中。
在我们选择购买公共证书的时候需要注意，不是任何公共证书都保证能够自动被所有客户端信任的，所以在购买之前要确保你选择的证书供应商提供的证书是全球信任的，并且它的CA证书会在客户端预装的受信任的根证书颁发机构中。
使用SSL证书来保护连接
每个证书在被颁发后都会有一个配对秘钥，配对秘钥由一个公有秘钥和一个私有秘钥组成，这两个秘钥在加密处理的时候都会被用到，用公有秘钥加密的数据只能用它对应的私有秘钥解密，反之亦然，每个配对秘钥都是唯一的。
每个证书除了有配对秘钥以外，还会有它的对象名，这个对象名用于标识出证书安装在哪台服务器或网站上。当使用网页浏览器去访问一个受保护的网站的时候，客户端和服务器会建立一个SSL连接，这个SSL连接是在SSL握手期间建立的，这个握手动作的具体步骤如下：
用户在网页浏览器中输入一个HTTPS的URL
网页浏览器连接到网站，并且请求服务器去验证它的身份
WEB服务器发送它的SSL证书给客户端，证书中包含了该证书的公钥
客户端对服务器的证书进行检查，它会检查证书的对象名，并将对象名与访问服务器的URL进行比较，它还会检查证书是否是根信任证书颁发机构颁发的，并且在证书吊销列表分发点中确认是否此证书已被吊销。
如果所有的检查都通过了，客户端会生成一个对称加密密钥，客户端和服务器通过这个对称加密密钥来解密数据，因为公钥和私钥的配对秘钥在对大量数据进行加密和解密的操作时效率不高，所以客户端会生成一个对称秘钥，然后通过服务器的公钥将这个对称秘钥进行加密，最后客户端会把这个加密好的对称秘钥发送给服务器。
服务器使用它的私钥去解密收到的对称秘钥，现在服务器和客户端都有相同的对称秘钥，数据就可以在两者之间进行安全的传输了。
上面的过程包含了几个非常重要的检查，首先服务器出示它的SSL证书用于提供自身的身份标识给客户端，如果证书中的服务器名称和客户端请求的URL相匹配，并且该证书是由一个受信任的颁发机构颁发的，客户端会信任并将服务器认为是一个有效的身份标识。另外客户端还会检查证书的有效性，它会去检查证书的生命周期，以及在证书吊销列表中检查是否有与该证书匹配的对象。所以建立一个SSL会话不仅仅是对加密进行管理，而且需要执行从服务器到客户端的验证动作。
注意：客户端验证不包含在常规的SSL握手动作中，意思就是客户端可以不将自己的身份标识提交给服务器，但是你可以将你的网站配置成要求客户端进行验证，客户端也可以使用一个证书来验证自己。
在服务器上配置一个SSL证书
想要通过SSL去保护服务器和客户端之间的通信，你必须在服务器上安装证书。你有多种方法来安装证书，但是在你安装证书之前，你必须定义证书的名称或者证书所支持的名称。例如假设你想保护URL为www.adatum.com的网站，你需要颁发通用名称为www.adatum.com的证书。
注意：证书可以只根据服务器名称或者别名颁发，不需要使用完整的URL。比如通用名为www.adatum.com的证书同样可以保护URL为www.adatum.com/sales或相似的网站。
在某些时候你可能需要在同一台服务器上使用多个服务器名称的证书，最典型的案例就是Exchagne的客户端访问服务器(CAS),CAS安装的证书必须支持它的公共名称，比如mail.adatum.com和autodiscover.adatum.com，由于这两个名字都关联了同一个网站，但是一个网站只能绑定一个证书，所以你必须一个能支持多名称的证书，这个证书也被称为对象可选名称证书，该证书可以使用多个名称，Windows 2012的CA和公共CA都可以颁发这种证书。
注意：在同一个域中，我们还可以通过颁发通配符证书来替代多名称证书，比如使用*.adatum.com的通用名颁发证书，这个证书对所有域名后缀为adatum.com的名称都有效，但是考虑到安全性的原因并不推荐使用这种证书。
通过内部CA颁发一个SSL证书，可以通过以下的方式：
使用服务器上的CA控制台向CA提交一个证书申请。这种方法可以为证书指定任意的额外属性，例如证书目标或者对象可选名称，但是在安装了证书之后，你必须手动的将证书指派给适用的网站。
使用IIS控制台。在IIS控制台中，你可以直接向CA申请证书，但是这种方式申请的证书是无法选择证书模板的，它会默认使用web服务器模板，并且你不能指定对象可选名称。不过这种方法也有它的优势，它是最简单的方法用于网站上安装证书。
使用CA Web注册。这种方法适合于将证书颁发给那些未加域的服务器，使用这种注册类型，你首先需要有一个证书请求文件(.reg格式的)，然后将这个文件在CA Web注册页面中提交，这种方法可以指定证书模板以及添加对象可选名称。
如果你购买了公共信任的SSL证书，这些过程会有些不同，在你选择一个证书提供商之后，你首先要通过一个管理过程，这个管理过程用于验证你公司的身份和域名所有权，在你完成这个过程之后，你要在你的服务器上建立一个证书签约请求(CSR Certificate Signing Request),这个CSR会建立私钥和一个CSR数据文件，然后你将CSR发送给证书颁发器，CA会使用CSR数据文件创建一个公钥去匹配你的私钥，而不需要将秘钥破解。除了在配置了证书归档的时候，CA永远都不会去查看证书的私钥或者证书颁发之前的操作，但是即使配置了证书归档，秘钥也是被加密的。
数字签名中的证书使用
证书除了能够保护通信之外，还可以用于保护内容和验证内容作者的身份。当你收到一个机密内容的信息时，有两个很关键的事情我们需要确认：首先，这个信息在传递的时没有被修改；其次，作者的身份是可验证的。你可以使用证书去保护和验证内容，以及验证作者的身份，最常见的例子就是用户对文档进行数字签名。
数字签名：
当某人在应用程序中对一个文档进行数字签名时，他会确认这个文档是可靠的。可靠在这里的意思是文档的创建者是已知的，并且这个文档在创建和签名之后没有通过任何方式改动过。PKI能够实现这个级别的安全性，和我们之前说的web服务器证书相比，用户同样会有一个配对秘钥，这个证书会在数据签名的过程中使用。
当一个作者对文档或者信息进行数字签名的时候，他的计算机操作系统会创建一个信息密码摘要，这个信息密码摘要是一个128bit-256bit长度的数字，操作系统通过对整个信息执行一个哈希算法来生成这个数字，然后这个数字被作者的私钥加密后添加到文档或信息的末尾。
当文档或信息被收件者接收时，收件者的操作系统也会对文档或信息运行一次哈希算法，来生成信息密码摘要，这个哈希算法与在作者端执行的哈希算法是完全一样的。接着收件者会使用作者的公钥将已收文档中的密码摘要进行解密，然后这个解密出来的密码摘要会和收件者生成的密码摘要进行比较，如果两者是相同的，那么说明这个文档或信息在传输过程中没有被修改过。另外如果收件者能够使用作者的公钥去解密密码摘要，说明这个密码摘要是使用作者的私钥进行加密的，同时这也相当于验证了作者的身份。最后收件者还会去验证用于表明作者身份的证书，它同样是去检查证书的有效期，CRL,对象名称和证书链信任。
部署数字签名：
想要在内部通信中部署数字签名，你需要基于用户模板来颁发证书，你必须将证书颁发给所有使用数字签名的用户，如果使用自动登记去发布证书就不需要用户干涉。用户必须使用一个可以支持内容签名的应用程序，例如你可以使用word和outlook默认的数字签名。
在你颁发了证书并配置好应用程序之后，就可以使用数字签名了，但是如果你想将经过数字签名的内容发送到公司外部，你可能会遇到CA的信任问题，例如收件者和作者不在同一个AD域，所以收件者是不会信任由作者所在域的CA颁发的用于数字签名的证书的，尽管在内容保护方面这种数字签名仍然是有效的，但是收件者使用这个应用程序的时候会生成一个警告信息，无法访问受保护的内容。
如果你需要将数字签名的内容发送给公司外部的收件者，最好使用全球信任的公共CA颁发的证书。
本文出自 “乾涸的海綿” 博客，请务必保留此出处http://thefallenheaven.blog.51cto.com/450907/1590183