非对称加密与证书（上篇）

阅读量：4984 次

发布时间：2019-06-12

本文共 8082 字，大约阅读时间需要 26 分钟。

本文来自。

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解码数字证书，获得证书的可读形式：

$ openssl x509 -in chained.pem -text -nooutCertificate:    Data:        Version: 3 (0x2)        Serial Number:            03:5c:25:82:1d:c2:b2:2f:6f:73:39:48:9c:68:07:1b:48:2d    Signature Algorithm: sha256WithRSAEncryption        Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3        Validity            Not Before: Oct 25 01:12:00 2016 GMT            Not After : Jan 23 01:12:00 2017 GMT        Subject: CN=www.wolfcstech.com        Subject Public Key Info:            Public Key Algorithm: rsaEncryption                Public-Key: (4096 bit)

Modulus:00:c3:92:70:78:ff:00:0a:22:c7:14:0b:3d:b3:26:34:cb:37:63:26:1d:d6:42:7b:5c:ab:51:cc:f7:12:57:26:b1:d1:4f:5f:a7:02:5b:3c:f3:e6:e1:ec:7c:66:61:ba:d8:5e:d6:61:60:48:d6:d3:4c:23:9a:50:75:4b:2d:1b:89:7d:7b:55:2f:12:63:b4:ac:c7:b5:d1:44:95:ed:a2:f4:9d:ee:77:3c:2b:06:48:d9:18:21:d1:ee:cf:5c:26:ad:c2:11:28:9c:27:65:11:94:c4:1d:0f:5e:4c:4f:00:71:cf:5d:1f:40:4b:9a:5e:3b:b0:42:45:c5:68:01:62:29:c2:92:b5:ad:8d:13:11:db:7e:02:65:14:6a:5d:4b:66:16:08:d4:ab:90:dc:06:28:27:cd:84:c0:b7:30:22:ff:54:71:c2:3b:8d:7d:8b:52:c3:a8:f1:ee:63:42:2a:dd:4d:a7:70:66:c5:c3:54:d5:8e:a1:e2:02:d0:8b:2f:f6:44:1d:f5:f2:85:fd:49:c7:e0:d7:d0:ae:21:b7:25:ae:7c:15:dc:56:51:45:f1:e7:19:d6:1c:95:2c:65:f7:34:2c:67:1c:93:00:81:a7:e2:23:da:1a:3c:d1:9f:84:5e:01:3f:71:e7:9c:cd:e0:4f:fc:db:a6:2f:33:3a:3d:ce:6d:52:72:47:0b:08:9c:04:1f:4a:cd:cd:71:db:c2:3f:0d:9c:b4:24:ca:25:06:49:2b:40:a7:96:b6:60:b7:8d:c7:b0:b4:84:96:06:63:3b:d9:0c:25:8d:af:ad:90:ce:b8:d5:c6:e6:28:28:bd:4b:72:92:28:1a:0a:b7:15:3c:28:26:15:ab:fc:88:22:74:50:77:cc:3d:a3:c8:be:83:14:3d:ca:0e:79:aa:71:66:56:b8:6f:fe:2a:2d:36:ff:0c:af:b9:61:5c:5b:5f:a4:cc:0a:5b:13:31:c9:16:3f:51:9c:19:56:dd:06:1d:c9:6f:f6:17:61:61:7b:4c:cb:aa:b9:92:52:25:9b:8f:02:2d:51:39:5f:f0:89:e2:e8:25:6f:04:2a:d3:6f:a3:3e:a7:44:a8:a1:db:01:55:ad:1d:3f:72:3a:9a:b7:0f:35:a3:de:d2:93:d7:7c:d6:12:66:b2:f9:da:c4:e3:e6:52:6f:55:07:5c:a2:57:0d:7a:ca:20:5a:59:1b:78:ba:cf:e2:1d:b3:33:0a:53:2e:26:9f:39:2f:ec:48:8b:9f:a0:b9:e8:e6:61:9b:89:34:59:02:07:bb:b4:c4:8d:1d:24:72:ea:1e:7c:5f:a9:a3:96:15:e9:4d:7e:4c:94:eb:cb:af:d2:70:83:78:be:36:eb

