我想使用 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 文件?
最佳答案
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 浏览器包一起分发。对于这个例子,验证是:
- 最终用户
example.com
证书的颁发者是否为alpha
? example.com
证书是否使用alpha
的 key 进行验证?alpha
的中间证书是否有bravo
作为其颁发者?alpha
的证书是否使用bravo
的 key 进行验证?bravo
的中间证书是否有charlie
作为其颁发者?bravo
证书与charlie
的 key 是否一致?charlie
的根证书是否以charlie
作为其颁发者?- 所提供的
charlie
证书是否根据先前作为可信 CA 安装在系统上的charlie
证书进行验证?
DH文件
DH 文件包含 Diffie-Hellman key exchange 的初始化值,一种在提供 perfect forward secrecy 的同时通过公共(public) channel 交换 key 的算法.该算法使两方能够生成共享 key ,同时最大限度地减少看到整个交换的观察者将生成相同 key 的变化。参数生成可能代价高昂,因此通常提前完成一次并重复用于多次 key 交换。
参见 openssl Diffie Hellman进入了解更多详情。
关于c++ - boost .Asio : Writing a SSL Server/Client Too many file types,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/32036730/