Boost.Asio: 写入 SSL Server/Client 文件类型太多
Boost.Asio: Writing a SSL Server/Client Too many file types
我想使用 Boost.Asio 创建一个简单的 SSL server/client 对。在此之前,我阅读了有关 SSL、证书、私钥、public 密钥等的信息。我使用 OpenSSL 生成私钥 (.key) 和证书 (.crt)。我的证书是自签名的。
然后,我开始挖掘 Boost.Asio 个样本。我首先尝试写一个客户端。在示例中,验证文件是 *.pem 文件。我不知道那是什么。搜索了一下(谷歌搜索 "how to convert crt to pem" 等)后,我发现我的 .crt 文件也是一个 .pem 文件,因为它以 -----BEGIN
开头并以 Base64 编码。
所以我已经完成了编写客户端并使用我的 .crt 文件作为 ctx.load_verify_file()
的参数。这是正确的做法吗?
为了测试我的客户端,我开始写一个服务器。现在我有3种文件,其中2种我不熟悉。他们是:
- 证书链文件
- 私钥文件(我唯一熟悉的)
- 临时dh文件
示例中私钥文件也是*.pem文件,但我的私钥文件是*.key文件。所以我很困惑。我需要做任何转换吗?
你能解释一下吗:
- 什么是*.pem 文件?怎么才能代表私钥和验证呢?
- 什么是证书链文件?
- 什么是临时 dh 文件?
PEM 文件
A PEM file (X.509) 指定一种格式,用于以文本格式表示 public 证书、证书链、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 and PKCS#12。
证书链
证书链是一连串的证书,从头到尾逐步执行,直到找到明确信任的受信任证书颁发机构 (CA) 的证书。
- 链的开头包含最终用户证书。这是颁发给正在建立连接的服务器的证书。受信任的或中间 CA 可能已颁发此证书。
- 链的开始和结束之间可能有很多中间证书。这些颁发给中间 CA,并由不同的中间 CA 或受信任的 CA 颁发。
- 链的末尾包含根证书。这是由受信任的 CA 颁发给自己的。可信 CA 的证书通常随 Web 浏览器和操作系统一起分发。
例如,考虑 example.com
是否已由 alpha
中间 CA 颁发证书; alpha
已由 bravo
中间 CA 颁发证书;并且 bravo
已由受信任的 charlie
CA 颁发证书,其证书已与您的网络浏览器包一起分发。用这个例子,验证是:
- 最终用户
example.com
证书是否有 alpha
作为其颁发者?
example.com
证书是否使用 alpha
的密钥进行验证?
alpha
的中间证书是否有 bravo
作为其颁发者?
alpha
的证书是否使用 bravo
的密钥进行验证?
bravo
的中间证书是否有 charlie
作为其颁发者?
bravo
证书与charlie
的密钥是否一致?
charlie
的根证书是否有 charlie
作为其颁发者?
- 所提供的
charlie
证书是否与先前作为可信 CA 安装在系统上的 charlie
证书进行验证?
DH 文件
DH 文件包含 Diffie-Hellman key exchange, an algorithm for exchanging keys over a public channel while providing perfect forward secrecy 的初始化值。该算法使两方能够生成共享密钥,同时最大限度地减少看到整个交换的观察者将生成相同密钥的变化。参数生成可能很昂贵,因此通常提前完成一次并重复用于多次密钥交换。
有关详细信息,请参阅 openssl Diffie Hellman 条目。
我想使用 Boost.Asio 创建一个简单的 SSL server/client 对。在此之前,我阅读了有关 SSL、证书、私钥、public 密钥等的信息。我使用 OpenSSL 生成私钥 (.key) 和证书 (.crt)。我的证书是自签名的。
然后,我开始挖掘 Boost.Asio 个样本。我首先尝试写一个客户端。在示例中,验证文件是 *.pem 文件。我不知道那是什么。搜索了一下(谷歌搜索 "how to convert crt to pem" 等)后,我发现我的 .crt 文件也是一个 .pem 文件,因为它以 -----BEGIN
开头并以 Base64 编码。
所以我已经完成了编写客户端并使用我的 .crt 文件作为 ctx.load_verify_file()
的参数。这是正确的做法吗?
为了测试我的客户端,我开始写一个服务器。现在我有3种文件,其中2种我不熟悉。他们是:
- 证书链文件
- 私钥文件(我唯一熟悉的)
- 临时dh文件
示例中私钥文件也是*.pem文件,但我的私钥文件是*.key文件。所以我很困惑。我需要做任何转换吗?
你能解释一下吗:
- 什么是*.pem 文件?怎么才能代表私钥和验证呢?
- 什么是证书链文件?
- 什么是临时 dh 文件?
PEM 文件
A PEM file (X.509) 指定一种格式,用于以文本格式表示 public 证书、证书链、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 and PKCS#12。
证书链
证书链是一连串的证书,从头到尾逐步执行,直到找到明确信任的受信任证书颁发机构 (CA) 的证书。
- 链的开头包含最终用户证书。这是颁发给正在建立连接的服务器的证书。受信任的或中间 CA 可能已颁发此证书。
- 链的开始和结束之间可能有很多中间证书。这些颁发给中间 CA,并由不同的中间 CA 或受信任的 CA 颁发。
- 链的末尾包含根证书。这是由受信任的 CA 颁发给自己的。可信 CA 的证书通常随 Web 浏览器和操作系统一起分发。
例如,考虑 example.com
是否已由 alpha
中间 CA 颁发证书; alpha
已由 bravo
中间 CA 颁发证书;并且 bravo
已由受信任的 charlie
CA 颁发证书,其证书已与您的网络浏览器包一起分发。用这个例子,验证是:
- 最终用户
example.com
证书是否有alpha
作为其颁发者? example.com
证书是否使用alpha
的密钥进行验证?alpha
的中间证书是否有bravo
作为其颁发者?alpha
的证书是否使用bravo
的密钥进行验证?bravo
的中间证书是否有charlie
作为其颁发者?bravo
证书与charlie
的密钥是否一致?charlie
的根证书是否有charlie
作为其颁发者?- 所提供的
charlie
证书是否与先前作为可信 CA 安装在系统上的charlie
证书进行验证?
DH 文件
DH 文件包含 Diffie-Hellman key exchange, an algorithm for exchanging keys over a public channel while providing perfect forward secrecy 的初始化值。该算法使两方能够生成共享密钥,同时最大限度地减少看到整个交换的观察者将生成相同密钥的变化。参数生成可能很昂贵,因此通常提前完成一次并重复用于多次密钥交换。
有关详细信息,请参阅 openssl Diffie Hellman 条目。