在微服务内部通信情况下签发SSL证书主机名

Question

我必须使用SSL确保微服务内部通信的安全。我所有的微服务都是spring引导应用程序，在这里我们使用zookeeper作为发现服务器。内部服务通信通过rest模板和虚拟客户端进行。我们使用丝带作为客户端负载平衡器。我们已经在所有微服务中设置了以下属性

spring.application.name=Application1
spring.cloud.zookeeper.discovery.enabled=true
spring.cloud.zookeeper.connectString=localhost:2181
spring.cloud.zookeeper.enabled=true
server.port=7800
spring.cloud.zookeeper.discovery.instance-ssl-port=7801

server.ssl.enabled=true
server.ssl.key-store-type=JKS
server.ssl.key-store=classpath:LP-PF1HMVQU.jks
server.ssl.key-store-password=123456
server.ssl.key-alias=LP-PF1HMVQU
server.ssl.protocol=TLS

我们必须使用自签名的证书，我已经生成了相同的证书，并将certicate导入到JRE信任存储以使通信成为可能(SSL握手)。这里的问题是，我必须将证书的CN与系统主机名(LP-PF1HMVQU)保持相同。这是因为当服务在动物园管理员注册时，它会存储机器名或主机名作为其地址，并且在握手过程中也会重新处理。

在动物园管理员注册的服务

{"name":"employee-service","id":"b4c2204a-b00c-4102-b609-17d7f73f35d7","address":"LP-PF1HMVQU","port":7800,"sslPort":null,"payload":{"@class":"org.springframework.cloud.zookeeper.discovery.ZookeeperInstance","id":"application-1","name":"employee-service","metadata":{}},"registrationTimeUTC":1564658801106,"serviceType":"DYNAMIC","uriSpec":{"parts":[{"value":"scheme","variable":true},{"value":"://","variable":false},{"value":"address","variable":true},{"value":":","variable":false},{"value":"port","variable":true}]}}

现在，在生产中，我们将为每个服务提供一个码头容器，每个服务可以有多个码头容器。这些码头集装箱向动物园管理员注册，并保留集装箱的IP地址.

我应该如何创建证书，CN名称应该是什么，以便它与任何IP地址相匹配。我尝试了通配符*作为CN的名称，但它没有工作。

请建议如何实现这一目标。

Answer 1

CN的名称应该是什么，这样它才能匹配任何IP地址。

不要那样做，它不会起作用(如预期的那样)

HTTPS和IP地址

虽然技术上您可以在HTTPS中有一个IP地址，比如https://192.0.2.42/whatever，但是它只会给您带来麻烦，因为附加到它的证书需要提到该IP，而不是一个名称，因为没有。从技术上讲，这是可能的(参见https://1.1.1.1/交付的证书)，只是更难/不符合标准情况。

因此，我建议您注册任何您想要的域名，然后使用它作为您所有需要的后缀。如果名称是可公开解析的，您甚至可以为它们获得DV证书。如果没有，您可能需要自己设置一个私有CA。

你还说：

证书的CN与我的系统主机名相同(LP-PF1HMVQU)

这是奇怪的，因为它不是一个全名，当然也不能解决，所以没有CA会同意签署这类证书。如果这确实是您想要的(但请参阅下面)，您将需要您自己的私有CA。

CN和SAN

第一个证书只有一个"Subject“部分，您可以在其中放置一个DN对象，即对某个实体的X.400描述，该实体要么是个人，要么是组织之类的抽象实体、电子邮件地址或网站主机名。

因此，最初我们让网站主机名作为主题中的CN组件，浏览器与之匹配。

但是很快就需要为多个名称提供一个证书，从"root“和"www”二元性开始，因此创建了一个扩展: Subject Alternative Name。

在那里，人们可以放置其他名称(或IP地址，我们将在下面看到)。如今，浏览器(以及更一般的HTTP客户端)大多忽略主题中的内容，因此CN只关注"SAN“部分。

所以这就是你需要放置IP地址的地方。

让我们再看一看https://1.1.1.1/提供的证书。您可以在其中看到主题部分的以下内容：

CN = cloudflare-dns.com
O = "Cloudflare, Inc."
L = San Francisco
ST = California
C = US

对桑人来说：

Not Critical
DNS Name: cloudflare-dns.com
DNS Name: *.cloudflare-dns.com
DNS Name: one.one.one.one
IP Address: 1.1.1.1
IP Address: 1.0.0.1
IP Address: 162.159.132.53
IP Address: 2606:4700:4700::1111
IP Address: 2606:4700:4700::1001
IP Address: 2606:4700:4700::64
IP Address: 2606:4700:4700::6400
IP Address: 162.159.36.1
IP Address: 162.159.46.1

因此，如果您真的希望在证书中有IP地址，那么您需要这样做。如果您自己管理CA，那么在技术上它并不是一个大问题(您需要确保使用

完整的详细信息(规范)都在https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.6上，您可以在这里和其他地方找到许多关于如何使用IP地址所需SAN扩展来构建适当的CSR/证书的说明。

请注意，您可以在SAN中为域名设置通配符，如*.example.com，但对于IP地址则不能使用它们。所以你的“它匹配任何IP地址”似乎不是一个目标。看起来您可能需要一个空白的证书来绕过身份验证并使您的系统正常工作？如果是这样的话，不要这样做并放弃这个想法:没有身份验证的TLS与纯文本一样糟糕，即使交换是加密的，因为您也不知道自己在加密谁。