Linux CA证书与https讲解

1.什么是CA证书。

◇ 普通的介绍信

想必大伙儿都听说过介绍信的例子吧？假设 A 公司的张三先生要到 B 公司去拜访，但是 B 公司的所有人都不认识他，他咋办捏？常用的办法是带公司开的一张介绍信，在信中说：兹有张三先生前往贵公司办理业务，请给予接洽......云云。然后在信上敲上A公司的公章。

张三先生到了 B 公司后，把介绍信递给 B 公司的前台李四小姐。李小姐一看介绍信上有 A 公司的公章，而且 A 公司是经常和 B 公司有业务往来的，这位李小姐就相信张先生不是歹人了。

这里，A公司就是CA证书

◇ 引入中介机构的介绍信

好，回到刚才的话题。如果和 B 公司有业务往来的公司很多，每个公司的公章都不同，那前台就要懂得分辨各种公章，非常滴麻烦。所以，有某个中介公司 C，发现了这个商机。C公司专门开设了一项“代理公章”的业务。

今后，A 公司的业务员去 B 公司，需要带2个介绍信：

介绍信1

含有 C 公司的公章及 A 公司的公章。并且特地注明：C 公司信任 A 公司。

介绍信2

仅含有 A 公司的公章，然后写上：兹有张三先生前往贵公司办理业务，请给予接洽......云云。

某些不开窍的同学会问了，这样不是增加麻烦了吗？有啥好处捏？

主要的好处在于，对于接待公司的前台，就不需要记住各个公司的公章分别是啥样子的；他/她只要记住中介公司 C 的公章即可。当他/她拿到两份介绍信之后，先对介绍信1的 C 公章，验明正身；确认无误之后，再比对介绍信1和介绍信2的两个 A 公章是否一致。如果是一样的，那就可以证明介绍信2是可以信任的了。

◇ 什么是证书？

“证书”洋文也叫“digital certificate”或“public key certificate”（专业的解释看“这里”）。

它是用来证明某某东西确实是某某东西的东西（是不是像绕口令？）。通俗地说，证书就好比例子里面的公章。通过公章，可以证明该介绍信确实是对应的公司发出的。

理论上，人人都可以找个证书工具，自己做一个证书。那如何防止坏人自己制作证书出来骗人捏？请看后续 CA 的介绍。

◇ 什么是CA？

CA是Certificate Authority的缩写，也叫“证书授权中心”。（专业的解释看“这里”）

它是负责管理和签发证书的第三方机构，就好比例子里面的中介——C 公司。一般来说，CA必须是所有行业和所有公众都信任的、认可的。因此它必须具有足够的权威性。就好比A、B两公司都必须信任C公司，才会找 C 公司作为公章的中介。

◇ 什么是CA证书？

CA 证书，顾名思义，就是CA颁发的证书。

前面已经说了，人人都可以找工具制作证书。但是你一个小破孩制作出来的证书是没啥用处的。因为你不是权威的CA机关，你自己搞的证书不具有权威性。

这就好比上述的例子里，某个坏人自己刻了一个公章，盖到介绍信上。但是别人一看，不是受信任的中介公司的公章，就不予理睬。坏蛋的阴谋就不能得逞啦。

文本后续提及的证书，若无特殊说明，均指 CA 证书。

2.证书的签发过程：

• a.服务方 S 向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证；

• b.CA 通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等；

• c.如信息审核通过，CA 会向申请者签发认证文件-证书。

证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明文，同时包含一个签名；

签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA 的私钥对信息摘要进行加密，密文即签名；

• d.客户端 C 向服务器 S 发出请求时，S 返回证书文件；

• e.客户端 C 读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应 CA 的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即公钥合法；

• f.客户端然后验证证书相关的域名信息、有效时间等信息；

• g.客户端会内置信任 CA 的证书信息(包含公钥)，如果CA不被信任，则找不到对应 CA 的证书，证书也会被判定非法。

在这个过程注意几点：

1.申请证书不需要提供私钥，确保私钥永远只能服务器掌握；

2.证书的合法性仍然依赖于非对称加密算法，证书主要是增加了服务器信息以及签名；

3.内置 CA 对应的证书称为根证书，颁发者和使用者相同，自己为自己签名，即自签名证书；

4.证书=公钥+申请者与颁发者信息+签名；

http通信存在的问题

• 容易被监听

  • http通信都是明文，数据在客户端与服务器通信过程中，任何一点都可能被劫持。比如，发送了银行卡号和密码，hacker劫取到数据，就能看到卡号和密码，这是很危险的

• 被伪装

  • http通信时，无法保证通行双方是合法的，通信方可能是伪装的。比如你请求www.taobao.com,你怎么知道返回的数据就是来自淘宝，中间人可能返回数据伪装成淘宝。

