SSL/TLS是一个密码学协议，它的目标并不仅仅是网页内容的加密传输。SSL/TLS的主要目标有四个：加密安全、互操作性、可扩展性和效率。对于安全性的保障，它还会从多个方面进行，包括机密性，真实性以及完整性。机密性是指，传输的内容不被除通信的双方外的第三方获取；真实性是指，通信的对端正是期待的对端，而不是其它第三方冒充的；完整性则是指，传输的数据是完整的，数据没有被篡改或丢失。为了平衡多种需求，SSL/TLS被设计为一个安全框架，其中可以应用多种不同的安全方案，每种方案都由多个复杂的密码学过程组成。不同的安全方案，在安全性和效率之间有着不同的取舍，并由不同的密码学过程组成。
在密码学上，非对称加密具有更高的安全性，同时计算复杂度更高，性能更差；而对称加密，则效率比较高，计算复杂度较低，但如果在通信过程中明文传输密钥，或将密钥以hard code的形式写在代码里，则安全隐患比较大。
从密码学过程的特性出发，整体来看，SSL/TLS连接是在会话协商阶段，通过 非对称加密 算法，如RSA、ECDHE等，完成身份验证，及后续用到的对称加密密钥的交换；在整个数据传输阶段，通过对称加密算法，如AES、3DES等，对传输的数据进行加密；通过数据散列算法，如SHA1、SHA256等，计算数据的散列值并随应用数据一起发送，以保证数据的完整性。
本文主要描述非对称加密的基本思想，及TLS的证书身份认证。
非对称加密
非对称加密 (asymmetric encryption) 又称为公钥加密 (public key cryptography)，是使用两个密钥，而不像对称加密那样使用一个密钥的加密方法；其中一个密钥是私密的，另一个是公开的。顾名思义，一个密钥用于非公开的私人的，另一个密钥将会被所有人共享。
非对称加密的两个密钥之间存在一些特殊的数学关系，使得密钥具备一些有用的特性。如果利用某人的公钥加密数据，那么只有他们对应的私钥能够解密。从另一方面讲，如果某人用私钥加密数据，任何人都可以利用对应的公钥解开消息。 后面这种操作不提供机密性，但可以用作数字签名。
非对称加密保护数据安全
盗用阮一峰老师的几幅图来说明，通过非对称加密保护数据安全的过程。
- 鲍勃有两把钥匙，一把是公钥，另一把是私钥。
- 鲍勃把公钥送给他的朋友们—-帕蒂、道格、苏珊—-每人一把。
- 苏珊要给鲍勃写一封不希望别人看到的保密的信。她写完后用鲍勃的公钥加密，就可以达到保密的效果。
- 鲍勃收到信后，用私钥解密，就可以看到信件内容。
对于非对称加密，只要私钥不泄露，传输的数据就是安全的。即使数据被别人获取，也无法解密。
非对称加密的这些特性直击对称加密中只用一个密钥，而该密钥不方便传输、保存的痛点。它大大方便了大规模团体的安全通信，方便了安全通信在互联网中的应用。
非对称加密生成数字签名
数据的加密安全只是数据安全的一个方面，数据的真实性同样非常重要。经常可以看到这样的案例，骗子在同学参加四、六级考试的时候，给同学的家长打电话或发短信，声称自己是学校的辅导员，并表示同学病重急需用钱，要求家长汇钱，同学家长汇钱给骗子而遭受巨大损失的情况。这就是数据/信息真实性没有得到足够验证而产生的问题。
再比如，一个仿冒的taobao网站，域名与真实的网站非常相似。我们一不小心输错了域名，或域名被劫持而访问了这个仿冒的网站，然后像平常在taobao购物一样，选择宝贝，并付款，但最后却怎么也收不到货物。
现实世界中，常常会请消息的发送者在消息后面签上自己的名字，或者印章来证明消息的真实可靠性，如信件中的签名，合同中的印章等等。类似地，在虚拟的网络世界中，也会通过数字签名来确认数据的真实可靠性。数字签名依赖的主要算法也是非对称加密，生成数字签名主要是使用私钥加密 数据的散列摘要 来签名。
通过几幅图来说明这个过程。
- 鲍勃给苏珊回信，决定采用”数字签名”来证明自己的身份，表示自己对信件的内容负责。他写完后先用散列函数，生成信件的摘要（digest）。
- 然后，鲍勃使用自己的私钥，对这个摘要加密，生成”数字签名”（signature）。
- 鲍勃将这个签名，附在信件下面，一起发给苏珊。
- 苏珊收到信后，取下数字签名，用鲍勃的公钥解密，得到信件的摘要。
- 苏珊再对信件本身应用散列函数，将得到的结果，与上一步得到的摘要进行对比。如果两者一致，则证明这封信确实是鲍勃发出的，信件完整且未被篡改过。
如果鲍勃向苏珊借了钱，并用上面这样的过程写信给苏珊确认自己收到了钱，那么鲍勃就再也不能抵赖了——信件的末尾可是清清楚楚地签着鲍勃的大名呢。
如果我们的网络世界能像上图的过程那样，每个人都可以方便地获得可靠的公钥，那就太美好了。互联网上的网站成千上万，每个人都走到自己要访问的网站站长的办公室把网站的公钥拷走，或者网站站长挨个走到自己的目标用户家门口，把自己网站的公钥交给用户，那可就太麻烦，代价太大了。
公钥通常都是通过网络传输的。不怀好意的人，会试图干扰这个传输过程，将自己伪造的公钥发送给用户，进而破坏后续整个数据传输的安全性。如果用户拿到的是伪造的公钥，那签名也就形同虚设。
如道格想欺骗苏珊，他在鲍勃将公钥交给苏珊时拦住鲍勃，表示要替鲍勃转交。正好鲍勃有老板交待的其它重要事情要完成，于是就把自己的公钥交给道格请他帮忙转交。但道格把鲍勃的公钥丢进垃圾桶，而把自己的公钥交给了苏珊。此时，苏珊实际拥有的是道格的公钥，但还以为这是鲍勃的。因此，道格就可以冒充鲍勃，用自己的私钥做成”数字签名”，写信给苏珊，让苏珊用假的鲍勃公钥进行解密。
证书
证书正是为了解决公钥的信任问题而引入。证书体系通过引入可信的第三机构，称为 证书签发机构（certificate authority，简称CA），为公钥做认证，来确保公钥的真实可靠。证书是经过了 CA 私钥签名的 证书持有者的公钥、身份信息及其它相关信息 的文件，用户通过 CA 的公钥解密获取证书中包含的 证书持有者 的公钥。只要 CA 的私钥保持机密，通过证书验证 证书持有者 的身份，及获取公钥的过程就可靠。
证书的工作过程
互联网PKI证书体系的结构如下图：
证书订阅人 ，也就是需要提供安全服务的人，向 证书中心 (CA) 的代理—— 登记机构 提交自己的公钥来申请证书。 登记机构 对 证书订阅人 的身份进行核实，然后向 证书中心 (CA) 提交 证书订阅人 的公钥及身份信息。 证书中心 (CA) 用自己的私钥，对 证书订阅人 的公钥、身份信息和其它一些相关信息进行加密，生成 “数字证书”（Digital Certificate） ，并发送给 登记机构。 登记机构 将证书发送给 证书订阅人 。 证书订阅人 将证书部署在Web服务器上。 信赖方，即安全服务的用户，维护 CA 根证书库，并在与Web服务器通信时，从服务器获得证书。 信赖方 用CA根证书验证接收到的证书的有效性，进而验证服务器的真实性。
同样通过几幅图来说明这个过程。
- 鲍勃去找证书签发机构，为公钥做认证。证书中心用自己的私钥，对鲍勃的公钥、身份信息和一些其它相关信息一起加密，生成”数字证书”（Digital Certificate）。
- 鲍勃拿到数字证书以后，就可以放心，以后再也没人能冒充自己了。再需要发送自己的公钥给朋友们时，只要把自己事先拿到的 数字证书 发送给朋友就可以了。需要写信给苏珊时，照常附上自己的数字签名即可。
- 苏珊收到信后，用CA的公钥解开数字证书，就可以拿到鲍勃真实的公钥，然后就能证明”数字签名”是否真的是鲍勃签的。
证书里有什么
PKI证书是 抽象语法表示一 (Abstract syntax notation one, ASN.1) 表示， 基本编码规则 (base encoding rules, BER) 的一个子集 唯一编码规则 (distinguished encoding rules, DER) 编码的二进制文件。我们通常看到的证书则是DER使用Base64编码后的ASCII编码格式，即 PEM (Privacy-enhanced mail) 这种更容易发送、复制和粘贴的编码格式的纯文本文件。
证书里到底都有些什么呢？这里我们通过一个实际的证书来看一下。我们可以通过openssl解码数字证书，获得证书的可读形式：
可以看到主要包含证书格式的版本号；证书的唯一的序列号；签名算法；颁发者的信息；证书的有效期；证书的使用者的信息、身份信息，在这里主要是几个域名；证书使用者的公钥等等。
Let’s Encrypt证书申请
我们通过一个 Let’s Encrypt 证书申请过程对证书做更多了解。 Let’s Encrypt 是一个免费、自动化、开放的证书签发机构，目前它已得到了Mozilla，Chrome等的支持，发展十分迅猛。
证书申请
Let’s Encrypt 使用ACME协议验证申请人对域名的控制并签发证书。要获取Let’s Encrypt 证书，需使用ACME客户端进行。Let’s Encrypt 官方推荐 使用Certbot这个功能强大，灵活方便的工具，不过也可以使用其它的ACME客户端。
这里我们通过Certbot申请Let’s Encrypt证书。
Certbot安装
对于在Ubuntu 14.04平台上部署nginx提供Web服务的情况，应该使用 certbot-auto 来安装：
certbot-auto 接收与 certbot 完全相同的标记；不带参数执行这个命令时，会自动安装依赖的所有东西，并更新工具本身。执行如下命令：
配置Web服务器
Let’s Encrypt 在签发证书之前，需要先通过ACME验证申请者对域名的控制权。验证方法是，ACME客户端产生一些临时文件放在指定的位置，并将该文件的相关信息发送给 Let’s Encrypt 。 Let’s Encrypt通过http协议访问域名下的对应文件，验证申请者对域名的控制权。因而申请证书前需要先配置Web服务器。
对于nginx服务器而言，可以这样配置：
申请证书
Certbot 功能非常强大，它支持许多的插件，为许多平台上的Web服务器自动地申请、安装及部署证书。对于nginx，目前还不支持证书的自动安装和部署，这里使用 certonly 命令单独地获取证书。
执行如下命令：
主要的参数说明：
--rsa-key-size：指定RSA密钥，即非对称加密私钥的强度，这里指定为4096位。这个参数用于生成RSA的私钥。--webroot：webroot是一个插件，可以与网站的根目录路径一起工作。-w：用于指定网站根目录路径。ACME客户端产生的临时文件都将放在这个参数指定的目录下。这个参数的值要与配置的Web服务器的网站根目录路径匹配。-d：用于指定要认证的域名。可以用一个证书为多个域名签名。
Certbot 自动地完成证书的申请过程。
证书申请成功之后可以看到如下的提示：
更多关于使用 Certbot 申请 Let’s Encrypt 证书的信息，可以参考 Certbot 官网。
从上面的图可以看到证书申请的大体过程：
申请得到的证书及相关文件被放在/etc/letsencrypt/目录下：
/etc/letsencrypt/archive/[域名]下保存与特定域名相关的文件，包括网站证书、中间证书链、完整证书链和私钥。如果多次为相同的域名申请证书，这个目录下将有多份证书相关文件，文件名后加数字以区分。/etc/letsencrypt/csr下是申请证书的证书签名请求(CSR)文件。如果多次申请了证书，这个目录下会保存所有申请的文件。/etc/letsencrypt/live/[域名]下是最近一次为特定域名申请证书的相关文件，同样是网站证书、中间证书链、完整证书链和私钥。/etc/letsencrypt/renewal/[域名].conf文件则保存证书申请的配置信息，以方便下次以相同配置为同样的域名更新证书。
可以看一下证书申请的配置文件内容来对证书申请过程做更多的了解：
CSR文件的内容
证书主要是为网站的公钥签名的，但前面申请证书的过程却并没有看到网站公钥的生成。这是因为公钥是在产生CSR文件的过程中自动生成并保存在CSR文件中的。
使用openssl解析前面我们申请Let’s Encrypt 证书时产生的CSR文件：
可以看到CSR文件包含了加密算法的信息(RSA)，公钥，公钥的大小(4096位)，签名算法 (sha256WithRSAEncryption)，域名等信息。
上面的CSR文件实际通过类似下面的命令生成：
也可以借助于openssl，通过私钥单独生成公钥：
证书的选择
证书体系的安全性非常依赖CA的私钥的强度，以及CA的私钥的保密性。如果有财大气粗者，建造了计算能力超强的计算机，计算出了CA的私钥；或者CA的安全系统遭受了攻击，结果私钥被盗；又或者CA内部有图谋不轨者盗走了CA的私钥，则拿到私钥的人就可以随意为各网站的仿冒者签发可以通过安全验证的证书了。
不同CA在维护安全方面的实力的差异而造成了不同证书间安全性的差异。提供安全服务的人，可以根据自己对安全性的需求，选择适当的证书。购买收费的证书似乎主要是投资给CA，以促使其加强自身安全体系的建设，防止私钥出现安全性问题。
当前市场占有率排名前10的CA大概占有90%以上的市场份额。商业的CA主要有如下的这些：
Digicert – SSL Digital Certificate Authority
Comodo – SSL Certificate Authority
此外，还有一些非营利性质的CA，主要有如下这些：
参考文档：
What is a CSR (Certificate Signing Request)?
The Most Common OpenSSL Commands
Description of Symmetric and Asymmetric Encryption
How to choose the right Certificate Authority for your Web site
10 World Popular Cheap SSL Certificate Providers
