SSL/TLS证书中的IP地址通配符 [英] IP-address wildcard in SSL/TLS certificates

问题描述

用于保护网站安全的SSL/TLS证书允许指定子域通配符:

The SSL/TLS certificates used to secure websites allow for specifying a subdomain wildcard:

• *.example.com 将对 www.example.com 有效，subdomain.example.com等.

• *.example.com will be valid for www.example.com, subdomain.example.com etc.

是否可以对IP地址使用通配符?特别是，我想要这样的本地开发SSL证书:

Is it possible to use wildcards for IP-addresses? In particular, I want an SSL-certificate for local development like this:

• 192.168.1.* ，它将对我的WiFi路由器的NAT网络内部可访问的256个不同IP地址中的任何一个有效.

• 192.168.1.*, which would then be valid for any of the 256 different IP-addresses that are reachable inside the NAT-network of my WiFi router.

代替仅使用 localhost ， 127.0.0.1 ， 0.0.0.0 ， :: 1 我的证书名称，我还希望能够连接手机以测试网站的开发版本，该网站的版本为 192.168.1.40 .但是随后，同一证书无法从另一台开发机器上重复使用-因为它将在同一网络上获得不同的IP.

Instead of just using localhost, 127.0.0.1, 0.0.0.0, ::1 as alternate names for my certificate, I also want to be able to connect my mobile phone to test the development version of my website which would be available at lets say 192.168.1.40. But then the same certificate could not be reused from a different development machine - since it would get a different IP on the same network.

我们不支持使用IP地址进行加密-这意味着我将改为使用自签名或本地信任的证书.

Let's encrypt doesn't support using IP-addresses - which means I would instead use self-signed or locally trusted certificates instead.

推荐答案

否. RFC 2818第3.1 部分为dNSName项目指定了通配符匹配；尽管此处不清楚，但普遍实现了此功能，以允许仅将通配符用作最左边的DNS标签，这是最不重要的，因为DNS名称是从右到左的.它指定如果使用iPAddress，则匹配必须是精确的(没有通配符)，并且即使允许通配符也是如此，因为IP地址是从左到右的，因此只有右侧的通配符(如您建议的通配符)才有用.

No. RFC 2818 section 3.1 specifies wildcard matching for dNSName items; although it isn't clear here, this is universally implemented to allow the wildcard only as the leftmost DNS label, which is the least significant because DNS names are right-to-left. It specifies that if iPAddress is used the match must be exact (no wildcard), and even if it allowed wildcard, because IP addresses are left-to-right, only a wildcard at the right, like the one you proposed, would be useful.

但是，如果您像大多数人一样仅使用/24的192.168.x.0或更小值，并且可能仅使用该范围内的某些地址，则不难列出所有所需的地址在证书中.例如，如果您使用的是 DHCP分配的地址，则这些地址通常仅占网络掩码名义上可用范围的一半或更少.

However, if you're only using a /24 of 192.168.x.0 or less, as many people do, and likely only some of the addresses in that range, it's not hard to just list all the addresses you need in the cert. For example, if you're using DHCP-assigned addresses, often those cover only half or less of the range nominally available from the netmask.

否在CA/Browser论坛规则下运行的CA，因此为主要浏览器所接受，将为私有(RFC 1918)地址颁发证书；请参见 https://wwww.cabforum.org 的基准要求.出于相同的原因，他们也不会像 .local .localdomain .dev .test 这样的本地或假"域名.

No CA operating under CA/Browser forum rules, and thus acceptable to major browsers, will issue a cert for a private (RFC 1918) address; see the Baseline Requirements at https://wwww.cabforum.org . They won't do local or 'fake' domainnames like .local .localdomain .dev .test either, for the same reason.

BTW 127.0.0.1和:: 1是真实地址，尽管不可路由，因此只能在本地使用.0.0.0.0和:: 0不同；它们根本不是地址，您不能对其进行 connect()；实际上，它们用于表示未连接的状态.您可以 在 bind()中使用它们，但这实际上意味着绑定到所有配置的地址(和接口).

BTW 127.0.0.1 and ::1 are real addresses, albeit not routable and thus usable only locally. 0.0.0.0 and ::0 are different; they aren't addresses at all, and you can't connect() to them; in fact they are used to represent the state of not being connected. You can use them in bind() but that actually means bind to all configured addresses (and interfaces).

这篇关于SSL/TLS证书中的IP地址通配符的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！