• 被篡改

  • hacker中间篡改数据后，接收方并不知道数据已经被更改

共享密钥加密和公开密钥加密

后续内容的需要，这里插播一段共享密钥加密和公开密钥加密

• 共享密钥加密

  • 共享密钥的加密密钥和解密密钥是相同的，所以又称为对称密钥

• 公开密钥加密

  • 加密算法是公开的，密钥是保密的。公开密钥分为私有密钥和公有密钥，公有密钥是公开的，任何人(客户端)都可以获取，客户端使用公有密钥加密数据，服务端用私有密钥解密数据。

• 异同

  • 共享密钥加密与公开密钥加密相比，加解密处理速度快，但公开密钥更适应互联网下使用

https解决的问题

https很好的解决了http的三个缺点（被监听、被篡改、被伪装），https不是一种新的协议，它是http+SSL(TLS)的结合体，SSL是一种独立协议，所以其它协议比如smtp等也可以跟ssl结合。https改变了通信方式，它由以前的http—–>tcp，改为http——>SSL—–>tcp；https采用了共享密钥加密+公开密钥加密的方式

• 防监听

  • 数据是加密的，所以监听得到的数据是密文，hacker看不懂。

• 防伪装

  • 伪装分为客户端伪装和服务器伪装，通信双方携带证书，证书相当于身份证，有证书就认为合法，没有证书就认为非法，证书由第三方颁布，很难伪造

• 防篡改

  • https对数据做了摘要，篡改数据会被感知到。hacker即使从中改了数据也白搭。

https连接过程

• 客户端发送请求到服务器端

• 服务器端返回证书和公开密钥，公开密钥作为证书的一部分而存在

• 客户端验证证书和公开密钥的有效性，如果有效，则生成共享密钥并使用公开密钥加密发送到服务器端

• 服务器端使用私有密钥解密数据，并使用收到的共享密钥加密数据，发送到客户端

• 客户端使用共享密钥解密数据

• SSL加密建立………

客户端认证的通信的过程

• 客户端需要认证的过程跟服务器端需要认证的过程基本相同，并且少了最开始的两步。这种情况都是证书存储在客户端，并且应用场景比较少，一般金融才使用，比如支付宝、银行客户端都需要安装证书

后续的问题

• 怎样保证公开密钥的有效性

  • 你也许会想到，怎么保证客户端收到的公开密钥是合法的，不是伪造的，证书很好的完成了这个任务。证书由权威的第三方机构颁发，并且对公开密钥做了签名。

• https的缺点

  • https保证了通信的安全，但带来了加密解密消耗计算机cpu资源的问题 ，不过，有专门的https加解密硬件服务器

• 各大互联网公司，百度、淘宝、支付宝、知乎都使用https协议，为什么？

  • 支付宝涉及到金融，所以出于安全考虑采用https这个，可以理解，为什么百度、知乎等也采用这种方式？为了防止运营商劫持！http通信时，运营商在数据中插入各种广告，用户看到后，怒火发到互联网公司，其实这些坏事都是运营商(移动、联通、电信)干的,用了https，运营商就没法插播广告篡改数据了。

4.比较完整的过程：

1. 客户端发起HTTPS请求

这个没什么好说的，就是用户在浏览器里输入一个https网址，然后连接到server的443端口。

2. 服务端的配置

采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。这套证书其实就是一对公钥和私钥。如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。

3. 传送证书

这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。

4. 客户端解析证书

这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随机值。然后用证书对该随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。

5. 传送加密信息

这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

6. 服务段解密信息

服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。

7. 传输加密后的信息

这部分信息是服务段用私钥加密后的信息，可以在客户端被还原。

8. 客户端解密信息

客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。

5.总结整个过程：

1.服务器向CA机构获取证书（假设这个证书伪造不了），当浏览器首次请求服务器的时候，服务器返回证书给浏览器。（证书包含：公钥+申请者与颁发者的相关信息+签名）

2.浏览器得到证书后，开始验证证书的相关信息，证书有效（没过期等）。（验证过程，比较复杂，详见上文）。

3.验证完证书后，如果证书有效，客户端是生成一个随机数，然后用证书中的公钥进行加密，加密后，发送给服务器，服务器用私钥进行解密，得到随机数。之后双方便开始用该随机数作为钥匙，对要传递的数据进行加密、解密。

关于https：http://blog.csdn.net/wangjun5159/article/details/51510594

引用参考博客：http://kb.cnblogs.com/page/194742/

关于https的误解：http://www.admin5.com/article/20150523/600106.shtml

6.https 正式测试

