HTTPS原理剖析及实战

SSL介绍

由于 HTTP 协议在通信过程中，是基于明文通信，并且底层是基于 TCP/IP 协议进行通信，那么按照 TCP/IP 协议族的工作机制，通信内容在所有的通信线路上都有可能遭到拦截和窃取。窃取这个过程其实很简单，通过抓包工具 Wireshark 就可以截获请求和响应的内容。由于 HTTP 协议通信的不安全性，所以人们为了防止信息在传输过程中遭到泄漏或者篡改，就想出来对传输通道进行加密的方式 https。https 是一种加密的超文本传输协议，它与 HTTP 在协议差异在于对数据传输的过程中，https对数据做了完全加密。由于 http 协议或者 https 协议都是处于 TCP 传输层之上，同时网络协议又是一个分层的结构，所以在 tcp 协议层之上增加了一层 SSL（Secure Socket Layer，安全层）或者 TLS（Transport Layer Security） 安全层传输协议组合使用用于构造加密通道；Ssl 是 netscape 公司设计的（Secure sockets layer)，后来互联网标准化组织 ISOC 接替了NETScape 公司，发布了 SSL 的升级版 TLS。接着 TLS 的版本又进行了多次升级； 实际上我们现在的 HTTPS 都是用的 TLS 协议，但是由于 SSL 出现的时间比较早，并且依旧被现在浏览器所支持，因此 SSL 依然是 HTTPS 的代名词。

SSL设计原理

逆向推导 https 的设计过程

我们先不去探究 ssl 的实现原理，我们先从设计者的角度去思考如何去建立一个安全的传输通道

从第一个消息开始

客户端 A 向服务端 B 发送一条消息，这个消息可能会被拦截以及篡改，我们如何做到 A 发送给 B 的数据包，及时被拦截了，也没办法得知消息内容并且也不能查看呢？

利用对称加密

要做到消息不能被第三方查看以及篡改，那么第一想法就是对内容进行加密，同时，该消息还需要能被服务端进行解密。所以我们可以使用对称加密算法来实现，密钥 S 扮演着加密和解密的角色。在密钥 S 不公开的情况下，就可以保证安全性？

没那么简单

在互联网世界，通信不会这么简单，也许是这样。

会存在多个客户端和服务端产生连接，而这个客户端也许是一个潜伏者，如果他也有对称密钥 S，那相当于上面的方案是不可行的？如果服务端和每个客户端通信的时候使用不同的加密算法呢？

似乎能够完美解决问题，然后？密钥如何分配呢？也就是服务端怎么告诉客户端该使用那种对称加密算法呢？解决办法似乎只能通过建立会话以后进行协商了？

协商过程又是不安全的

协商过程，意味着又是基于一个网络传输的情况下去动态分配密钥，可是这个协商过程又是不安全的，怎么破？

非对称加密出马

非对称加密算法的特点是：私钥加密后的密文，只要有公钥，都能解密，但是公钥加密后的密文，只有私钥可以解密。私钥只有一个人有，而公钥可以发给所有人

这样就可以保证 A/B 向服务器端方向发送的消息是安全的。似乎我们通过非对称加密算法解决了密钥的协商的问题？但是

公钥怎么拿？

使用非对称加密算法，那么如何让 A、B 客户端安全地持有公钥？那么我们逐步思考，有两种我们能想到的方案：

1. 服务器端将公钥发送给每一个客户端

2. 服务器端将公钥放到一个远程服务器，客户端可以请求到 （多了一次请求，还得解决公钥放置问题）方案一似乎不可行，因为，传输过程又是不安全的？公钥可能会被调包

引入第三方机构

到上面这一步，最关键的问题是，客户端如何知道给我公钥的是黄蓉还是小龙女？只能找本人去证实？或者有一个第三者来帮你证实，并且第三者是绝对公正的。所以，引入一个可信任的第三者是一个好的方案服务端把需要传递给客户端的公钥，通过第三方机构提供的私钥对公钥内容进行加密后，再传递给客户端？ 通过第三方机构私钥对服务端公钥加密以后的内容，就是一个简陋版本的“数字证书”。这个证书中包含【服务器公钥】

