供内部使用的 SSL 签名证书
我有一个分布式应用程序，由许多通过 TCP（例如 JMS）和 HTTP 进行通信的组件组成。所有组件都在具有内部 IP 地址的内部硬件上运行，并且公众无法访问。
我想使用 SSL 确保通信安全。从知名证书颁发机构购买签名证书是否有意义？或者我应该只使用自签名证书？
我对可信证书优势的理解是，权威机构是一个可以被公众信任的实体——但这只是当公众需要确保特定域的实体就是他们所说的人时的问题。是。
因此，就我而言，如果同一组织负责通信两端的组件以及中间的所有内容，那么公众信任的权威机构将毫无意义。换句话说，如果我为自己的服务器生成并签署证书，我就知道它是值得信赖的。并且组织外部的任何人都不会被要求信任此证书。这是我的推理 - 我是否正确，或者使用已知权威机构的证书是否有一些潜在的优势？
I have a distributed application consisting of many components that communicate over TCP (for examle JMS) and HTTP. All components run on internal hardware, with internal IP addresses, and are not accessible to the public.
I want to make the communication secure using SSL. Does it make sense to purchase signed certificates from a well-known certificate authority? Or should I just use self-signed certs?
My understanding of the advantage of trusted certs is that the authority is an entity that can be trusted by the general public - but that is only an issue when the general public needs to be sure that the entity at a particular domain is who they say they are.
Therefore, in my case, where the same organization is responsible for the components at both ends of the communication, and everything in between, a publicly trusted authority would be pointless. In other words, if I generate and sign a certificate for my own server, I know that it's trustworthy. And no one from outside the organization will ever be asked to trust this certificate. That is my reasoning - am I correct, or is there some potential advantage to using certs from a known authority?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
对于封闭社区项目，您无需使用外部公共 CA。在许多大型组织中，他们运营内部 PKI 来为此类内部项目颁发证书。使用 PKI 的优点是您可以基于单个安全分发的根证书/信任锚在各个组件之间建立信任关系。
但是，如果项目允许内部用户通过 Web 浏览器安全连接到内部服务，您可能需要考虑使用公共 CA 颁发的证书。另一种方法是确保每个可能需要连接到您的服务的浏览器都信任您的根证书；这是为了防止浏览器出现警告消息。
There is no need for you to use an external public CA for a closed community project. In many larger organisations they operate an internal PKI to issue certs for internal projects like this. An advantage of using a PKI is that you can setup a trust relationship between the various components based on a single securely distributed root certificate / trust anchor.
However, if the project allowed internal users to connect securely to an internal service via their web browser you may want to consider using a public CA issued cert. The alternative is to make sure that every browser that may need to connect to your service trusted your root cert; this is to prevent browser warning messages.
我想说这是相当安全的，除非你认为忍者渗透者会交换你的服务器。
第三方的存在是为了让“起来”变得更加困难。生成'一个新的证书。有人可以在具有相同详细信息的新计算机上重新创建自签名证书，它不会是相同的证书，您也必须为其添加例外，但您的用户可能不会知道其中的区别。
I'd say it's reasonably safe, unless you think a ninja infiltrator is going to swap your server on you.
The 3rd party is there to make it harder to just 'up & generate' a new cert. Someone could re-create a self-signed cert on a new machine with the same details, it wouldn't be the same cert, you'd have to add an exception for it too, but your users probably wouldn't know the difference.
只要您的系统在您的组内运行并且没有计划对其进行扩展（并且计划确实会发生变化，因此请记住这一点），那么设置您自己的简单 PKI 基础设施就可以了。
如果您最终扩展到组织之外，您所需要做的就是将根证书分发给您将通信的各方。这实际上为您的合作伙伴提供了细粒度的控制，他们希望对您与公共 CA 基础设施给予多少信任。
As long as your system is running inside your group and there are no plans to expand it (and plans do change, so keep that in mind), it is just fine to setup your own simple PKI infrastructure.
If you do end up expanding beyond your organization, all you need to do is distribute your root certificate to the parties you will be communicating. This gives actually a fine grained control to your partners how much trust they want to put in you vs the public CA infrastructure.