Ssl 如何在微服务之间实现TLS

有人能对我正在考虑的微服务安全设计进行评论、审查、评论或其他方面的漏洞吗

假设我有三个微服务，每一个都通过REST端点与另外两个进行通信。每个微服务都包含一个密钥库。该密钥库中包含由可信证书颁发机构签名的微服务的私钥/公钥对。该密钥库中还有另外两个微服务的公钥证书，它们是从源微服务的签名/受信任密钥对导出的

这个实现是可行的，但它的某些地方不太对劲

也就是说，每次我引入一个新的微服务时，我必须将a）每个现有微服务的公钥证书添加到其密钥库中，以及b）新微服务的公钥证书添加到每个其他微服务中（假设新微服务必须与每个现有微服务进行双向安全通信）

现在，对第二个密钥对重复上述模式，该密钥对用于对REST调用中提供的身份验证令牌进行签名/验证

我想知道，在所有微服务之间共享单个可信公钥证书是否是a）明智的，b）安全的，而不是上面提到的？完全不同的东西

请有礼貌。我决不是这方面的专家

编辑： 在阅读了对我的原始帖子的回复/评论后，我突然想到，我忽略了可能使问题更清楚的细节，因此评论者能够更好地解决这个问题：

所讨论的微服务存在于私有intranet中，并且只有该intranet中的客户端（浏览器或其他微服务）才能访问

事实上，有一个受信任的CA，即拥有此intranet的公司，正是该CA签署了微服务的密钥对

这个问题的解决方案似乎隐含在@Andreas first评论中，他在评论中写道，“只要发行它们的CA是可信的，它们也将是可信的。”

只要每个新的微服务部署有a）自己的密钥对，由CA签名（一个用于签名，另一个用于加密），以及b）CA的证书，我就可以合理地保证部署新的微服务，它们将与所有其他微服务安全通信（合理，因为我甚至不知道其他潜在的漏洞）

不知怎的，我突然想到，我必须为每个微服务的密钥对创建一个全新的证书，并将这些证书包含在其他微服务的密钥库中（对每个新的微服务重复）。相反，我所需要的只是一个证书，即在每个微服务的密钥库中签署密钥对的CA证书。

一种方法是这样做的（您的问题很广泛，没有代码，可能更多的是关于软件工程的主题，而不是这里），如下所示：

创建自己的CA

（可选，仅为您的微服务创建子CA）

通过此CA生成所有证书

使您的代码信任来自此CA的所有证书，而不是检查证书本身（但仍应检查日期、正确的签名等）

这样，当您引入一个新的微服务时，您只有一个要为其生成的证书，而其他微服务中没有要更改的内容，这是您需要达到的目标，否则它将无法管理

通过这样做，您甚至可以根据需要将一些微服务移到系统之外，它们只需附带CA公钥即可

我建议不要对不同的微服务重复使用相同的证书，因为这只会导致问题

另外，松散相关，但请务必阅读以下内容： 它显示了在web之外使用TLS时的各种陷阱。这是一个令人大开眼界的问题。虽然该Internet草案（）仅针对TLS而不是PKI问题，但它可以提供关于如何正确实施TLS1.2的有用见解，并提供一些安全的默认选择。“LTS”部分具体表示“长期支持”

---

再看看这个相关的问题：答案会给你其他的想法，比如使用保险库。

如果你的微服务没有暴露在网络上，那么你可以为此目的创建自签名证书。自签名证书用于内部调用。你可以在sslshopper网站上创建它们

此外，不要对所有微服务使用相同的证书。 我已经实施了类似的解决方案，在我们的案例中，我们已经将签名服务设置为另一个微服务，该微服务将满足其他微服务。该自签名服务将连接到HSM或硬件安全模块。所有证书都存储在属于配置文件的HSM中。您可以在HSM和it配置文件创建上进行一些谷歌搜索

---

信任存储库用于保存公共证书，密钥存储库用于存储私钥。这是标准的，不是通用的，但在理想情况下是这样的。

为什么需要添加每个服务公共证书？只要颁发证书的CA是可信的，它们也会是可信的。这就是web本身的工作方式，为什么不呢为您工作？感谢您使用了TLS，而不是其他所有人都错误使用的东西，但请将其从标记中删除。还有java和tls1.2，因为您的问题不是针对这些情况的。@Andreas当您需要对客户端进行身份验证时，这不起作用（对服务器进行身份验证很容易）。服务器需要事先了解一点有关证书的信息，或者使用专用PKI，否则任何人都可以提供任何CA签署的证书。如果可以，请依靠基础结构提供安全通信。例如，如果使用Docker Swarm，则可以激活网络的连接加密：@ConstantinGalbenu encr埃及不是相互认证哇，谢谢你的链接。不能