客户端拿到这个证书以后，因为证书是第三方机构使用私钥加密的。客户端必须要有第三方机构提供的公钥才能解密证书。这块又涉及到第三方机构的公钥怎么传输？（假设是先内置在系统中）以及还有一个问题，第三方机构颁发的证书是面向所有用户，不会只针对一家发放。如果不法分子也去申请一个证书呢？

如果不法分子也拿到证书？

如果不法分子也申请了证书，那它可以对证书进行调包。客户端在这种情况下是无法分辨出收到的是你的证书，还是中间人的。因为不论是中间人的、还是你的证书都能使用第三方机构的公钥进行解密。

验证证书的有效性

事情发展到现在，问题演变成了，客户端如何识别证书的真伪？在现实生活中，要验证一个东西的真伪，绝大部分都是基于编号去验证（比如大学毕业证书，比如买的数码产品是否是山寨），我之前讲过，计算机领域的解决方案都是人为去实现的，所以在这里，解决方案也是一样，如果给这个数字证书添加一个证书编号？是不是就能达到目的呢？证书上写了如何根据证书的内容生成证书编号。客户端拿到证书后根据证书上的方法自己生成一个证书编号，如果生成的证书编号与证书上的证书编号相同，那么说明这个证书是真实的。这块有点类似于 md5 的验证，我们下载一个软件包，都会提供一个 md5 的值，我们可以拿到这个软件包以后通过一个第三方软件去生成一个 md5 值去做比较，如果一样表示这个软件包没被篡改过.

对服务端的数据进行 MD5 算法得到一个MD5 的值，生成证书编号，使用第三方机构的私钥对这个证书编号进行加密，并且会在证书中添加证书编号的生成算法浏览器内置的 CA 公钥可以解密服务端 CA 私钥加密的证书，通过浏览器内置的 CA 证书的证书编号算法对服务端返回的证书编号进行验签

第三方机构的公钥证书存哪里？

浏览器和操作系统都会维护一个权威的第三方机构列表（包括他们的公钥）因为客户端接收到的证书中会些颁发机构，客户端就根据这个办法机构的值在本地找到响应的公钥说到这里，我想大家一定知道，证书就是 HTTPS 中的数字证书，证书编号就是数字签名，而第三方机构就是数字证书的签发机构（CA）

Https 原理分析

HTTPS 证书的申请过程

1. 服务器上生成 CSR 文件（证书申请文件，内容包括证书公钥、使用的 Hash 签名算法、申请的域名、公司名称、职位等信息）

2. 把 CSR 文件和其他可能的证件上传到 CA 认证机构，CA 机构收到证书申请之后，使用申请中的 Hash 算法，对部分内容进行摘要，然后使用 CA 机构自己的私钥对这段摘要信息进行签名（相当于证书的唯一编号）

3. 然后 CA 机构把签名过的证书通过邮件形式发送到申请者手中。

4. 申请者收到证书之后部署到自己的 web 服务器中

客户端请求交互流程

1. 客户端发起请求(Client Hello 包)

a) 三次握手，建立 TCP 连接

b) 支持的协议版本(TLS/SSL)

c) 客户端生成的随机数 client.random，后续用于生成“对话密钥”

d) 客户端支持的加密算法

e) sessionid，用于保持同一个会话（如果客户端与服务器费尽周折建立了一个 HTTPS 链接，刚建完就断了，也太可惜）

2. 服务端收到请求，然后响应（Server Hello）

a) 确认加密通道协议版本

b) 服务端生成的随机数 server.random，后续用于生成“对话密钥”

c) 确认使用的加密算法（用于后续的握手消息进行签名防止篡改）

d) 服务器证书（CA 机构颁发给服务端的证书）

3. 客户端收到证书进行验证

a) 验证证书是否是上级 CA 签发的, 在验证证书的时候，浏览器会调用系统的证书管理器接口对证书路径中的所有证书一级一级的进行验证，只有路径中所有的证书都是受信的，整个验证的结果才是受信

b) 服务端返回的证书中会包含证书的有效期，可以通过失效日期来验证 证书是否过期

c) 验证证书是否被吊销了