准备cfssl环境

mkdir /root/ssl_test

wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -O /root/ssl_test/cfssl

wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -O /root/ssl_test/cfssljson

wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -O /root/ssl_test/cfssl-certinfo chmod +x /root/ssl_test/cfssl*

生成ca证书

• 准备配置文件

  cd /root/ssl_test;mkdir keys;cd keys

  cat > ca-config.json <<EOF

  {

    "signing": {

      "default": {

        "expiry": "8760h"

      },

      "profiles": {

        "app": {

          "usages": [

              "signing",

              "key encipherment",

              "server auth",

              "client auth"

          ],

          "expiry": "8760h"

        }

      }

    }

  }

  EOF

   

  cat > ca-csr.json <<EOF

  {

    "CN": "k8s",

    "key": {

      "algo": "rsa",

      "size": 2048

    },

    "names": [

      {

        "C": "CN",

        "ST": "BeiJing",

        "L": "BeiJing",

        "O": "k8s",

        "OU": "System"

      }

    ]

  }

  EOF

• 执行命令生成ca文件

  ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca

生成server证书

cat > app-csr.json <<EOF

{

  "CN": "*.ma.com",

  "hosts": [

    "*.ma.com"

  ],

  "key": {

    "algo": "rsa",

    "size": 2048

  },

  "names": [

    {

      "C": "CN",

      "ST": "BeiJing",

      "L": "BeiJing",

      "O": "k8s",

      "OU": "System"

    }

  ]

}

 

../cfssl gencert -ca=./ca.pem \

  -ca-key=./ca-key.pem \

  -config=./ca-config.json \

  -profile=app app-csr.json | ../cfssljson -bare app

 

# openssl x509  -noout -text -in  app.pem

进行验证

• 导入证书

  ca.pem改名为ca.crt。将正式导入浏览器。

• 构建https服务

  cd /root/ssl_test

  cat > http-server.js <<EOF

  var https = require('https');

  var fs = require('fs');

   

  var options = {

      key: fs.readFileSync('./keys/app-key.pem'),

      cert: fs.readFileSync('./keys/app.pem')

  };

   

  https.createServer(options, function (req, res) {

      res.writeHead(200);

      res.end('hello world');

  }).listen(8000);

  EOF

   

  yum install nodejs -y

  npm install https -g

  node http-server.js

• 修改hosts文件添加

  192.168.0.158 *.ma.com
  

  在浏览器访问https://www.ma.com:8000 发现网站显示为安全

7. 证书各个字段的含义

openssl x509  -noout -text -in  app.pem

