扫一扫关注微信
扫一扫关注微信
当你在浏览器输入一个网址 (例如 http://tasaid.com)的时候，浏览器发起一个 HTTP 请求，带着请求信息 (参见 HTTP Headers)，连接到服务器，把请求信息递给服务器，服务器收到信息之后，解析相关的信息，然后进行处理，再返回浏览器请求的数据。
简单来说是这么一个流程：
小明 跟 浏览器爸爸 说我想要去中关村某个店家拿一些东西 (发起请求)
浏览器爸爸 就把 小明 要的东西记在一张清单上 (生成HTTP协议)
然后 浏览器爸爸 派出一个 线程小弟，噌噌噌跑到中关村的店里，把清单递给 店家，说小明要这些东西 (进行传输)
店家 让 线程小弟 稍等，然后去屋子里面拿小明的这些东西 (服务器收到请求)
店家 把东西拿出来后，并且也打印了一份清单，让 线程小弟 带着清单和东西一起拿回去 (服务器处理请求完毕)
然后 线程小弟 回到 浏览器爸爸 那边，把服务器给的清单和物品交给浏览器爸爸，浏览器爸爸根据清单核对物品 (浏览器处理响应)
然后把物品打包交给了 小明 (浏览器渲染并呈现界面)
看图说话：
这其中有个问题，浏览器爸爸和服务器都没有验证清单信息的有效性和对方的身份。万一有人在中间把线程小哥拦下来，暴揍一顿，然后把物品清单给换了怎么办？或者有人把线程小哥在半路上暴揍一顿，拿了清单换了另外一个小哥怎么办？
这是个很严肃的问题：假如服务器要把一些东西锁在柜子里，需要小明给密码才可以打开柜子。然后小明把密码写在清单上让浏览器爸爸交给服务器。这时候，如果这张清单被人拦截下来，不就得到了小明的密码？
简单来说，传输的信息中包含用户密码，被拦截了怎么办？
正因为HTTP请求有这些安全性的问题，所以HTTPS诞生了，致力于解决了这些安全性问题，我们进行一下对比：
那么HTTPS是如何做到更安全的呢？
简单来说，HTTPS 即是在 HTTP 下加入了一层 SSL 加密，所以被称为HTTPS。具体的加密过程则是 公匙加密法：
客户端向服务器索要公匙，然后使用公匙加密信息
服务器收到加密后的信息，用自己的私匙解密
公匙密码和算法都是公开的，而私匙则是保密的。加密使用的公匙和解码使用的密匙都是不相同的，因此这是一个 非对称加密 算法。
提及 HTTPS ，就会听到大家说需要证书才能部署，那么什么是证书呢？
因为互联网不安全，公匙也是信息的一部分，也是会有被篡改的风险的。所以引入了互联网权威机构 - CA 机构，又称为证书授权 (Certificate Authority) 机构，浏览器会内置这些"受信任的根证书颁发机构" (即 CA)。
服务端向权威的身份鉴定 CA 机构申请数字证书，CA 机构验证了网站之后，会把网站录入到内部列表，采用 Hash 把服务端的一些相关信息生成摘要，然后 CA 机构用自己的私匙，把服务端的公匙和相关信息一起加密，然后给申请证书的服务端颁发数字证书，用于其他客户端 (比如浏览器) 认证这个网站的公匙。
客户端通过服务端下发的证书，找到对应的 CA，然后向 CA 验证这个证书是否有效，CA 验证通过之后，下发服务端的公匙。
因为 CA 是权威并且可信的，所以客户端 (浏览器) 信任 CA，而 CA 又信任经过认证的服务端 ，所以客户端 (浏览器) 也信任这个服务端，这就是信任链 (Chain Of Trust)。
而 CA 颁发的数字证书，一般包含这些信息：
简单来说：为了保证公匙是安全的，所以通过数字证书验证公匙。
一条完整的HTTPS请求应该是这样的：
客户端 (浏览器) 发起 HTTP 请求，请求连接服务端，发送支持的加密通信协议 (和版本)，并且生成一个随机数，后续用于生成"对话密钥"。
服务端确认加密通信协议 (和版本)，同时也生成一个随机数，后续用于生成"对话密匙"，并且将 CA 颁发的数字证书，一起发送给客户端。
客户端收到数字证书后，检测内置的"受信任的根证书颁发机构"，查看解开数字证书的公匙是否在。
如果解开数字证书的公匙存在，则使用它解开数字证书，得到正确的服务器公匙，同时再次生成一个随机数，用于服务器公匙加密，并发送给服务器。
此时本地和服务器同时将三个随机数，根据约定的加密方法进行加密，各自生成本次会话的所使用的同一把 "会话密匙" 。
到这里，认证阶段已经完毕，数据传输从 非对称加密 换成了 对称加密 (因为考虑到性能)，接下来所有的数据传输都是使用HTTP协议进行传输，只不过使用了 "会话密匙" 来加密内容。
见下图：
这里只介绍在 TaSaid.com 部署 HTTPS 中尝试的免费证书方案，部署在 IIS8 上。
Let's Encrypt
沃通 (wosign) (不推荐)
本来在 TaSaid.com 迁移中尝试部署过沃通 (wosign) 的签发的免费证书，但是后来发现了 Mozilla 官网( firefox/火狐 背后的开源组织 ) 里列出了 沃通的一系列可疑行为和问题，并且沃通 "秘密" 收购 StartCom（著名的免费 HTTPS 证书 StartSSL 即其旗下产品）行为可疑， Mozilla 基金会正在考虑对沃通以及 StartCom 这两个 CA 机构一年内新签发的所有 SSL 证书进行封杀。
我在上一篇文章 《从 HTTP 到 HTTPS - 什么是 HTTPS》 中指出 CA 机构应该是是权威和可信的，但由于沃通当前的陷入的一系列丑闻，信任度降低，所以暂时不推荐使用沃通。并且沃通官网已暂时关闭免费 HTTPS 证书申请。
这一段内容发表于2016年10月5日，如果您在未来某天阅览到这个内容，请即时更新了解沃通最新的动态。
所以我们这次仅推荐 Let's Encrypt。
推荐 Let's Encrypt 理由：
由 ISRG（Internet Security Research Group，互联网安全研究小组）提供服务，而 ISRG 是来自于美国加利福尼亚州的一个公益组织。Let's Encrypt 得到了 Mozilla、Cisco、Akamai、Electronic Frontier Foundation 和 Chrome 等众多公司和机构的支持，发展十分迅猛。
极速申请 - 只要认证的网站通过验证，当时即可颁发证书
免费和访问速度兼得
对于域名所有权的验证，支持两种方式：放临时文件进行验证、查询 whois 给域名所有人发邮件验证
无需注册账户
关键是稳定，背后的支持的组织很强大
缺点：
一次只能颁发3个月有效期的证书，到期之后需要自己再续上 (仍然是免费的)，这点维护起来比较麻烦，不过我们可以使用工具自动续期。
不支持通配符泛域名 (*.demo.com)，所以在申请认证是时候，要把域名都 301 跳转到证书里包含的域名上，不然浏览器会弹证书错误。
默认 Let's Encrypt 申请证书比较繁琐，所以我们在 windows 下使用工具 letsencrypt-win-simple 进行部署，简单方便快捷。
下载 letsencrypt-win-simple
在服务器中打开CMD，运行letsencrypt-win-simple
在CMD中根据简单的命令，输入要认证的网站域名和网站文件夹
letsencrypt-win-simple 自动验证域名所有权
验证通过后即时颁发证书
部署
下载最新版 letsencrypt-win-simple：
本人在2016年9月15日下到的最新版是：letsencrypt-win-simple.V1.9.1.zip。
在服务器解压 letsencrypt-win-simple.V1.9.1 得到文件夹，打开CMD进入到该文件夹下。
第一次运行命令会连接远程服务器更新，并且会让你是否输入邮箱订阅认证信息，可以忽略，然后让做个选择(忘记什么选择了)，选择Y即可，选择N则会中断。
部署单个域名
输入以下命令
letsencrypt.exe --accepttos --manualhost 你的域名 --webroot 你的网站物理路径(wwwroot路径)letsencrypt-win-simple.V1.9.1 会自动生成临时文件并放到网站根目录，然后会让 Let's Encrypt 服务器会访问这个文件, 用于验证这个网站是否属于你。
如果验证不通过，是因为 IIS 需要修改一些配置，具体参见下文的详细说明。
验证通过后会实时颁发证书，并且 letsencrypt-win-simple.V1.9.1 会自动把证书添加到服务器中，然后直接在 IIS 中进行HTTPS部署即可。
部署多个域名
输入命令 letsencrypt.exe --san
输入 M ，表示此次需要认证多个域名
输入网站的 host
输入要认证的多个域名，用 , 号分隔，比如tasaid.com,www.tasaid.com,m.tasaid.com
输入网站物理路径，比如 C:/Users/linkFly/Documents/Said/SaidTemp
letsencrypt-win-simple.V1.9.1 会自动生成临时文件并放到网站根目录，然后会让 Let's Encrypt 服务器会访问这个文件, 用于验证这个网站是否属于你。
如果验证不通过，是因为 IIS 需要修改一些配置，具体参见下文的详细说明。
验证通过后会实时颁发证书，并且会自动把证书添加到服务器中，然后直接在 IIS 中进行HTTPS部署即可。
注：相关网站建设技巧阅读请移步到建站教程频道。
建站咨询热线
135-1615-8738
