c++ - boost .Asio : Writing a SSL Server/Client Too many file types

Question

我想使用 Boost.Asio 创建一个简单的 SSL 服务器/客户端对。在此之前，我阅读了有关 SSL、证书、私钥、公钥等的信息。我使用 OpenSSL 生成私钥 (.key) 和证书 (.crt)。我的证书是自签名的。

然后，我开始挖掘 Boost.Asio 样本。我首先尝试写一个客户端。在示例中，验证文件是 *.pem 文件。我不知道那是什么。搜索了一下(谷歌搜索“如何将 crt 转换为 pem”等)后，我发现我的 .crt 文件也是一个 .pem 文件，因为它以 -----BEGIN 开头并编码为Base64。

所以我已经完成了客​​户端的编写，并使用我的 .crt 文件作为 ctx.load_verify_file() 的参数。这是适当的做法吗？

为了测试我的客户端，我已经开始编写一个服务器。现在我有3种文件，其中2种我不熟悉。它们是:

• 证书链文件
• 私钥文件(我唯一熟悉的)
• 临时dh文件

在示例中，私钥文件也是一个 *.pem 文件，但我的私钥文件是一个 *.key 文件。所以我很困惑。我需要进行任何转换吗？

那么你能解释一下吗:

• 什么是*.pem 文件？它如何表示私钥以及验证？
• 什么是证书链文件？
• 什么是临时 dh 文件？

Answer 1

PEM文件

A PEM file (X.509) 规定了以文本格式表示公共(public)证书、证书链、公钥等的格式。它可以有各种扩展名(.cert、.key、.pem 等)。每个项目都在页眉和页脚之间进行 base64 编码:

-----BEGIN <item type>-----
item data
-----END <item type>-----

例如，Boost.Asio SSL 示例的 server.pem文件包含:

-----BEGIN CERTIFICATE-----
MIIB/jCCAWcCCQDlADUqOr8YCTANBgkqhkiG9w0BAQUFADA7MQswCQYDVQQGEwJB
VTEMMAoGA1UECBMDTlNXMQ8wDQYDVQQHEwZTeWRuZXkxDTALBgNVBAoTBGFzaW8w
... more lines ...
WuB94G/gtST9ECVHRKUuBn4xT1rz5DO20h3VSAzTirkSFQPdWunyBbIva0Hsf6pF
287CA1cM106X0Vs4dv2F2u0zSszYfOysAM1pIPcxdyboXA==
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,9A7CF9C13224C492

w00sJ2/d79LRI+9LRsnQkBZwIo/NbprFtN3SVqcUAtncqowl9BnKZnQ2csnj8KZA
STAL+PZAyJQTiJfJxecCkB8Tu4/apFe2V9/PxUirJzGtJ9FHBAjLgmpK4yWwSCMq
... more lines ...
G+psOVLNgCnFh+z4NO5CB4mVNtrR1NAH6IFhnlrip4YFRk3XPHVlkrxn6fHeEDGE
eVB3XJcgsGnVQCvF5vsymZWZ722xgLPkK8iG3QLayoM4c9RlrKMwwA==
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIIB7TCCAVYCCQCxKhAUH1ygCDANBgkqhkiG9w0BAQUFADA7MQswCQYDVQQGEwJB
VTEMMAoGA1UECBMDTlNXMQ8wDQYDVQQHEwZTeWRuZXkxDTALBgNVBAoTBGFzaW8w
... more lines ...
mQK2WeH6DVQ1r7fWqEq1Lq10qBdobbjDRE9jpezWdGMThbYtle6/8wHUJeq189PR
XwZWyRvnfcI+pqX832yNRh24Ujwuv3wlx3JOVByybCoJc05N1THaHo0Q7j//8HsX
VS/RFHuq3muy47cV9gbsCIw=
-----END CERTIFICATE-----

请注意，还有其他方式可以提供证书，例如 PKCS#7和 PKCS#12 .

---

证书链

证书链是一连串的证书，从头到尾逐步执行，直到找到明确信任的可信证书颁发机构 (CA) 的证书。

• 链的开头包含最终用户证书。这是颁发给正在建立连接的服务器的证书。受信任的或中间 CA 可能已颁发此证书。
• 链的开始和结束之间可能有许多中间证书。这些颁发给中间 CA，并由不同的中间 CA 或受信任的 CA 颁发。
• 链的末端包含根证书。这是由受信任的 CA 颁发给自己的。可信 CA 的证书通常随网络浏览器和操作系统一起分发。

例如，考虑 example.com 是否已由 alpha 中间 CA 颁发证书； alpha 已被bravo 中间CA颁发证书； bravo 已获得受信任的 charlie CA 颁发的证书，其证书已与您的 Web 浏览器包一起分发。对于这个例子，验证是:

1. 最终用户 example.com 证书的颁发者是否为 alpha？
2. example.com 证书是否使用 alpha 的 key 进行验证？
3. alpha 的中间证书是否有 bravo 作为其颁发者？
4. alpha 的证书是否使用 bravo 的 key 进行验证？
5. bravo 的中间证书是否有 charlie 作为其颁发者？
6. bravo 证书与charlie 的 key 是否一致？
7. charlie 的根证书是否以 charlie 作为其颁发者？
8. 所提供的 charlie 证书是否根据先前作为可信 CA 安装在系统上的 charlie 证书进行验证？

---

DH文件

DH 文件包含 Diffie-Hellman key exchange 的初始化值，一种在提供 perfect forward secrecy 的同时通过公共(public) channel 交换 key 的算法.该算法使两方能够生成共享 key ，同时最大限度地减少看到整个交换的观察者将生成相同 key 的变化。参数生成可能代价高昂，因此通常提前完成一次并重复用于多次 key 交换。

参见 openssl Diffie Hellman进入了解更多详情。