SSL 客户端如何验证服务器的证书？
我正在构建一个应用程序，并计划使用 OpenSSL 来保护数据传输。
我计划只让客户端验证服务器的证书。 我对如何保护服务器的证书感到困惑。 我想加密包含私钥的服务器证书，但我不想使用任何硬编码密钥进行此加密。
采用 SSL 的应用程序遵循哪些常见做法？
I am building an application and I am planning on using OpenSSL for securing data transfers.
I am planning on only having the client validate the server's certificate. I am confused on how I should secure the server's certificate. I would like to encrypt the server's certificate containing the private key, but I do not want to use any hard coded keys for this encryption.
What are some of the common practices followed by applications employing SSL?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
为了确保我们理解术语，通常所说的“SSL 证书”实际上由两个组件组成：
公共证书组件由您选择的 CA（证书颁发机构）签名，之后它可以可以自由分发。 它不需要保护或加密，实际上它会作为 SSL 协商的一部分发送到连接到您的服务器的客户端。
私钥组件应该受到保护。 在大多数情况下，这只是作为加密文件存储在服务器上。 高档解决方案使用专用的“防篡改”加密硬件（HSM——硬件安全模块）来存储私钥。 这些范围从基于智能卡的解决方案到具有 m/n 控制的多密钥、支持网络的设备等。与 HSM 相关的风险（更不用说成本）在这里我不会讨论。
许多应用程序只是将私钥保留在磁盘上。 有几个选项可以保护密钥文件：
一如既往，存在安全权衡。 特别是，如果您对私钥文件使用受密码保护的加密，并且遇到应用程序意外重启（例如断电），则需要有人在应用程序重新启动时向其提供密码。 将密码存储在由系统初始化脚本读取的文件中（正如至少两个 Web 服务器供应商所鼓励的那样）在真正的安全性方面几乎没有增加。 很难建议不加密私钥文件，但如果您是一家小商店的唯一管理员/技术人员，您绝对应该考虑如果服务器在您不可用时重新启动会发生什么，以及您的企业可能会付出什么代价。
Just to make sure we have our terminology straight, an "SSL certificate" in common parlance is really composed of two components:
The public certificate component is signed by your chosen CA (certificate authority), after which it can be freely distributed. It does not need to be secured or encrypted, and indeed it will be sent to clients that connect to your server as part of the SSL negotiation.
The private key component should be protected. In the majority of cases, this is simply stored as an encrypted file on the server. Upscale solutions use dedicated "tamperproof" crypto hardware (HSMs -- hardware security modules) to store the private key. These range from smart-card based solutions to multi-key, network enabled appliances with m/n controls etc etc. There are risks (not to mention costs) associated with HSMs that I will not go into here.
Many applications simply retain the private key on disk. There are a couple of options to secure the key file:
As always, there is a security trade-off. In particular, if you are using password-protected encryption on the private key file and you experience an unexpected application restart (eg power outage), then somebody will need to be available to provide the password to the app as it restarts. Storing the password in a file that is read by system initialization scripts (as encouraged by at least two web server vendors) adds little in terms of real security. It's hard to recommend leaving the private key file unencrypted but if you are the sole admin/techy in a small shop, you should definitely consider what might happen if the server reboots when you are not available, and what the costs might be to your business.
不太确定你想问什么。 服务器证书发送给您（客户端）； 您通过检查签名来验证证书（使用 SHA-1 而不是 MD5，MD5 已被破解。）您从 CA 获得的密钥是公共端； CA 和服务器证书持有者自行保管私钥。 您可以验证证书，因为公钥足以解密已使用私钥加密的消息。 因此，从科学的角度来看，您根本不必担心证书的加密问题。
请参阅有关 SSL/TLS 的维基百科文章。
not quite sure what you're trying to ask. the server cert is sent to you, the client; you validate the cert by checking its signature (use SHA-1 not MD5, MD5 has been cracked.) The key you have from the CA is the public side; the CA and the server cert holder keep their private keys to themselves. You can validate the cert because the public key is enough to decrypt a message that has been encrypted with the private key. So you don't have to worry, on the cient side, about keeping the cert encrypted at all.
Have a look at the Wikipedia article on SSL/TLS.
您不必保护服务器的证书。 这是一份公开文件
服务器的证书不包含私钥。
您不需要进行任何加密。 您需要保护的唯一服务器资产是其私钥，它与其证书完全不同。 对于 OpenSSL，它甚至可以是不同的文件。
You don't have to secure the server's certificate. It's a public document
The server's certificate does not contain the private key.
You don't need to do any encryption. The only server asset you need to protect is its private key, which is entirely distinct from its certificate. In the case of OpenSSL it can even be a different file.