d) 前面我们知道 CA 机构在签发证书的时候，都会使用自己的私钥对证书进行签名证书里的签名算法字段 sha256RSA 表示 CA 机构使用 sha256 对证书进行摘要，然后使用 RSA 算法对摘要进行私钥签名，而我们也知道 RSA 算法中，使用私钥签名之后，只有公钥才能进行验签。

e) 浏览器使用内置在操作系统上的 CA 机构的公钥对服务器的证书进行验签。确定这个证书是不是由正规的机构颁发。验签之后得知 CA 机构使用 sha256 进行证书摘要，然后客户端再使用 sha256 对证书内容进行一次摘要，如果得到的值和服务端返回的证书验签之后的摘要相同，表示证书没有被修改过

f) 验证通过后，就会显示绿色的安全字样

g) 客户端生成随机数，验证通过之后，客户端会生成一个随机数 pre-master secret，客户端根据之前的：Client.random + sever.random + pre-master 生成对称密钥然后使用证书中的公钥进行加密，同时利用前面协商好的 HASH 算法,把握手消息取 HASH 值，然后用 随机数加密 “握手消息+握手消息 HASH 值(签名)” 并一起发送给服务端 (在这里之所以要取握手消息的 HASH 值，主要是把握手消息做一个签名，用于验证握手消息在传输过程中没有被篡改过。)

4. 服务端接收随机数

a) 服务端收到客户端的加密数据以后，用自己的私钥对密文进行解密。然后得到client.random/server.random/pre-master secret, HASH 值，并与传过来的 HASH 值做对比确认是否一致。

b) 然后用随机密码加密一段握手消息(握手消息+握手消息的 HASH 值 )给客户端

5. 客户端接收消息

a) 客户端用随机数解密并计算握手消息的 HASH，如果与服务端发来的 HASH 一致，此时握手过程结束，

b) 之后所有的通信数据将由之前交互过程中生成的pre master secret / client.random/server.random 通过算法得出session Key，作为后续交互过程中的对称密钥

证书介绍

X509

x509协议是定义证书格式的一个标准，我们来看一段官网的介绍：

X.509 是密码学里公钥证书的格式标准。 X.509 证书己应用在包括TLS/SSL（WWW万维网安全浏览的基石）在内的众多 Internet协议里.同时它也用在很多非在线应用场景里，比如电子签名服务。X.509证书里含有公钥、身份信息(比如网络主机名，组织的名称或个体名称等)和签名信息（可以是证书签发机构CA的签名，也可以是自签名）。对于一份经由可信的证书签发机构签名或者可以通过其它方式验证的证书，证书的拥有者就可以用证书及相应的私钥来创建安全的通信，对文档进行数字签名.

另外除了证书本身功能，X.509还附带了证书吊销列表和用于从最终对证书进行签名的证书签发机构直到最终可信点为止的证书合法性验证算法。

证书中一些属性介绍，摘抄下官网的介绍

• Subject/DN - Distinguished Name

The unique identifier for what this thing is. Includes information about the thing being certified,

including common name, organization, organization unit, country codes, etc.

Subject: C=CN, ST=Sichuan, L=Chengdu, O=TW, OU=NA,
CN=test.it/emailAddress=warner.hooh@gmail.com

• CN - Common Name

Common name represents the server name protected by the SSL certificate. After v3 version, it depent on SAN.

• SAN - Subject Alternative Name

The Subject Alternative Name field lets you specify additional host names (sites, IP addresses, common

names, etc.) to be protected by a single SSL Certificate, such as a Multi-Domain (SAN) or Extend

Validation Multi-Domain Certificate.

X509v3 Subject Alternative Name:

 DNS:test.it, DNS:www.test.it

• Fingureprint/Thumbprint

The algorithm of the fingerprint/thumbprint is unrelated to the encryption algorithm of the certificate.

The fingerprint/thumbprint is a identifier used by some server platforms to locate the certificate in a

certificate store.

openssl x509 -noout -fingerprint -sha256 -inform pem -in server.pem
openssl x509 -noout -fingerprint -sha1 -inform pem -in server.pem
openssl x509 -noout -fingerprint -md5 -inform pem -in server.pem
// XXX Fingerprint=E6:5A:5D:37:22:FC:EF:EA:4B:22:92:45:BC:49....

查看证书信息

获取公钥