Certificate:

    Data:

        Version: 3 (0x2)

        Serial Number:

            58:af:a5:d6:10:10:e1:99:8c:e9:92:29:ef:57:2f:e0:00:a4:12:5c

    Signature Algorithm: sha256WithRSAEncryption

        Issuer: C=CN, ST=BeiJing, L=BeiJing, O=k8s, OU=System, CN=k8s

        Validity

            Not Before: Sep 11 06:02:00 2018 GMT

            Not After : Sep 11 06:02:00 2019 GMT

        Subject: C=CN, ST=BeiJing, L=BeiJing, O=k8s, OU=System, CN=*.ma.com

        Subject Public Key Info:

            Public Key Algorithm: rsaEncryption

                Public-Key: (2048 bit)

                Modulus:

                    00:ca:23:ef:e1:54:f8:e9:ae:6a:8e:53:db:79:ab:

                    fc:48:9f:6b:d7:f8:25:a4:ed:8c:06:60:bc:a3:8e:

                    7c:42:5f:ac:d7:23:ba:e1:41:0e:8a:20:26:c9:42:

                    59:d5:a2:4d:e8:c6:5a:9c:7f:8b:bc:d0:b2:14:a5:

                    da:19:d4:a3:be:7e:53:9c:f4:23:2d:5b:00:69:51:

                    cf:ec:53:eb:7e:a7:5c:ce:e2:6d:61:ea:42:e4:54:

                    5f:19:f0:6a:b8:27:e1:69:83:d9:65:90:df:f9:65:

                    73:7d:12:83:c2:6d:50:f9:0a:e8:3a:e5:3b:bd:b1:

                    32:7b:a5:23:a7:fd:77:c1:cc:b6:d6:ab:71:3e:ef:

                    83:33:e4:67:e0:76:f8:0e:58:89:6e:d5:fb:ad:d2:

                    9e:18:ff:1d:a5:bc:af:73:8d:b8:11:af:8b:63:b0:

                    75:3d:f9:12:c3:9f:55:9e:c5:fe:cd:29:ce:e9:05:

                    c4:6b:34:4b:6c:81:9b:d0:b7:62:d6:29:d7:50:a5:

                    61:b1:5f:2e:c0:89:21:0f:70:bc:de:60:ff:65:c3:

                    0f:62:b6:9c:b8:b2:b4:af:a2:cc:a0:30:5c:b1:59:

                    7d:eb:bb:a9:8d:b1:d0:e7:93:2d:85:65:cf:75:e9:

                    d6:d9:cd:03:ae:b6:ad:9b:c8:f7:29:16:ef:66:32:

                    9c:1b

                Exponent: 65537 (0x10001)

        X509v3 extensions:

            X509v3 Key Usage: critical

                Digital Signature, Key Encipherment

            X509v3 Extended Key Usage:

                TLS Web Server Authentication, TLS Web Client Authentication

            X509v3 Basic Constraints: critical

                CA:FALSE

            X509v3 Subject Key Identifier:

                E1:3A:88:BD:83:B6:32:BF:8F:59:49:90:39:AA:6B:B8:0A:FA:24:61

            X509v3 Authority Key Identifier:

                keyid:5A:39:96:24:77:5E:23:FC:EF:85:CA:C9:6A:06:FC:73:EB:56:0A:CE

 

            X509v3 Subject Alternative Name:

                DNS:*.ma.com

    Signature Algorithm: sha256WithRSAEncryption

         32:89:a7:f1:e6:8a:b8:0f:0f:4d:26:d0:a0:f7:b3:ec:79:ca:

         b3:9d:2d:ec:40:87:4c:d9:68:82:cf:1d:fa:60:9c:5b:19:07:

         be:9d:85:05:2c:db:0a:b8:eb:3d:05:79:6e:5b:b9:ea:07:cf:

         ac:ec:14:c6:f5:90:0d:73:c7:66:c3:f8:f8:f6:18:6c:c6:c6:

         e9:0c:7d:6a:5f:af:9c:dd:26:68:3c:e5:fb:4b:70:c0:e7:b5:

         11:65:18:31:fb:6f:69:1f:8c:b0:1e:dc:f4:14:1c:5d:45:02:

         fa:08:1a:1c:f8:5c:7e:a9:72:19:c1:93:c2:51:30:a9:e5:f7:

         54:5e:62:fe:01:8c:49:3a:80:4c:0c:87:82:de:31:ab:3d:5b:

         a1:6b:5a:13:0a:a2:41:d4:1b:bd:ff:2c:8d:7c:cc:e4:34:29:

         3c:0a:89:a0:ef:54:95:22:2f:2e:b8:72:2d:56:20:65:7b:b2:

         c4:5c:3e:16:00:cb:f3:ec:1f:5a:03:64:02:e7:32:c2:44:7d:

         4c:73:bc:6b:9f:c4:40:00:c7:67:27:be:66:8a:f6:5b:39:2c:

         4b:b3:a5:b0:69:fa:a0:94:36:c5:9f:56:0f:66:28:9e:b4:35:

         54:47:3c:44:d7:e1:6f:47:59:56:82:4c:a2:cc:10:88:b7:5f:

         8a:7d:50:fc

数字证书中主题(Subject)中字段的含义

• 一般的数字证书产品的主题通常含有如下字段：

字段名	字段值
公用名称 (Common Name)	简称：CN 字段，对于 SSL 证书，一般为网站域名；而对于代码签名证书则为申请单位名称；而对于客户端证书则为证书申请者的姓名；
单位名称 (Organization Name)	简称：O 字段，对于 SSL 证书，一般为网站域名；而对于代码签名证书则为申请单位名称；而对于客户端单位证书则为证书申请者所在单位名称；

• 证书申请单位所在地

字段名	字段值
所在城市 (Locality)	简称：L 字段
所在省份 (State/Provice)	简称：S 字段
所在国家 (Country)	简称：C 字段，只能是国家字母缩写，如中国：CN

• 其他一些字段

字段名	字段值
电子邮件 (Email)	简称：E 字段
多个姓名字段	简称：G 字段
介绍	Description 字段
电话号码：	Phone 字段，格式要求 + 国家区号 城市区号 电话号码，如： +86 732 88888888
地址：	STREET 字段
邮政编码:	PostalCode 字段
显示其他内容	简称:OU 字段

8.单向认证双向认证

何为SSL/TLS单向认证，双向认证？
单向认证指的是只有一个对象校验对端的证书合法性。
通常都是client来校验服务器的合法性。那么client需要一个ca.crt,服务器需要server.crt,server.key
双向认证指的是相互校验，服务器需要校验每个client,client也需要校验服务器。
server 需要 server.key 、server.crt 、ca.crt
client 需要 client.key 、client.crt 、ca.crt