V2AS问路
数字证书与身份验证之HTTPS证书生成
阅读原文时间：2021年04月21日阅读：1

数字证书与身份验证之HTTPS证书生成

简单快捷的生成个人的https证书

前期准备之工具

软件：需要安装nodejs，openssl，ie

环境：win10，nodejs和openssl需要位于系统环境变量中

简介

HTTPS：

HTTPS 区别于 HTTP，它多了加密(encryption)，认证(verification)，鉴定(identification)。它的安全源自非对称加密以及第三方的 CA 认证。

运行过程：

  • 客户端生成一个随机数 random-client，传到服务器端（Say Hello)
  • 服务器端生成一个随机数 random-server，和着公钥，一起回馈给客户端（I got it)
  • 客户端收到的东西原封不动，加上 premaster secret（通过 random-client、random-server 经过一定算法生成的东西），再一次送给服务器端，这次传过去的东西会使用公钥加密
  • 服务器端先使用私钥解密，拿到 premaster secret，此时客户端和服务器端都拥有了三个要素：random-client、random-server 和 premaster secret
  • 此时安全通道已经建立，以后的交流都会校检上面的三个要素通过算法算出的 session key

CA 数字证书认证中心：

如果网站只靠上图运作，可能会被中间人攻击，试想一下，在客户端和服务端中间有一个中间人，两者之间的传输对中间人来说是透明的，那么中间人完全可以获取两端之间的任何数据，然后将数据原封不动的转发给两端，由于中间人也拿到了三要素和公钥，它照样可以解密传输内容，并且还可以篡改内容。

为了确保我们的数据安全，我们还需要一个 CA 数字证书。HTTPS的传输采用的是非对称加密，一组非对称加密密钥包含公钥和私钥，通过公钥加密的内容只有私钥能够解密。上面我们看到，整个传输过程，服务器端是没有透露私钥的。而 CA 数字认证涉及到私钥，整个过程比较复杂，我也没有很深入的了解，后续有详细了解之后再补充下。

CA 认证分为三类：DV ( domain validation)，OV ( organization validation)，EV ( extended validation)，证书申请难度从前往后递增，貌似 EV 这种不仅仅是有钱就可以申请的。

对于一般的小型网站尤其是博客，可以使用自签名证书来构建安全网络，所谓自签名证书，就是自己扮演 CA 机构，自己给自己的服务器颁发证书。

生成数字证书

新建一个keys文件夹，方便存储数字证书

在keys文件夹下，摁住shift，点击右键打开powershell

第一步，为服务器端和客户端准备公钥、私钥

# 生成服务器端私钥
openssl genrsa -out server.key 1024
# 生成服务器端公钥
openssl rsa -in server.key -pubout -out server.pem


# 生成客户端私钥
openssl genrsa -out client.key 1024
# 生成客户端公钥
openssl rsa -in client.key -pubout -out client.pem

第二步，生成 CA 证书

# 生成 CA 私钥
openssl genrsa -out ca.key 1024

# X.509 Certificate Signing Request (CSR) Management.
openssl req -new -key ca.key -out ca.csr

# X.509 Certificate Data Management.
openssl x509 -req -in ca.csr -signkey ca.key -out ca.crt

在执行第二步时会出现（Common Name和Organization Name为必填项其他可省略）：

➜  keys  openssl req -new -key ca.key -out ca.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:My CA
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:localhost
Email Address []:
# 密钥口令也可为空

注意，这里的
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
后面生成客户端和服务器端证书的时候也需要填写，不要写成一样的。
现在是生成CA证书所以可以写成My CA，在生成生成服务器端证书和客户端证书时分别填写My Server, My Client。

Common Name (e.g. server FQDN or YOUR name) []:
这一项，是最后可以访问的域名，我这里为了方便测试，写成 localhost

第三步，生成服务器端证书

rganization Name为My Server

# 服务器端需要向 CA 机构申请签名证书，在申请签名证书之前依然是创建自己的 CSR 文件
openssl req -new -key server.key -out server.csr

# 向自己的 CA 机构申请证书，签名过程需要 CA 的证书和私钥参与，最终颁发一个带有 CA 签名的证书
openssl x509 -req -CA ca.crt -CAkey ca.key -CAcreateserial -in server.csr -out server.crt