Exponent: 65537 (0x10001)X509v3 extensions:X509v3 Key Usage: criticalDigital Signature, Key EnciphermentX509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client AuthenticationX509v3 Basic Constraints: criticalCA:FALSEX509v3 Subject Key Identifier: B8:27:0E:D4:47:BB:27:66:51:3B:E7:F9:8B:9C:48:2E:3D:FD:C8:97X509v3 Authority Key Identifier: keyid:A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1Authority Information Access: OCSP - URI:http://ocsp.int-x3.letsencrypt.org/CA Issuers - URI:http://cert.int-x3.letsencrypt.org/X509v3 Subject Alternative Name: DNS:wolfcstech.cn, DNS:wolfcstech.com, DNS:www.wolfcstech.cn, DNS:www.wolfcstech.comX509v3 Certificate Policies: Policy: 2.23.140.1.2.1Policy: 1.3.6.1.4.1.44947.1.1.1CPS: http://cps.letsencrypt.orgUser Notice:Explicit Text: This Certificate may only be relied upon by Relying Parties and only in accordance with the Certificate Policy found at https://letsencrypt.org/repository/

Signature Algorithm: sha256WithRSAEncryption46:a1:fb:1c:fe:6e:ef:af:fc:84:e3:7e:20:1d:c8:0c:0b:e4:d2:4b:9e:f6:bc:e5:31:59:08:bb:7e:0d:74:3f:e6:de:39:58:e2:f4:fa:bf:5c:26:86:96:19:8f:00:13:17:2b:4f:95:c4:bd:02:ad:cd:a6:e5:80:21:f5:ee:e6:4d:01:86:07:82:37:5e:39:c9:55:40:ed:08:2e:8d:94:b8:86:2f:15:76:10:bd:97:46:06:b3:34:80:12:f4:dc:2a:2a:63:80:36:fe:ef:e1:9e:b6:dc:22:51:c7:54:46:1a:b2:c5:e8:62:98:90:46:ea:92:8c:fd:d4:dd:00:4f:fb:1e:25:24:93:c1:74:15:07:6f:67:d3:be:5b:47:7e:18:56:02:01:55:09:fc:bf:7f:ff:27:fc:db:d8:53:55:02:43:2e:a0:23:28:01:4d:4d:f9:bc:02:bc:fe:50:c2:67:d7:d4:48:23:c2:0b:25:d4:65:e1:8f:3c:75:12:b6:87:b1:17:86:c8:1a:26:72:0e:ba:07:92:c4:87:3e:e1:fc:e3:58:ef:a2:23:43:09:85:c4:82:00:04:07:49:06:10:bc:fd:20:67:0f:63:f8:ff:bf:7f:6f:da:72:77:51:1d:50:34:07:63:e8:68:e3:ef:70:5f:71:b4:11:9e:27

可以看到主要包含证书格式的版本号；证书的唯一的序列号；签名算法；颁发者的信息；证书的有效期；证书的使用者的信息、身份信息，在这里主要是几个域名；证书使用者的公钥等等。

Let's Encrypt证书申请

我们通过一个 Let's Encrypt 证书申请过程对证书做更多了解。是一个免费、自动化、开放的证书签发机构，目前它已得到了Mozilla，Chrome等的支持，发展十分迅猛。

证书申请

Let’s Encrypt 使用ACME协议验证申请人对域名的控制并签发证书。要获取Let’s Encrypt 证书，需使用ACME客户端进行。Let’s Encrypt 使用Certbot这个功能强大，灵活方便的工具，不过也可以使用。

这里我们通过Certbot申请Let’s Encrypt证书。

Certbot安装

对于在Ubuntu 14.04平台上部署nginx提供Web服务的情况，应该使用 certbot-auto 来安装：

$ wget https://dl.eff.org/certbot-auto$ chmod a+x certbot-auto

certbot-auto 接收与 certbot 完全相同的标记；不带参数执行这个命令时，会自动安装依赖的所有东西，并更新工具本身。执行如下命令：

$ ./certbot-auto