是的，可以发行。

幸运的是，普通浏览器不接受 TLD 的通配符证书。

铬源代码：

// Do not allow wildcards for public/ICANN registry controlled domains -
// that is, prevent *.com or *.co.uk as valid presented names, but do not
// prevent *.appspot.com (a private registry controlled domain).
// In addition, unknown top-level domains (such as 'intranet' domains or
// new TLDs/gTLDs not yet added to the registry controlled domain dataset)
// are also implicitly prevented.
// Because |reference_domain| must contain at least one name component that
// is not registry controlled, this ensures that all reference domains
// contain at least three domain components when using wildcards.
size_t registry_length =
    registry_controlled_domains::GetCanonicalHostRegistryLength(
        reference_name,
        registry_controlled_domains::INCLUDE_UNKNOWN_REGISTRIES,
        registry_controlled_domains::EXCLUDE_PRIVATE_REGISTRIES);

// ... [SNIP]

// Account for the leading dot in |reference_domain|.
bool is_registry_controlled =
    registry_length != 0 &&
    registry_length == (reference_domain.size() - 1);

// Additionally, do not attempt wildcard matching for purely numeric
// hostnames.
allow_wildcards =
    !is_registry_controlled &&
    reference_name.find_first_not_of("0123456789.") != std::string::npos;
}

Google 禁止的域的完整列表位于 net/base/registry_controlled_domains/effective_tld_names.dat

其他浏览器也这样做，包括 IE 和 Firefox。

在DigiNotar 颁发的假证书列表中，有“*.*.com”。这显然是一种绕过限制的尝试。

对于发行部分，一切都可以放入证书中。名称是“通配符”对于 CA 没有特殊意义。CA 将字符串作为dNSName扩展名放置Subject Alt Name，仅此而已。此字符串是否包含“ *”字符不会影响 CA 行为。

重要的是SSL 客户端将接受什么作为“有效证书”，即包含与预期服务器名称“匹配”的名称（包含在 URL 中的名称）的证书。这在RFC 2818 的第 3.1 节中有名义上的规定，它允许多种通配符名称，包括诸如“ www.*.*c*”之类的东西，匹配（理论上）任何包含三个组件的服务器名称，第一个是“ www”，第三个包含至少一个“ c”。Web 浏览器供应商很快就认为该规范：

• 允许非常广泛的通配符名称；
• 正确实施相对复杂；
• 其他浏览器供应商和 CA 都不太可能正确实施（尽管 CA 不受名称内容的影响，但它仍然对证书的内容负责，并且浏览器供应商正确地猜测会有 CA不情愿地颁发过于宽泛的通配符证书）；
• 无论如何，它是一个“信息性” RFC，而不是“提议的标准”，因此有律师倾向的人可能会争辩说它可以被忽略。

所以浏览器厂商制定了自己的方案和限制。很久以后，发布了一个新的 RFC（6125，从 2011 年 3 月起），其中第 6.4.3 节专门用于处理证书中的通配符名称。RFC 6125 所描述的更符合实际情况，并且是“提议的标准”，因此至少在某种程度上有一些意愿来实现它。但是，RFC 6125 中没有任何内容要求拒绝*.com; 但浏览器确实拒绝它。

我已经在常见的浏览器上对此进行了测试，三个大浏览器（无论如何都在 Windows 上）不接受这个。我没有做的是在移动平台上尝试它，imo 是这次攻击的真正目标。由于 iOS 没有办法撤销证书，因此在苹果发布补丁并应用它之前，有数百万台 i 设备易受攻击。

很明显的地方可以尝试这个有很大的影响：Activesync 交换，ssl vpn 客户端，idevices 上的 safari，androids 上的股票浏览器。