第四步，生成客户端证书

rganization Name为My Client

# client 端
openssl req -new -key client.key -out client.csr

# client 端到 CA 签名
openssl x509 -req -CA ca.crt -CAkey ca.key -CAcreateserial -in client.csr -out client.crt

这时候keys文件夹下有了以下内容

.
└── keys
├── ca.crt
├── ca.csr
├── ca.key
├── ca.pem
├── ca.srl
├── client.crt
├── client.csr
├── client.key
├── client.pem
├── server.crt
├── server.csr
├── server.key
└── server.pem

建立本地localhost

在keys的同级目录下新建两个js文件
https-server.js文件构建了一个简单的 https 服务器

代码：

// file https-server.js
var https = require('https');
var fs = require('fs');

var options = {
  key: fs.readFileSync('./keys/server.key'),
  cert: fs.readFileSync('./keys/server.crt')
};

https.createServer(options, function(req, res) {
  res.writeHead(200);
  res.end('hello world');
}).listen(8000);

https-client.js文件带上了CA证书

// file http-client.js
var https = require('https');
var fs = require('fs');

var options = {
  hostname: "localhost",
  port: 8000,
  path: '/',
  methed: 'GET',
  key: fs.readFileSync('./keys/client.key'),
  cert: fs.readFileSync('./keys/client.crt'),
  ca: [fs.readFileSync('./keys/ca.crt')]
};

options.agent = new https.Agent(options);

var req = https.request(options, function(res) {
  res.setEncoding('utf-8');
  res.on('data', function(d) {
    console.log(d);
  });
});
req.end();

req.on('error', function(e) {
  console.log(e);
});

访问

在https-client.js和https-server.js文件所在目录
打开powershell
输入：

node https-server.js

此时运行本地服务器（不要关powershell窗口），接下来有两种访问方式

  1. nodejs访问

https-client.js所在目录新打开一个powershell窗口运行

node https-client.js

此时得到返回

hello world
  1. IE访问

在IE搜索栏输入：
https://localhost:8000

此时会显示不安全，这个问题就需要我们导入数字证书了

向IE导入数字证书

  1. 打开IE浏览器后，点击“工具”，然后选择“Internet选项”。
  2. 选择Internet选项中选择“内容”选项卡，选择“证书”。
  3. 在受信任的根证书颁发机构中，选择导入。
  4. 打开导入证书窗口，点击下一步。
  5. 浏览需要导入的证书，导入ca.crt，点击下一步。 添加后导入即可

]

补充知识

单双向认证区别

单向认证：客户端会认证服务器端身份，服务器端不对客户端进行认证

双向认证：客户端和服务端都会互相认证，即双发之间要证书交换

单向认证原理

  1. 客户端程序(浏览器)向服务器传送客户端 SSL 协议的版本号，加密算法的种类，产生的随机数，以及其他服务器和客户端之间通讯所需要的各种信息(发送的内容从服务端给的证书中加载,不需要程序处理,由建立的连接自动完成)。

  2. 服务器向客户端传送 SSL 协议的版本号，加密算法的种类，随机数以及其他相关信息，同时服务器还将向客户端传送自己的证书(公钥)。

  3. 客户端利用服务器传过来的信息验证服务器的合法性，服务器的合法性包括：证书是否过期，发行服务器证书的 CA 是否可靠，发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过， 通讯将断开；如果合法性验证通过，将继续进行第四步。

  4. 客户端随机产生一个用于后面通讯的“对称密码”，然后用服务器的公钥（服务器的公钥从步骤2中的服务器的证书中获得）对其加密，然后将加密后的“预主密码”传给服务器。

  5. 如果服务器要求客户的身份认证（在握手过程中为可选），用户可以建立一个随机数然后对其进行数据签名，将这个含有签名的随机数和客户自己的证书以及加密过的“预主密码”一起传给服务器。

  6. 如果服务器要求客户的身份认证，服务器必须检验客户证书和签名随机数的合法性，具体的合法性验证过程包括：客户的证书使用日期是否有效，为客户提供证书的 CA 是否可靠，发行 CA 的公钥能否正确解开客户证书的发行 CA 的数字签名，检查客户的证书是否在证书废止列表（CRL）中。检验如果没有通过，通讯立刻中断；如果验证通过，服务器将用自己的私钥解开加密的“预主密 码”，然后执行一系列步骤来产生主通讯密码（客户端也将通过同样的方法产生相同的主通讯密码）。

  7. 服务器和客户端用相同的主密码即“通话密码”，一个对称密钥用于 SSL 协议的安全数据通讯的加解密通讯。同时在 SSL 通讯过程中还要完成数据通讯的完整性，防止数据通讯中的任何变化。

  8. 客户端向服务器端发出信息，指明后面的数据通讯将使用的步骤7中的主密码为对称密钥，同时通知服务器客户端的握手过程结束。

  9. 服务器向客户端发出信息，指明后面的数据通讯将使用的步骤7中的主密码为对称密钥，同时通知客户端服务器端的握手过程结束。

  10. SSL 的握手部分结束，SSL 安全通道的数据通讯开始，客户和服务器开始使用相同的对称密钥进行数据通讯，同时进行通讯完整性的检验。