openssl x509 -noout -pubkey -in certificate.crt

校验证书

openssl verify -verbose -CAfile issuer.pem signed.pem
// signed.pem OK
// The signed.pem can be decrypted by the private key of issuer.pem
// The issuer embeded in signed.pem has to be exactly the same as issuer.pem

证书校验的工作原理

证书链

证书校验的流程：

从上图中我们可以看到，每一个子证书都引用了父级证书，所以校验证书时会逐级向上寻找root证书。如果能找到root证书，并且通过root证书的公钥对子证书进行验签操作成功，说明该终端实体证书就是有效的。而我们的客户端只安装了Root根证书，没有安装中间证书，所以服务器端在传递证书时也需要将中间证书传递过来。

证书部署的顺序：

-----BEGIN CERTIFICATE-----
MII...

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

MII...

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

MII...

-----END CERTIFICATE-----

1. Server证书

2. 中间CA证书1

3. 中间CA证书2

...

n.中间CA证书n-1，当然我们也可以将Root证书也传递过来，这是一个可选的操作。

通过以下命令校验证书是否按照有效

openssl s_client -showcerts -servername www.baidu.com -connect www.baidu.com:443

可以看到，一共三级证书，最顶层的是Root CA，中间的是中间CA证书，最底层的是server证书，并且返回ok状态码，说明证书安装有效

CONNECTED(00000005)
depth=3 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify return:1
depth=2 OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
verify return:1
depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
verify return:1
depth=0 C = CN, ST = beijing, L = beijing, OU = service operation department, O = "Beijing Baidu Netcom Science Technology Co., Ltd", CN = baidu.com
verify return:1
---
Certificate chain
 0 s:/C=CN/ST=beijing/L=beijing/OU=service operation department/O=Beijing Baidu Netcom Science Technology Co., Ltd/CN=baidu.com
   i:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign RSA OV SSL CA 2018
