Wildcard证书带与不带Subject Alternative Name的区别及安全影响

带SAN与不带SAN的通配符证书核心差异 #

两类证书的核心区别围绕域名匹配规则、兼容性、适用场景展开，具体差异如下：

• 域名匹配范围不同
  不带SAN字段的传统通配符证书，仅靠证书内的通用名称（CN）字段做匹配，规则非常死板：比如CN值为*.example.com的证书，仅能匹配a.example.com、test.example.com这类单层级子域名，既无法覆盖根域example.com本身，也无法匹配a.b.example.com这类多层级子域，更不可能支持其他主域名（如example.org）的匹配。
  带SAN（主题备用名称）字段的通配符证书，除了CN字段的基础匹配规则外，会优先读取SAN列表内的条目做域名校验，SAN列表支持添加任意你拥有控制权的域名：既可以加根域、不同层级的通配符条目（比如*.b.example.com），也可以加完全不同的其他主域名，一张证书就能覆盖列表内所有域名的HTTPS需求。
• 客户端兼容性不同
  2017年之后主流浏览器（Chrome 58+、Firefox 48+、Edge全版本等）就已经废弃了仅靠CN字段做域名校验的逻辑，所有证书必须携带正确的SAN字段才能被信任。没有SAN字段的老式通配符证书，在当前主流浏览器环境下访问会直接触发“连接不安全”的警告，甚至直接被拦截，仅能在十几年前的老旧操作系统、遗留业务客户端环境下正常使用。目前正规CA基本已经停发不带SAN的证书，新上线的服务完全没必要考虑这类老证书。
• 申请审核规则不同
  申请不带SAN的单通配符证书时，CA（证书颁发机构）仅会审核你对通配符对应主域的控制权；申请带SAN的通配符证书时，CA会对SAN列表内的每一个域名、每一个通配符条目单独做所有权校验，没有控制权的域名无法被加入SAN列表。
• 实际使用成本不同
  不带SAN的通配符证书适用场景极窄，现在几乎只有老旧系统兼容场景会用到；带SAN的通配符是当前的主流部署方案，不用为每个域名/子域单独申请、部署、续期证书，运维成本低很多。

带SAN的通配符证书的安全影响 #

这类证书本身不存在设计层面的原生安全缺陷，合规申请、正确部署的前提下，加密强度、身份校验可信度和普通单域名证书、老式通配符证书没有区别，所谓安全风险几乎都来自使用环节的不当操作：

• 私钥泄露的影响范围更大
  如果单张带SAN的通配符证书覆盖了大量域名（比如同时包含对外业务域名、内部系统域名、多个不同业务线的域名），一旦证书私钥发生泄露，攻击者可以直接伪造SAN列表内任意域名的钓鱼站点，用户端不会触发任何安全警告，影响范围远大于仅覆盖单个域的证书。
• SAN条目管理疏漏带来的风险
  证书本身是TLS握手过程中会公开传输的内容，所有人都能拿到。如果SAN列表里长期留存已经下线的测试域名、已经出售/弃用的域名，一旦私钥管控出现疏漏，拿到私钥的人可以直接用这张证书为这些失效域名搭建合法HTTPS服务，很容易被用于钓鱼欺诈。
• 权限过度分配的风险
  很多团队为了省事，申请证书时会把所有能加的域名都塞进SAN列表，给全公司所有业务线共用这一张证书，导致只需要负责单个子域运维的人员，也能拿到可以签所有公司域名的证书私钥，存在越权使用的隐患。

只要做好私钥的权限管控（按业务范围拆分不同的证书，不要一张证书覆盖所有域名，严格限制私钥的读取权限）、定期清理SAN列表内的无效条目、按时续期，带SAN的通配符证书完全可以安全使用，不需要刻意规避。

内容的提问来源于stack exchange，提问作者Sandeep Dommari