OpenSSL 中文手册 | OpenSSL 中文网
本文介绍https传输协议中涉及的概念，流程，算法，如何实现等相关内容。
HTTP传输过程
HTTP 之所以被 HTTPS 取代，最大的原因就是不安全，至于为什么不安全，看了下面这张图就一目了然了
HTTP 在传输数据的过程中，所有的数据都是明文传输，自然没有安全性可言，特别是一些敏感数据，比如用户密码和信用卡信息等，一旦被第三方获取，后果不堪设想。为了解决这问题，需要对数据进行加密。https就是在这种场景下产生的
HTTPS协议
HTTPS 并非独立的通信协议，而是对 HTTP 的扩展，两者关系如下图。也就是说 HTTPS = HTTP + SSL / TLS
HTTPS 的整个通信过程如下图，可以分为两大阶段：证书验证和数据传输阶段，数据传输阶段又可以分为非对称加密和对称加密两个阶段。
针对HTTPS的传输过程，下面分别对对称加密，非对称，证书验证进行详细介绍
1. 对称加密
1.1 对称加密传输过程
对称加密，顾名思义就是加密和解密都是使用同一个密钥，常见的对称加密算法有 DES、3DES 和 AES 等。在https协议中，对称加密用于对真正的业务数据进行加密解密，对应图《HTTPS加密、解密、验证及数据传输过程》中步骤7，8。
1.2 对称加密优缺点
优点：算法公开、计算量小、加密速度快、加密效率高，适合加密比较大的数据。
缺点：
- 交易双方需要使用相同的密钥，也就无法避免密钥的传输，而密钥在传输过程中无法保证不被截获，因此对称加密的安全性得不到保证。
- 每对用户每次使用对称加密算法时，都需要使用其他人不知道的惟一密钥，这会使得发收信双方所拥有的钥匙数量急剧增长，密钥管理成为双方的负担。对称加密算法在分布式网络系统上使用较为困难，主要是因为密钥管理困难，使用成本较高。
1.3 使用对称加密数据传输的问题
客户端和服务器端需要使用相同的密钥，也就无法避免密钥的传输，而密钥在传输过程中无法保证不被截获，因此对称加密的安全性得不到保证。当黑客获取到对称加密的密钥后，可以在网络传输中任意获取用户信息，且可以对用户信息进行篡改。
如上图所示，黑客在网络中获取用户发送的加密数据后，用密钥进行解密后，得到用户信息，并修改了用户的密码password=abcd123。在这种情况下，服务器对获取到的数据进行解密后，得到的用户密码为abcd123。可以想象，如果这个操作是用来配置银行卡密码的，该有多恐怖。
2. 非对称加密
非对称加密，顾名思义，就是加密和解密需要使用两个不同的密钥：公钥（public key）和私钥（private key）。公钥与私钥是一对，如果用公钥对数据进行加密，只有用对应的私钥才能解密；如果用私钥对数据进行加密，那么只有用对应的公钥才能解密。非对称加密算法实现机密信息交换的基本过程是：甲方生成一对密钥并将其中的一把作为公钥对外公开；得到该公钥的乙方使用公钥对机密信息进行加密后再发送给甲方；甲方再用自己保存的私钥对加密后的信息进行解密。如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。常用的非对称加密算法是 RSA 算法。
在HTTPS协议中，使用公钥进行加密，私钥进行解密。
2.1 非对称加密传输过程
在https协议中，客户端通过非对称加密把密钥 KEY 发送给服务器。客户端在拿到服务器的公钥后，会生成一个随机码 (用 KEY 表示，这个 KEY 就是后续双方用于对称加密的密钥)，然后客户端使用公钥把 KEY 加密后再发送给服务器，服务器使用私钥将其解密，这样双方就有了同一个密钥 KEY，然后双方再使用 KEY 进行对称加密交互数据。在非对称加密传输 KEY 的过程中，即便第三方获取了公钥和加密后的 KEY，在没有私钥的情况下也无法破解 KEY (私钥存在服务器，泄露风险极小)，也就保证了接下来对称加密的数据安全。而上面这个流程图正是 HTTPS 的雏形，HTTPS 正好综合了这两种加密算法的优点，不仅保证了通信安全，还保证了数据传输效率。
2.2 非对称加密优缺点：
优点：算法公开，加密和解密使用不同的钥匙，私钥不需要通过网络进行传输，安全性很高。
缺点：计算量比较大，加密和解密速度相比对称加密慢很多。
2.3 非对称加密存在的问题
公开密钥加密方式还是存在一些问题的。那就是无法证明公开密钥本身就是货真价实的公开密钥。比如，正准备和某台服务器建立公开密钥加密方式下的通信时，如何证明收到的公开密钥就是原本预想的那台服务器发行的公开密钥。或许在公开密钥传输途中，真正的公开密钥已经被攻击者替换掉了。
为了解决上述问题，可以使用由数字证书认证机构(CA，CertificateAuthority)和其相关机关颁发的公开密钥证书。
3. 证书验证
数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。作为交互中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。CA中心为每个使用公开密钥的用户发放一个数字证书，数字证书的作用是证明证书中列出的用户合法拥有证书中列出的公开密钥。CA机构的数字签名使得攻击者不能伪造和篡改证书。它负责产生、分配并管理所有 参与网上交易的个体所需的数字证书，因此是安全电子交易的核心环节。
4. 回顾https协议传输流程
让我们再回顾一遍整个HTTPS数据传输流程：
1） 客户端请求 HTTPS 网址，然后连接到 server 的 443 端口 (HTTPS 默认端口，类似于 HTTP 的80端口)。
2）采用 HTTPS 协议的服务器必须要有一套数字 CA (Certification Authority)证书，证书是需要申请的，并由专门的数字证书认证机构(CA)通过非常严格的审核之后颁发的电子证书 (当然了是要钱的，安全级别越高价格越贵)。颁发证书的同时会产生一个私钥和公钥。私钥由服务端自己保存，不可泄漏。公钥则是附带在证书的信息中，可以公开的。证书本身也附带一个证书电子签名，这个签名用来验证证书的完整性和真实性，可以防止证书被篡改。
3）服务器响应客户端请求，将证书传递给客户端，证书包含公钥和大量其他信息，比如证书颁发机构信息，公司信息和证书有效期等。Chrome 浏览器点击地址栏的锁标志再点击证书就可以看到证书详细信息。
4）客户端解析证书并对其进行验证。如果证书不是可信机构颁布，或者证书中的域名与实际域名不一致，或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。就像下面这样：
如果证书没有问题，客户端就会从服务器证书中取出服务器的公钥A。然后客户端还会生成一个随机码 KEY，并使用公钥A将其加密。
5）客户端把加密后的随机码 KEY 发送给服务器，作为后面对称加密的密钥。
6）服务器在收到随机码 KEY 之后会使用私钥B将其解密。经过以上这些步骤，客户端和服务器终于建立了安全连接，完美解决了对称加密的密钥泄露问题，接下来就可以用对称加密愉快地进行通信了。
7）服务器使用密钥 (随机码 KEY)对数据进行对称加密并发送给客户端，客户端使用相同的密钥 (随机码 KEY)解密数据。
8）双方使用对称加密愉快地传输所有数据。
动手操作 -- 自签证书
使用openssl实现自签名证书
如下通过一个例子介绍如何生成https通讯中所需要的私钥，公钥，证书。如下的例子使用了openssl生成自签名证书。基本流程：
- 搞一个虚拟的CA机构，生成一个证书
- 生成一个自己的密钥，然后填写证书认证申请，拿给上面的CA机构去签名，于是就得到了自（自建CA机构认证的）签名证书
1. 虚拟一个CA认证机构
1）生成CA认证机构的证书密钥key。如下例子中，运行命令后会生成文件ca.key
生成CA认证机构的证书密钥key
# 需要设置密码，输入两次[root@nginx open]# openssl genrsa -des3 -out ca.key 4096
Generating RSA private key, 4096 bit long modulus
.........................................................++
.....................................................................................................................................++
e is 65537 (0x10001)
Enter pass phrase for ca.key:
Verifying - Enter pass phrase for ca.key:这种方式是不需要密码的
[root@nginx open]#
openssl genrsa -out ca.key 4096命令运行后，当前路径下可以看到CA的证书密钥key
[root@nginx open]# ls
ca.key2）用私钥ca.key生成CA认证机构的证书ca.crt
# 2. 用私钥ca.key生成CA认证机构的证书ca.crt 这里的机构是自己做客一个机构，外界不认可的
# 其实就是相当于用私钥生成公钥，再把公钥包装成证书[root@nginx open]# openssl req -new -x509 -key ca.key -out ca.crt -days 3650
Enter pass phrase for ca.key:
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) [XX]:CN
State or Province Name (full name) []:BEIJING
Locality Name (eg, city) [Default City]:beijing
Organization Name (eg, company) [Default Company Ltd]:JETTECH
Organizational Unit Name (eg, section) []:DEV
Common Name (eg, your name or your server's hostname) []:jettech.com.cn
Email Address []:wu_bo@hoperun.com命令运行后生成ca.crt证书文件。 这个证书ca.crt有的又称为"根证书",因为可以用来认证其他证书
[root@nginx open]# ls
ca.crt ca.key或
证数各参数含义如下：
C-----国家（Country Name）
ST----省份（State or Province Name）
L----城市（Locality Name）
O----公司（Organization Name）
OU----部门（Organizational Unit Name）
CN----产品名（Common Name）
emailAddress----邮箱（Email Address）
[root@nginx open]# openssl req -new -x509 -key ca.key -out ca.crt -days 3650 -subj "/C=CN/ST=BEIJING/L=beijing/O=JETTECH/OU=DEV/CN=jettech.com.cn/emailAddress=wu_bo2@hoperun.com"
Enter pass phrase for ca.key:1）和2）可以用一条命令生成
[root@nginx open]# openssl req -new -x509 -days 3650 -newkey rsa:4096 -keyout ca.key -out ca.crt -subj "/C=CN/ST=BEIJING/L=beijing/O=JETTECH/OU=DEV/CN=jettech.com.cn/emailAddress=wu_bo2@hoperun.com"查看
[root@nginx open]# openssl x509 -noout -in ca.crt -text
Certificate:Data:Version: 3 (0x2)Serial Number:96:b6:28:b0:7f:aa:65:9fSignature Algorithm: sha256WithRSAEncryptionIssuer: C=CN, ST=BEIJING, L=beijing, O=JETTECH, OU=DEV, CN=jettech.com.cn/emailAddress=wu_bo2@hoperun.comValidityNot Before: Jan 10 09:11:37 2024 GMTNot After : Jan 7 09:11:37 2034 GMTSubject: C=CN, ST=BEIJING, L=beijing, O=JETTECH, OU=DEV, CN=jettech.com.cn/emailAddress=wu_bo2@hoperun.comSubject Public Key Info:Public Key Algorithm: rsaEncryptionPublic-Key: (4096 bit)Modulus:00:f2:64:2d:42:6d:9a:b4:a7:8b:4f:fe:c9:d7:6d:90:4b:57:ca:58:2a:52:22:81:bf:62:24:6a:2c:4c:38:59:c4:ff:41:f0:44:3a:8f:58:a5:05:36:fd:51:4c:aa:77:87:a8:fc:7f:d4:8f:a7:d6:86:4d:53:62:af:70:d2:ca:54:5f:b6:7c:32:a6:3b:e9:ff:83:2a:44:08:b5:67:80:6b:82:6e:dd:a7:51:da:76:df:77:6a:27:fa:01:c3:fe:70:88:26:a7:6a:6e:c0:59:eb:63:d7:ca:77:44:5a:e3:c8:56:e9:55:69:11:10:fe:43:41:2e:2a:34:a4:d6:f4:b3:47:58:7c:d7:d9:7a:1e:0a:f5:86:3e:3c:2d:fe:2c:4f:bb:4c:61:c1:78:8f:c5:61:74:3f:ac:ea:7f:37:11:32:59:44:f7:5c:db:9a:34:6c:dc:a6:d8:69:bd:da:15:77:d6:55:3c:47:aa:f5:0d:e3:1e:99:7c:09:b0:aa:46:06:64:6d:c0:d9:7e:a3:83:c3:a4:47:f9:d8:44:7d:e0:4e:19:18:3e:0a:81:a2:bf:3c:da:61:d6:3a:1f:14:14:fc:9a:1e:3f:9f:83:b2:e1:76:a3:84:28:c1:77:bb:6b:ff:3e:29:25:6b:4c:f9:dc:a9:ab:38:27:1d:55:d0:5d:a8:7d:6b:e9:e6:78:c8:9b:25:34:2a:56:6c:19:28:4c:ec:8e:17:4c:24:a4:ae:9c:ec:ca:63:4e:6b:40:84:26:db:40:59:e3:bd:5c:c9:81:73:fd:41:f9:12:43:aa:78:2e:5d:7f:9c:83:61:28:c6:00:96:fa:65:90:01:ca:49:b5:d6:93:a7:ff:02:5b:c4:ea:17:9e:28:92:da:63:86:41:4a:b7:8d:d3:ef:77:69:ca:56:d3:aa:5f:90:09:82:bc:49:f3:bf:0f:b5:6f:e9:be:f1:6c:86:87:6f:4d:d5:7c:0f:2a:60:13:c3:d2:79:97:a4:b1:b3:f3:5a:0b:2c:5d:ce:ba:67:77:3d:c2:ba:97:34:b8:8c:7e:cc:5d:84:5a:47:f0:a0:1a:ff:b4:bf:4f:dc:04:8e:11:9f:9e:89:80:61:f7:79:10:1a:32:14:6f:e8:80:2e:7d:73:4e:7d:de:b4:97:fb:81:8d:fc:a5:99:95:df:4b:0a:b3:78:25:08:60:44:9a:ce:d4:b0:d5:b4:f6:47:6a:ed:1e:95:0b:b4:4f:f3:43:d2:b7:1c:2c:6b:f4:b8:f1:ea:6b:52:5f:49:c2:7d:29:f6:d5:ba:f8:e5:c4:37:ac:91:20:9b:5a:8a:54:e0:e6:0a:fd:6e:a7:02:ad:af:22:e3:8c:2d:3f:c7Exponent: 65537 (0x10001)X509v3 extensions:X509v3 Subject Key Identifier: 2E:FD:D3:05:5C:53:71:88:D1:4F:2F:BA:00:F2:D3:9F:62:AF:9E:17X509v3 Authority Key Identifier: keyid:2E:FD:D3:05:5C:53:71:88:D1:4F:2F:BA:00:F2:D3:9F:62:AF:9E:17X509v3 Basic Constraints: CA:TRUESignature Algorithm: sha256WithRSAEncryption2b:67:a4:53:1a:a8:49:14:96:36:f5:95:85:48:03:5d:4b:39:02:e2:e4:8a:13:55:de:00:d5:43:ed:38:f0:9f:6d:ed:d1:dc:8c:c1:a3:bb:e7:4c:f8:3d:b7:ca:81:0b:0d:61:be:5e:f6:80:7b:fc:25:fc:e1:19:91:2e:20:92:78:5a:a2:89:40:d8:a5:29:33:a1:10:37:ad:fe:1f:28:a7:96:3b:f7:83:30:e2:cf:98:0d:91:22:6d:a9:33:e8:55:03:dd:c8:8e:43:3f:68:6e:60:28:d6:1b:ab:30:af:72:0e:f6:eb:9e:aa:de:dd:13:26:d1:16:de:c3:4a:d2:37:83:b4:aa:1c:70:0d:07:b0:f2:18:5e:73:10:c7:40:d8:e1:90:b8:f7:74:4e:b3:69:6d:50:f2:e3:59:7e:92:15:69:b9:91:d7:a5:15:c4:ea:23:c8:2b:bb:b5:08:37:ff:ed:7e:15:21:7c:82:32:cc:b0:10:51:d6:b9:81:5f:91:e6:09:90:1c:e4:7d:e5:6a:19:54:e4:ed:b6:ca:1d:eb:6e:8f:f5:53:67:b9:bc:61:13:ab:c6:f8:79:84:92:e5:27:87:1a:74:b7:04:3e:b7:49:96:76:8e:54:1b:1a:cb:31:33:48:30:02:f5:75:f7:4a:70:52:5b:26:7e:39:a2:48:65:23:40:16:7e:bf:99:17:d1:d6:46:6d:3b:8d:98:3f:50:09:06:b0:95:0b:52:99:d3:9e:db:99:ac:d7:c6:e0:c2:05:3c:4b:bc:4c:db:46:22:ca:e1:9f:b8:c7:e3:4d:45:22:73:df:95:dc:83:0c:cf:c8:8f:a6:23:d8:6e:cf:0f:52:f0:bc:df:a0:61:ac:63:75:04:e8:d1:b6:36:0c:6e:e6:2e:fe:49:f9:ca:b3:10:0f:5c:33:57:52:e3:95:20:9d:32:5a:5a:6a:13:e8:e9:25:a2:ce:71:ba:cc:5a:e9:5b:6d:5a:16:a4:59:4e:e5:5b:c1:0c:ab:5b:42:56:4a:09:23:63:16:6b:6b:58:44:82:6e:10:f1:2f:79:bf:6a:40:57:ea:2c:50:76:55:f6:ea:01:84:28:a8:16:1d:ac:ed:49:71:0c:f2:8d:2e:80:a2:b2:16:47:6c:18:49:96:60:d9:42:92:68:c3:84:dc:bb:91:15:6f:be:0a:88:81:be:48:7e:e6:9a:31:aa:e1:d3:3d:64:39:19:1c:34:88:87:18:70:62:1e:04:42:41:8a:93:92:e4:92:4a:c7:f0:49:41:da:34:fb:a3:67:0a:c5:33:e2:ef:c2:a9:26:a6:bb:49:2b:96:96:41:d8:be:bb:54:d8:5e:19可以吧ca.crt和ca.key 输出到ca.pem
[root@nginx open]# cat ca.crt ca.key >ca.pemca.crt ca.key ca.pem server.csr server.ke2. 生成网站证书
用上面那个虚构出来的CA机构来认证，得到自签证书
1）生成自己网站的密钥server.key
1. 生成自己网站的密钥server.key[root@nginx open]# openssl genrsa -des3 -out server.key 1024
Generating RSA private key, 1024 bit long modulus
....++++++
........................++++++
e is 65537 (0x10001)
Enter pass phrase for server.key:
Verifying - Enter pass phrase for server.key:
[root@nginx open]# 2) 生成自己网站证书的请求文件。如果找外面的CA机构认证，也是发个请求文件给他们。这个私钥就包含在请求文件中了，认证机构要用它来生成网站的公钥，然后包装成一个证书
# 如果找外面的CA机构认证，也是发个请求文件给他们
# 这个私钥就包含在请求文件中了（server.csr），认证机构要用它来生成网站的公钥，然后包装成一个证书[root@nginx open]# openssl req -new -sha256 -key server.key -out server.csr -subj "/C=CN/ST=BEIJING/L=beijing/O=JETTECH/OU=DEV/CN=allen.com.cn/emailAddress=allen@hoperun.com"
Enter pass phrase for server.key:
[root@nginx open]# ls
ca.crt ca.key server.csr server.key1）和2）可以用一条命令生成证书请求文件：
[root@nginx open]# openssl req -new -sha256 -newkey rsa:2048 -keyout server.key -out server.csr -subj "/C=CN/ST=BEIJING/L=beijing/O=JETTECH/OU=DEV/CN=allen.com.cn/emailAddress=allen@hoperun.com"
Generating a 2048 bit RSA private key
...........................+++
.....................................................+++
writing new private key to 'server.key'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
[root@nginx open]# ls
ca.crt ca.key ca.pem server.csr server.key3) 使用虚拟的CA认证机构的证书ca.crt，来对自己网站的证书请求文件server.csr进行处理，生成签名后的证书server.crt. 注意设置序列号和有效期（一般都设1年）
# 3. 使用虚拟的CA认证机构的证书ca.crt，来对自己网站的证书请求文件server.csr进行处理，生成签名后的证书server.crt
# 生成了证书，证书内含有公钥，因此，不需要单独提供公钥
# 注意设置序列号和有效期（一般都设1年）[root@nginx open]# openssl x509 -req -sha256 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt -days 365
Signature ok
subject=/C=CN/ST=BEIJING/L=beijing/O=JETTECH/OU=DEV/CN=allen.com.cn/emailAddress=allen@hoperun.com
Getting CA Private Key
Enter pass phrase for ca.key:
[root@nginx open]# ls
ca.crt ca.key ca.pem server.crt server.csr server.keyopenssl x509 -req -days 36500 -sha256 -extensions v3_req -CA ca.cert -CAkey ca.key -CAserial ca.srl -CAcreateserial -in server.csr -out server.cert
查看证书内容：
[root@nginx open]# openssl x509 -noout -in server.crt -text
Certificate:Data:Version: 1 (0x0)Serial Number: 1 (0x1)Signature Algorithm: sha256WithRSAEncryptionIssuer: C=CN, ST=BEIJING, L=beijing, O=JETTECH, OU=DEV, CN=jettech.com.cn/emailAddress=wu_bo2@hoperun.comValidityNot Before: Jan 10 09:34:08 2024 GMTNot After : Jan 9 09:34:08 2025 GMTSubject: C=CN, ST=BEIJING, L=beijing, O=JETTECH, OU=DEV, CN=allen.com.cn/emailAddress=allen@hoperun.comSubject Public Key Info:Public Key Algorithm: rsaEncryptionPublic-Key: (2048 bit)Modulus:00:c4:01:76:8e:23:d8:a2:ac:60:0a:ec:84:12:2a:f0:bd:1e:d9:1e:a0:53:9d:e4:51:a2:29:3b:57:d4:43:fc:b1:0b:57:b5:0e:7e:30:55:32:6a:34:56:64:ab:b9:1d:3b:bb:69:e7:db:ea:aa:b0:30:86:24:70:e5:59:e5:5e:fd:9e:35:56:23:86:a1:33:4d:f1:64:ac:88:31:a4:35:ac:ec:0c:98:dc:fe:ef:4c:dc:cb:2e:5b:8c:f6:8f:af:5a:2f:19:a9:c6:1f:3e:32:46:33:ca:18:57:a3:e4:b3:27:c1:1c:61:29:f0:30:0c:82:79:da:a8:15:95:c4:48:62:64:21:b5:98:3b:4e:45:75:92:29:7e:cf:bd:61:86:b2:6d:d4:89:12:83:2c:b0:05:d9:d2:2e:c6:a8:f2:ce:54:1a:bd:85:b9:80:db:06:f1:f4:3e:4d:d4:c5:bf:d8:80:de:db:df:9e:0e:75:ce:ee:e8:39:04:ea:60:66:fd:22:c8:51:1d:b0:fc:1f:a4:e9:a2:17:2a:40:4b:bd:81:ef:f0:8f:3d:6e:dc:bc:13:82:ea:f3:1e:0b:44:0c:0c:6e:5d:39:b6:ce:7d:b9:be:29:59:ac:0e:85:bb:29:13:e6:ff:6c:11:9d:d5:82:d5:84:63:d6:cb:bc:70:c9:1b:ebExponent: 65537 (0x10001)Signature Algorithm: sha256WithRSAEncryption65:41:09:c4:09:dd:00:28:22:dc:59:ff:5c:da:0d:37:90:5b:7b:06:0f:ff:37:c0:f4:51:ee:79:1c:54:d0:ed:37:ca:4e:26:dc:22:27:14:b8:36:b7:1b:18:73:30:b5:4e:d4:24:f0:03:41:a9:22:b1:23:86:a8:c7:f1:86:67:51:55:dd:52:db:43:11:69:50:f5:18:85:a4:23:72:b9:46:8e:e1:d5:d3:be:08:b8:dd:39:17:81:82:df:7c:f5:2d:56:cf:4b:b9:d3:3c:3d:26:d2:a0:08:23:7d:c7:02:41:12:cc:ba:6d:bd:2d:69:2f:ae:b9:4a:5d:83:c6:e3:7b:bb:20:b6:5d:31:ab:16:5e:ee:10:ee:3a:b2:70:f1:b5:2f:42:08:8e:7a:53:33:25:18:b1:a0:bd:36:1b:8f:84:f8:65:0c:fa:aa:be:f2:f1:a4:cd:6d:d2:27:36:10:d0:34:57:4b:b2:1e:f9:f0:13:c8:57:c9:57:14:78:e9:36:b3:87:c8:06:60:22:74:21:d1:26:cb:d4:82:83:5c:5b:ba:a6:20:a3:56:be:af:d9:a0:d5:6a:98:53:46:fc:a5:52:92:4e:99:f0:f5:29:34:1b:43:80:ab:7d:32:3d:e8:cf:00:01:32:f9:2f:e5:35:89:93:8d:5a:f2:8d:8b:10:ab:27:4a:78:99:65:5a:0d:5d:d8:34:01:fb:3a:76:12:09:34:29:29:8e:9b:9a:ea:6e:8c:da:f5:ae:7e:0e:cb:54:eb:b3:ce:6c:f2:a6:d5:1b:18:40:09:88:72:d4:90:09:bc:b9:2f:92:84:f7:8c:8c:ba:a3:20:cd:ec:53:91:da:49:66:94:69:ee:d0:2f:77:24:9a:79:37:55:85:bd:5c:51:e8:34:28:7b:8a:eb:8b:89:1f:65:3c:4c:73:2b:bf:61:49:2f:c3:bf:e6:e9:6c:48:ff:f3:16:04:a7:ee:77:02:96:0a:70:6a:e6:e4:6f:c0:b1:97:9b:e8:02:fc:f2:7e:f5:8a:c3:34:33:6d:a0:5d:45:96:b0:19:ee:bc:0d:37:e1:c1:d2:e7:48:ed:d2:ad:50:58:6f:83:f8:8c:b6:57:17:98:22:3f:cb:4d:c3:18:f4:f1:e6:11:8b:fb:90:f6:d0:5c:a7:c3:40:6a:07:41:d1:30:fe:0f:fc:b9:e0:45:6a:e4:c5:51:92:ac:41:38:b3:d6:87:1c:d0:d6:31:c7:0c:f0:06:05:32:60:75:f5:54:8b:fc:6f:15:35:46:d7:7b:d4:c3:cb:ec:81:79:e8:a3:3f:fb:44:c4:90:46:9a:e9:73:e7:fc:ad:6a:d0:2e:4e:02:91:3c:db查看公钥：
[root@nginx open]# openssl x509 -noout -in server.crt -noout -pubkey
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxAF2jiPYoqxgCuyEEirw
vR7ZHqBTneRRoik7V9RD/LELV7UOfjBVMmo0VmSruR07u2nn2+qqsDCGJHDlWeVe
/Z41ViOGoTNN8WSsiDGkNazsDJjc/u9M3MsuW4z2j69aLxmpxh8+MkYzyhhXo+Sz
J8EcYSnwMAyCedqoFZXESGJkIbWYO05FdZIpfs+9YYaybdSJEoMssAXZ0i7GqPLO
VBq9hbmA2wbx9D5N1MW/2IDe29+eDnXO7ug5BOpgZv0iyFEdsPwfpOmiFypAS72B
7/CPPW7cvBOC6vMeC0QMDG5dObbOfbm+KVmsDoW7KRPm/2wRndWC1YRj1su8cMkb
6wIDAQAB
-----END PUBLIC KEY-----3.测试
单向认证命令行：
服务器：
[root@nginx open]# openssl s_server -CAfile ca.crt -cert server.crt -key server.key -accept 22580
Enter pass phrase for server.key:
Using default temp DH parameters
ACCEPT客户端：
[root@nginx open]# openssl s_client -CAfile ca.crt -cert server.crt -key server.key -connect 172.16.10.21 -port 22580双向认证：
服务器：
[root@nginx open]# openssl s_server -CAfile ca.crt -cert server.crt -key server.key -accept 22580 -Verify 1
verify depth is 1, must return a certificate
Enter pass phrase for server.key:
Using default temp DH parameters
ACCEPT客户端：
[root@nginx open]# openssl s_client -CAfile ca.crt -cert server.crt -key server.key -cert client.cer -key client.key -connect 127.0.0.1 -port 22580OpenSSL创建生成CA证书、服务器、客户端证书及密钥_windows openssl生成ca-CSDN博客
附录
名称解释
如下整理了我们学习https协议的过程中会遇到名词含义。
| 英文缩写 | 英文全称 | 中文翻译 | 说明 |
|---|---|---|---|
| HTTPS | Hypertext Transfer Protocol Secure | 安全的http，等同于http+SSL/TLS | |
| SSL | Secure Socket Layer | 套接字层安全 | SSL协议要求建立在可靠的传输层协议(TCP)之上 |
| TLS | Transport Layer Security | 传输层安全 | 支持加密和身份验证的安全通信协议TLS 是 SSL 的直接后继者，所有版本的 SSL 目前均已弃用。但是，使用术语 SSL 来描述 TLS 连接的情况很常见。在大多数情况下，术语SSL 和 SSL/TLS 都是指 TLS 协议和 TLS 证书。 |
| CA | certificate authority | 证书颁发机构 | HTTPS 网站需要从证书颁发机构（CA）获取 SSL/TLS 证书。我们有时在访问公司内网https请求时，浏览器提示：“您的链接不是私密连接”，此错误通常是因为网站的SSL 证书并非由合法证书颁发机构颁发导致 |
证书相关文件常用扩展名
注意：这个扩展名是随便叫的，你叫.txt也行，这里是为了规范使用，便于识别，尽量采用下面标准后缀
| 扩展名 | 含义 | 备注 |
|---|---|---|
| .cer|.crt | 公钥证书CRT文件是SSL证书的基本文件格式，也称为X.509证书。它包含服务器的公钥、证书颁发机构（CA）的数字签名和证书序列号 | 文件是二进制格式，只保存证书，不保存私钥,.cer常见于Windows系统, crt常见于Linux系统，可能是PEM编码,也可能是DER编码 |
| .pem(Privacy Enhanced Mail) | BASE64编码的文本格式，可以存放证书或私钥，或者两者都包含。 .PEM 文件如果只包含私钥，一般用.KEY文件代替。 | PEM文件通常是BASE64编码的文本文件，并具有以下扩展名：.pem、.crt、.cer和.key。PEM文件可以包含多个证书，每个证书由BEGIN CERTIFICATE和END CERTIFICATE标记包裹 |
| .key | 通常用于存放公钥或者私钥.key 单独存储的.pem格式的密钥，一般保存为.key | 非X509证书，PEM/DER编码均有； |
| .csr(Certificate Signing Request) | 证书签名请求.csr 证书签名请求，包含证书持有人的信息，如国家，域名等 | 不是证书，用于证书颁发机构申请签名证书，是一个公钥和附加信息 |
| .pfx / .p12(predecessor of PKCS#12) | crt和key存在一个pfx文件中pkcs1/pkcs12 公钥加密（非对称加密）的一种标准，一般存储为.p12等包含证书和密钥的封装格式 | 这样的证书文件是二进制格式，同时包含证书和私钥，且一般有密码保护。 |
| .jks(Java Key Storage) | Java的专利，使用专用工具keytool生成具，可将PFX转为JKS。 |
参考资料
https://blog.csdn.net/lk2684753/article/details/100160856
https://segmentfault.com/a/1190000021494676
https://www.jianshu.com/p/0e9ee7ed6c1d
https://blog.csdn.net/m0_454060
HTTPS详解及openssl简单使用 - 知乎
Openssl证书管理
nginx配置本地https(openssl双向认证)（好文章！！申精！！）_asynchdns idn ipv6 largefile gss-api kerberos spne-CSDN博客
https://www.cnblogs.com/isylar/p/10002117.html
[root@nginx nginx]# cat nginx.conf
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
include /usr/share/nginx/modules/*.conf;
events {worker_connections 1024;
}
http {log_format main '$remote_addr - $remote_user [$time_local] "$request" ''$status $body_bytes_sent "$http_referer" ''"$http_user_agent" "$http_x_forwarded_for"';access_log /var/log/nginx/access.log main;sendfile on;tcp_nopush on;tcp_nodelay on;keepalive_timeout 65;types_hash_max_size 4096;include /etc/nginx/mime.types;default_type application/octet-stream;include /etc/nginx/conf.d/*.conf;upstream nexus_servers_http {server 192.168.99.189 max_fails=3 fail_timeout=5s;}server {listen 80;listen [::]:80;server_name allen.jettech.com;root /usr/share/nginx/html;location / {proxy_pass http://nexus_servers_http;proxy_set_header Host $host:$server_port;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;proxy_next_upstream http_502 http_504 error timeout invalid_header; }}server {listen 443 ssl;ssl off;#listen 443 ssl http2;#listen [::]:443 ssl http2;server_name allen.jettech.com;ssl_certificate "/home/wubo/rancher/cert/open/allen.jettech.com.crt";#配置证书位置ssl_certificate_key "/home/wubo/rancher/cert/open/allen.jettech.com.key";#配置秘钥位置#ssl_verify_client on; #开启客户端证书验证，双向认证#ssl_client_certificate "/home/wubo/rancher/cert/open/ca.crt"; #双向认证 #根级证书公钥，用于验证各个二级clientssl_session_timeout 10m;ssl_protocols SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2; #按照这个协议配置ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE; #按照这个套件配置ssl_prefer_server_ciphers on;ssl_session_cache shared:SSL:1m;location / {proxy_pass http://nexus_servers_http;proxy_set_header Host $host:$server_port;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;proxy_next_upstream http_502 http_504 error timeout invalid_header; }}
}- HTTP
简介：
HyperText Transfer Protocol，超文本传输协议，是互联网上使用最广泛的一种协议，所有WWW文件必须遵循的标准。HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全。
使用TCP端口为：80 - HTTPS
Hyper Text Transfer Protocol over Secure Socket Layer，安全的超文本传输协议，网景公式设计了SSL(Secure Sockets Layer)协议用于对Http协议传输的数据进行加密，保证会话过程中的安全性。
使用TCP端口默认为443 -
SSL协议加密方式
SSL协议即用到了对称加密也用到了非对称加密(公钥加密)，在建立传输链路时，SSL首先对对称加密的密钥使用公钥进行非对称加密，链路建立好之后，SSL对传输内容使用对称加密。
1.对称加密
速度高，可加密内容较大，用来加密会话过程中的消息。
2.公钥加密
加密速度较慢，但能提供更好的身份认证技术，用来加密对称加密的密钥
单向认证
Https在建立Socket连接之前，需要进行握手，具体过程如下：
1、客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息。
2、服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书
3、客户端使用服务端返回的信息验证服务器的合法性，包括：
-
证书是否过期
-
发型服务器证书的CA是否可靠
-
返回的公钥是否能正确解开返回证书中的数字签名
-
服务器证书上的域名是否和服务器的实际域名相匹配
验证通过后，将继续进行通信，否则，终止通信
4、客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择
5、服务器端在客户端提供的加密方案中选择加密程度最高的加密方式。
6、服务器将选择好的加密方案通过明文方式返回给客户端
7、客户端接收到服务端返回的加密方式后，使用该加密方式生成产生随机码，用作通信过程中对称加密的密钥，使用服务端返回的公钥进行加密，将加密后的随机码发送至服务器
8、服务器收到客户端返回的加密信息后，使用自己的私钥进行解密，获取对称加密密钥。 在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全。
双向认证
双向认证和单向认证原理基本差不多，只是除了客户端需要认证服务端以外，增加了服务端对客户端的认证，具体过程如下：
- 1、客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息。
2、服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书
3、客户端使用服务端返回的信息验证服务器的合法性，包括：- 证书是否过期
- 发型服务器证书的CA是否可靠
- 返回的公钥是否能正确解开返回证书中的数字签名
- 服务器证书上的域名是否和服务器的实际域名相匹配
验证通过后，将继续进行通信，否则，终止通信
4、服务端要求客户端发送客户端的证书，客户端会将自己的证书发送至服务端
5、验证客户端的证书，通过验证后，会获得客户端的公钥
6、客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择
7、服务器端在客户端提供的加密方案中选择加密程度最高的加密方式
8、将加密方案通过使用之前获取到的公钥进行加密，返回给客户端
9、客户端收到服务端返回的加密方案密文后，使用自己的私钥进行解密，获取具体加密方式，而后，产生该加密方式的随机码，用作加密过程中的密钥，使用之前从服务端证书中获取到的公钥进行加密后，发送给服务端
10、服务端收到客户端发送的消息后，使用自己的私钥进行解密，获取对称加密的密钥，在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全。
公网证书：
SSL For Free - Free SSL Certificates in Minutes
![[Kubernetes]7. K8s包管理工具Helm、使用Helm部署mongodb集群(主从数据库集群)](https://img-blog.csdnimg.cn/direct/7acd61edb2c84e39b0c68682399d3ef1.png)