-----BEGIN CERTIFICATE-----
MIIKDzCCCPegAwIBAgIMDJ+O1RK35B2wOSKQMA0GCSqGSIb3DQEBCwUAMFAxCzAJ
BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSYwJAYDVQQDEx1H
bG9iYWxTaWduIFJTQSBPViBTU0wgQ0EgMjAxODAeFw0yMTExMTUwNzU3MDFaFw0y
MjA4MDIwMTE2MDNaMIGnMQswCQYDVQQGEwJDTjEQMA4GA1UECBMHYmVpamluZzEQ
MA4GA1UEBxMHYmVpamluZzElMCMGA1UECxMcc2VydmljZSBvcGVyYXRpb24gZGVw
YXJ0bWVudDE5MDcGA1UEChMwQmVpamluZyBCYWlkdSBOZXRjb20gU2NpZW5jZSBU
ZWNobm9sb2d5IENvLiwgTHRkMRIwEAYDVQQDEwliYWlkdS5jb20wggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSo4ErkmIxyfzun7/JR0Zaalkid6fcdDDA
JwdnMDZwJPJG8mwODAcrVnWTi7u5bEq+9KjiXmkWaleko1gcnz24J8dW6xCQccty
c83p6OdCcQKtyr8jaLYurUCjX6/JdXUHAL6aYFZJO/UCmBaNbjtodTPnizmxiL6P
6YCmEFtBWMwr1d3Ob3djJyCyLjDjtB83k6EzlAelMIiO4OJIZ8ywbj0C7jJYlPr9
Iv01mmu0EIVNnlz21YG30VtHw6qxlSh/6JJc5/0BKnTmrjT8fkT2o5Ig3fB0jBeC
Xr+1pKSDMKzkS05FqkHKVdQNiiMo9lfTrsddohgVl54gl6dtqQZtAgMBAAGjggaP
MIIGizAOBgNVHQ8BAf8EBAMCBaAwgY4GCCsGAQUFBwEBBIGBMH8wRAYIKwYBBQUH
MAKGOGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzcnNhb3Zz
c2xjYTIwMTguY3J0MDcGCCsGAQUFBzABhitodHRwOi8vb2NzcC5nbG9iYWxzaWdu
LmNvbS9nc3JzYW92c3NsY2EyMDE4MFYGA1UdIARPME0wQQYJKwYBBAGgMgEUMDQw
MgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRv
cnkvMAgGBmeBDAECAjAJBgNVHRMEAjAAMD8GA1UdHwQ4MDYwNKAyoDCGLmh0dHA6
Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3Nyc2FvdnNzbGNhMjAxOC5jcmwwggNhBgNV
HREEggNYMIIDVIIJYmFpZHUuY29tghJjbGljay5obS5iYWlkdS5jb22CEGNtLnBv
cy5iYWlkdS5jb22CEGxvZy5obS5iYWlkdS5jb22CFHVwZGF0ZS5wYW4uYmFpZHUu
Y29tghB3bi5wb3MuYmFpZHUuY29tgggqLjkxLmNvbYILKi5haXBhZ2UuY26CDCou
YWlwYWdlLmNvbYINKi5hcG9sbG8uYXV0b4ILKi5iYWlkdS5jb22CDiouYmFpZHVi
Y2UuY29tghIqLmJhaWR1Y29udGVudC5jb22CDiouYmFpZHVwY3MuY29tghEqLmJh
aWR1c3RhdGljLmNvbYIOKi5iYWlmdWJhby5jb22CDyouYmNlLmJhaWR1LmNvbYIN
Ki5iY2Vob3N0LmNvbYILKi5iZGltZy5jb22CDiouYmRzdGF0aWMuY29tgg0qLmJk
dGpyY3YuY29tghEqLmJqLmJhaWR1YmNlLmNvbYINKi5jaHVhbmtlLmNvbYIRKi5j
bG91ZC5iYWlkdS5jb22CCyouZGxuZWwuY29tggsqLmRsbmVsLm9yZ4ISKi5kdWVy
b3MuYmFpZHUuY29tghAqLmV5dW4uYmFpZHUuY29tghEqLmZhbnlpLmJhaWR1LmNv
bYIRKi5nei5iYWlkdWJjZS5jb22CEiouaGFvMTIzLmJhaWR1LmNvbYIMKi5oYW8x
MjMuY29tggwqLmhhbzIyMi5jb22CDCouaGFva2FuLmNvbYIOKi5pbS5iYWlkdS5j
b22CDyoubWFwLmJhaWR1LmNvbYIPKi5tYmQuYmFpZHUuY29tggwqLm1pcGNkbi5j
b22CECoubmV3cy5iYWlkdS5jb22CCyoubnVvbWkuY29tgg8qLnBhZS5iYWlkdS5j
b22CECouc2FmZS5iYWlkdS5jb22CDiouc21hcnRhcHBzLmNugg4qLnN1LmJhaWR1
LmNvbYINKi50cnVzdGdvLmNvbYIRKi52ZC5iZHN0YXRpYy5jb22CEioueHVlc2h1
LmJhaWR1LmNvbYILYXBvbGxvLmF1dG+CDGJhaWZ1YmFvLmNvbYIGZHd6LmNugg9t
Y3QueS5udW9taS5jb22CDHd3dy5iYWlkdS5jboIQd3d3LmJhaWR1LmNvbS5jbjAd
BgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwHwYDVR0jBBgwFoAU+O9/8s14
Z6jeb48kjYjxhwMCs+swHQYDVR0OBBYEFLAoM3yElq58Hh5vTxgNqlmsbxaXMIIB
fgYKKwYBBAHWeQIEAgSCAW4EggFqAWgAdQBvU3asMfAxGdiZAKRRFf93FRwR2QLB
ACkGjbIImjfZEwAAAX0imXfjAAAEAwBGMEQCIFixozqr9OSRxvNvFK3FRVD+SjaZ
JoL0oGq3e6tUEcuiAiBAoUtQNhY05Js/+pru6O2S3zt2nQ2W8j8CZrguOZH4OAB3
ACl5vvCeOTkh8FZzn2Old+W+V32cYAr4+U1dJlwlXceEAAABfSKZd+IAAAQDAEgw
RgIhAPhczPoE28jCB+b1o/Zo6Zn03ar+gKacz9w1oMsU3pvBAiEAsBzpPYgZ+N14
CCGc3j1bBR6fje3SIkjBy5POB4+o+KIAdgBRo7D1/QF5nFZtuDd4jwykeswbJ8v3
nohCmg3+1IsF5QAAAX0imXgHAAAEAwBHMEUCIQDvS2s/xRbw5ENc3u9meK5T8Y8M
P3fGn5ZYXxvMi+UuvwIgVWPjUj8g8LSXON5dR7MsvmYtQSubfHPZ2elcwcG9qBYw
DQYJKoZIhvcNAQELBQADggEBAENPNV988IA1R20NtuNeU1MKeBO3v4q7ER3TGomi
vcEUiGdwmdwXoukaVMQdTVDlKtRaOrcjyRBGyw95Iic0crBCwsepT47aAhcBFezO
NIHMGQD76qPPoVqSB2b3xkFzs+r1PFIdR21p1b4JNpqkNWNeYL4zynjkzfAycadi
qjZRzA66kvZ4/w+nciG6ViEEiycTUc+6ZNCgnMJ7KIzRB67FO9aoP94ix4y/Ovg7
OavWdKL0HS0Ullf+mmA8rWgBrmqjiHIDkaqGHyrsIvh0+uQodVNdQNfHZYhzAMOW
0Ng96W9lY3B/Ye7quginNpuCF08gfCnVJwJlUOgetf9xy2M=
-----END CERTIFICATE-----
 1 s:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign RSA OV SSL CA 2018
   i:/OU=GlobalSign Root CA - R3/O=GlobalSign/CN=GlobalSign