双向验证原理

  1. 浏览器发送一个连接请求给安全服务器。

  2. 服务器将自己的证书，以及同证书相关的信息发送给客户端(浏览器)。

  3. 客户端程序(浏览器)检查服务器送过来的证书是否是由自己信赖的 CA 中心所签发的。如果是，就继续执行协议；如果不是，客户端程序(浏览器)就给客户一个警告消息：警告客户这个证书不是可以信赖的，询问客户是否需要继续访问。

  4. 接着客户端程序(浏览器)比较证书里的消息，例如域名和公钥，与服务器刚刚发送的相关消息是否一致，如果是一致的，客户端程序(浏览器)认可这个服务器的合法身份。

  5. 服务器要求客户端(浏览器)发送客户端(浏览器)自己的证书。服务器收到证书后验证客户端的证书，如果没有通过验证，拒绝连接；如果通过验证，服务器获得客户端的公钥。

  6. 客户端(浏览器)告诉服务器自己所能够支持的通讯对称密码方案。

  7. 服务器从客户发送过来的密码方案中，选择一种加密程度最高的密码方案，用客户的公钥加过密后通知浏览器。

  8. 客户端(浏览器)针对这个密码方案，选择一个通话密钥，接着用服务器的公钥加过密后发送给服务器。

  9. 服务器接收到浏览器送过来的消息，用自己的私钥解密，获得通话密钥。

  10. 服务器、浏览器接下来的通讯都是用对称密码方案，对称密钥是加过密的。

上面所述的是双向认证 SSL 协议的具体通讯过程，这种情况要求服务器和用户双方都有证书。单向认证 SSL 协议不需要客户拥有 CA 证书，具体的过程相对于上面的步骤，只需将服务器端验证客户证书的过程去掉，以及在协商对称密码方案，对称通话密钥时，服务器发送给客户的是没有加过密的 （这并不影响 SSL 过程的安全性）密码方案。 这样，双方具体的通讯内容，就是加过密的数据，如果有第三方攻击，获得的只是加密的数据，第三方要获得有用的信息，就需要对加密的数据进行解密，这时候的 安全就依赖于密码方案的安全。而幸运的是，目前所用的密码方案，只要通讯密钥长度足够的长，就足够的安全。这也是我们强调要求使用 128 位加密通讯的原因。

感谢以下博客的帮助：

小胡子哥的个人博客之HTTPS证书生成原理和部署细节

MissEel的个人博客之创建本地的https证书

孔四月的博客之Node.js搭建一个简单的服务器

godjob的博客之ssl双向认证和单向认证原理

手机扫一扫

移动阅读更方便

阿里云服务器
腾讯云服务器
七牛云服务器

你可能感兴趣的文章

一键安装lnmp 环境
jenkins部署及gitlab联调
openNebula集群搭建

4

cephadm快速部署指定版本ceph集群及生产问题处理

5

Nomad 系列-Nomad 挂载存储卷

6

K8S 证书详解(认证)

7

云原生 | 企业内使用 CoreDNS 构建高性能、插件化的DNS服务器

8

OpenStack-T版+Ceph

9

使用阿里云ECS和RDS搭建个人博客

10

1Nginx基础及编译安装