我正在尝试替换 Exchange 服务器上已过期的自签名 SSL 证书。我使用 selfssl 创建了一个新证书，但当我尝试添加新的公共文件夹时，出现错误，提示“ssl 证书服务器名称不正确”。
我怀疑原因在于我的服务器的公共 FQDN 和其内部名称不相同（显然如此），因此当我在本地管理服务器时，我收到此错误。具体来说，当我尝试从服务器本身添加新的公共文件夹（通过远程桌面）时，我收到此错误。我的 LAN 上的客户端可以正常访问服务器上的 OWA（除了我的浏览器警告我证书是自签名的，这是意料之中的）。在我的 LAN 上，我的公共 FQDN 正确解析为机器的内部 LAN IP 地址。
之前的证书在“颁发者”字段中有一个包含 5 个左右名称的列表（localhost、mail.mydomain.com、mail.mydomain.local、mail 等）。只要提供以下两条信息之一，我的问题就可以解决：
如何创建具有多个 CN 值的证书？将多个 CN 值传递给 selfssl 的明显解决方案似乎不起作用。我不会被说服购买 UC 证书，因为“嗯，Exchange 需要这个奇怪的东西，只要购买它，一切都会好起来。”必须能够使用 OpenSSL 等签署适用于此的证书。
我觉得我需要一个除了 FQDN 之外的证书，这很奇怪。有没有办法让 Exchange 以正常的方式运行，而不需要带有 SAN 的证书？这是迄今为止我最喜欢的解决方案。
该服务器运行的是 Small Business Server 2003 和 Exchange Server 2003 SP2。
答案1
如果您想要一个具有多个名称的证书，则需要购买支持主题备用名称的证书。我今天花了 55 多英镑买了一个。它不是您可以购买的最强大的证书之一，但对于只有内部员工使用系统的小型企业来说，它们很好，并且可以消除所有证书错误。
如果您使用 ISP 托管外部 DNS，并且（显然）在您的网络内托管内部 DNS，那么很容易绕过此问题，并且您不需要 SAN 证书。请注意，这不适用于 2003 年之后的 Exchange 版本，因此购买证书是您唯一的选择。
例如，如果您的 Exchange 服务器在外部是，exchange.example.com但您使用其他内部名称（例如exchange.example.local或exchange.internal.example.com），那么您需要做的就是exchange.example.com在您的内部 DNS 上创建一个新的 DNS 正向查找区域，并向该区域添加一个默认的“@”记录，该记录指向您的 Exchange 服务器。
内部查找exchange.example.com将解析为您的内部 IP，而在您的网络外部执行的查询将解析为您的外部 IP 地址。