-----BEGIN CERTIFICATE-----
MIIETjCCAzagAwIBAgINAe5fIh38YjvUMzqFVzANBgkqhkiG9w0BAQsFADBMMSAw
HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFs
U2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjAeFw0xODExMjEwMDAwMDBaFw0yODEx
MjEwMDAwMDBaMFAxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52
LXNhMSYwJAYDVQQDEx1HbG9iYWxTaWduIFJTQSBPViBTU0wgQ0EgMjAxODCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKdaydUMGCEAI9WXD+uu3Vxoa2uP
UGATeoHLl+6OimGUSyZ59gSnKvuk2la77qCk8HuKf1UfR5NhDW5xUTolJAgvjOH3
idaSz6+zpz8w7bXfIa7+9UQX/dhj2S/TgVprX9NHsKzyqzskeU8fxy7quRU6fBhM
abO1IFkJXinDY+YuRluqlJBJDrnw9UqhCS98NE3QvADFBlV5Bs6i0BDxSEPouVq1
lVW9MdIbPYa+oewNEtssmSStR8JvA+Z6cLVwzM0nLKWMjsIYPJLJLnNvBhBWk0Cq
o8VS++XFBdZpaFwGue5RieGKDkFNm5KQConpFmvv73W+eka440eKHRwup08CAwEA
AaOCASkwggElMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0G
A1UdDgQWBBT473/yzXhnqN5vjySNiPGHAwKz6zAfBgNVHSMEGDAWgBSP8Et/qC5F
JK5NUPpjmove4t0bvDA+BggrBgEFBQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6
Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMwNgYDVR0fBC8wLTAroCmgJ4Yl
aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBHBgNVHSAEQDA+
MDwGBFUdIAAwNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5j
b20vcmVwb3NpdG9yeS8wDQYJKoZIhvcNAQELBQADggEBAJmQyC1fQorUC2bbmANz
EdSIhlIoU4r7rd/9c446ZwTbw1MUcBQJfMPg+NccmBqixD7b6QDjynCy8SIwIVbb
0615XoFYC20UgDX1b10d65pHBf9ZjQCxQNqQmJYaumxtf4z1s4DfjGRzNpZ5eWl0
6r/4ngGPoJVpjemEuunl1Ig423g7mNA2eymw0lIYkN5SQwCuaifIFJ6GlazhgDEw
fpolu4usBCOmmQDo8dIm7A9+O4orkjgTHY+GzYZSR+Y0fFukAj6KYXwidlNalFMz
hriSqHKvoflShx8xpfywgVcvzfTO3PYkz6fiNJBonf6q8amaEsybwMbDqKWwIX7e
SPY=
-----END CERTIFICATE-----
 2 s:/OU=GlobalSign Root CA - R3/O=GlobalSign/CN=GlobalSign
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
-----BEGIN CERTIFICATE-----
MIIETjCCAzagAwIBAgINAe5fFp3/lzUrZGXWajANBgkqhkiG9w0BAQsFADBXMQsw
CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UECxMH
Um9vdCBDQTEbMBkGA1UEAxMSR2xvYmFsU2lnbiBSb290IENBMB4XDTE4MDkxOTAw
MDAwMFoXDTI4MDEyODEyMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290
IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNp
Z24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2
hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG4VKrDIFHcGzdZNHr9SyjD4I9
DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnLJlkNc96wyOkm
DoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh
BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTv
riBJ/K1AFUjRAjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZp
hYIXAgMBAAGjggEiMIIBHjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB
/zAdBgNVHQ4EFgQUj/BLf6guRSSuTVD6Y5qL3uLdG7wwHwYDVR0jBBgwFoAUYHtm
GkUNl8qJUC99BM00qP/8/UswPQYIKwYBBQUHAQEEMTAvMC0GCCsGAQUFBzABhiFo
dHRwOi8vb2NzcC5nbG9iYWxzaWduLmNvbS9yb290cjEwMwYDVR0fBCwwKjAooCag
JIYiaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LmNybDBHBgNVHSAEQDA+
MDwGBFUdIAAwNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5j
b20vcmVwb3NpdG9yeS8wDQYJKoZIhvcNAQELBQADggEBACNw6c/ivvVZrpRCb8RD
M6rNPzq5ZBfyYgZLSPFAiAYXof6r0V88xjPy847dHx0+zBpgmYILrMf8fpqHKqV9
D6ZX7qw7aoXW3r1AY/itpsiIsBL89kHfDwmXHjjqU5++BfQ+6tOfUBJ2vgmLwgtI
fR4uUfaNU9OrH0Abio7tfftPeVZwXwzTjhuzp3ANNyuXlava4BJrHEDOxcd+7cJi
WOx37XMiwor1hkOIreoTbv3Y/kIvuX1erRjvlJDKPSerJpSZdcfL03v3ykzTr1Eh
kluEfSufFT90y1HonoMOFm8b50bOI7355KKL0jlrqnkckSziYSQtjipIcJDEHsXo
4HA=
-----END CERTIFICATE-----
---
Server certificate
subject=/C=CN/ST=beijing/L=beijing/OU=service operation department/O=Beijing Baidu Netcom Science Technology Co., Ltd/CN=baidu.com
issuer=/C=BE/O=GlobalSign nv-sa/CN=GlobalSign RSA OV SSL CA 2018
---
No client certificate CA names sent
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 5449 bytes and written 344 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: BE2DB749BA96C0D9141EA6D997C0EA40D75F580BB6774A7D5698FB81F96D33F8
    Session-ID-ctx:
    Master-Key: 4F6C61F712EFEF66E9DA466939E930D25E80BD6F23A167EAE57B1090C2579B3753E476735E3D6067C3F145912F50DACF
    TLS session ticket:
    0000 - 35 16 01 68 46 9c 91 e4-7d dd 8d a9 7e 9a b0 60   5..hF...}...~..`
    0010 - 57 d6 8e a4 7b 16 7e e0-1c 15 d9 af f8 57 3e 04   W...{.~......W>.
    0020 - 9f 91 1f f4 8c 82 5d db-67 56 c2 b2 1c e5 ff 34   ......].gV.....4
    0030 - 2d 53 f4 1d 76 00 57 a9-8f df 1c b7 05 a6 97 d0   -S..v.W.........
    0040 - 94 99 fe c3 68 63 6c c8-cb 14 9a eb e3 44 ec 41   ....hcl......D.A
    0050 - a7 30 b0 78 e5 fa e4 38-81 a0 a0 a2 6d c7 75 19   .0.x...8....m.u.
    0060 - 50 59 f9 4f 73 08 a3 b8-0a 9f 54 33 cf 21 20 2f   PY.Os.....T3.! /
    0070 - 9b 85 34 9d d5 98 05 f6-78 88 43 5b 0d c3 a3 80   ..4.....x.C[....
    0080 - 4d 6b ae 15 04 22 c4 14-b9 15 73 08 7e 86 9e 47   Mk..."....s.~..G
    0090 - e0 1a 7e 9d 15 24 04 7d-ba 5c 68 16 ca c0 3d 10   ..~..$.}.\h...=.

    Start Time: 1656675526
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

证书格式

PEM - Privacy Enhanced Mail

格式内容如下：

-----BEGIN CERTIFICATE-----
MIIH0jCCBrqgAwIBAgIQDgl0QXDFncvk0d92JIZVTzANBgkqhkiG9w0BAQsFADBE
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMR4wHAYDVQQDExVE
aWdpQ2VydCBHbG9iYWwgQ0EgRzIwHhcNMjExMDEyMDAwMDAwWhcNMjIxMDExMjM
...
-----END CERTIFICATE-----

• PEM 类型的证书格式有： .pem, .crt, .cer and .key
• 被 ASCII Base64 编码
• 一般适用于Unix server和Apache服务

查看 PEM 格式的证书

openssl x509 -in certificate.pem -text -noout

DER - Distinguished Encoding Rules

DER 格式是 PEM 的二进制格式。

• DER 证书具有 .der、.cer 扩展名

• 它们通常用于 JAVA 服务器

查看 DER certificate

openssl x509 -in certificate.der -inform der -text -noout

PKCS#12 & PFX

PKCS#12 或 PFX 格式以二进制格式编码。这种类型的证书将服务器证书以及中间证书和私钥存储在单个加密文件中。具有 .p12、.pksc#12 或 .pfx 扩展名的证书。您可以将 .pfx 文件的扩展名重命名为 .p12，反之亦然。

• 它们具有 .pfx 和 .p12 扩展名

• 它们通常用于 Microsoft windows 服务器

查看PFX certificate

openssl pkcs12 -nodes -in certificate.pfx

PKCS#7 & P7B

PKCS#7 或 P7B 格式以 ASCII Base64 格式编码。此类证书包含以下内容

-----BEGIN PKCS7-----
MIIH0jCCBrqgAwIBAgIQDgl0QXDFncvk0d92JIZVTzANBgkqhkiG9w0BAQsFADBE
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMR4wHAYDVQQDExVE
aWdpQ2VydCBHbG9iYWwgQ0EgRzIwHhcNMjExMDEyMDAwMDAwWhcNMjIxMDExMjM
...
-----END PKCS7-----

p7B文件的特殊性在于它只包含证书和字符串证书，而不是私钥。

• 它们具有 .p7b 和 .p7c 扩展名

• 它们一般用于Microsoft windows和Java Tomcat服务器。

查看P7B certificate

openssl pkcs7 -print_certs -in certificate.p7b

### 不同证书格式之间的转换

Convert PEM

PEM to DER

openssl x509 -outform der -in certificate.pem -out certificate.der

PEM to P7B

openssl crl2pkcs7 -nocrl -certfile certificate.cer -out certificate.p7b -certfile CACert.cer

PEM to PFX

openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -
certfile CACert.crt

Convert DER

DER(.CRT .CER .DER) to PEM

openssl x509 -inform der -in certificate.cer -out certificate.pem

Convert P7B

P7B to PEM

openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer

P7B to PFX

openssl pkcs12 -export -in certificate.cer -inkey privateKey.key -out certificate.pfx -
certfile CACert.cer

P7B to CER

openssl pkcs7 -print_certs -in certificat-ssl.p7b -out certificat-ssl.cer

Convert PFX

PFX to PEM

openssl pkcs12 -in certificate.pfx -out certificate.cer -nodes

Convert CER

CER TO P7B

openssl crl2pkcs7 -nocrl -certfile certificat-ssl.cer -certfile cert-intermediaire.cer
-certfile cert-racine.cer -out certificat-ssl.p7b

CER TO PFX

openssl pkcs12 -in certificat-ssl.cer -certfile cert-intermediaire.cer -certfile certracine.cer -inkey cle-privee.key -export -out certificat-ssl.pfx

CER TO DER

openssl x509 -in certificat-ssl.cer -outform der -out certificat-ssl.der

https 应用实战

1. Springboot ssl配置实战

2. Nginx ssl配置实战

3. Kafka ssl配置实战