crypto/x509 ParseCertificate 后如何读取 SAN 而不是 CN

Go 里调用 x509.ParseCertificate 后，读取 SAN 不需要手动解析扩展：DNS 名称看 cert.DNSNames，IP 地址看 cert.IPAddresses，邮箱看 cert.EmailAddresses。cert.Subject 是证书主体的 DN 信息，里面的 CommonName 仍能读取，但不能把它当成现代主机名校验的回退字段。

官方文档：https://pkg.go.dev/crypto/x509

先分清 SAN 和 Subject

证书解析结果可以看成一个已经整理好的对象，而不是一段需要再次按字符串搜索的文本。Certificate.Subject 的类型是 pkix.Name，它描述证书主体的区分名；Certificate.DNSNames、IPAddresses、EmailAddresses 等字段则来自 Subject Alternative Name（SAN）扩展。

因此，“想知道证书包含哪些域名”应该读取 DNSNames；“想看证书主题里的 CN”才读取 Subject.CommonName。两者可能碰巧相同，也可能完全不同，不能因为某张旧证书的值相同就合并语义。

用 ParseCertificate 取得证书对象

如果输入是 PEM，先用 pem.Decode 取出 DER 字节，再交给 x509.ParseCertificate。下面的写法把两个解析错误分开处理，避免把“没有 PEM 块”和“DER 内容损坏”混成一个问题。

package main

import (
    "crypto/x509"
    "encoding/pem"
    "fmt"
)

func parseCertificate(pemBytes []byte) (*x509.Certificate, error) {
    // PEM 只负责外层封装；先取出其中的 DER 字节。
    block, _ := pem.Decode(pemBytes)
    if block == nil || block.Type != "CERTIFICATE" {
        return nil, fmt.Errorf("输入中没有 CERTIFICATE PEM 块")
    }

    // ParseCertificate 负责解析单张 ASN.1 DER 证书。
    cert, err := x509.ParseCertificate(block.Bytes)
    if err != nil {
        return nil, fmt.Errorf("解析 X.509 证书失败: %w", err)
    }
    return cert, nil
}

若手里已经是 DER 字节，可以直接调用 x509.ParseCertificate(derBytes)。解析成功只说明字节能被解析成证书对象，不等于已经完成信任链、用途或吊销状态验证；本文只讨论名称字段的读取。

按名称类型读取 SAN

SAN 不是一个需要调用者自行拆分的字符串。Go 将常见名称类型映射成不同字段：域名放在 DNSNames，IP 地址放在 IPAddresses，邮箱放在 EmailAddresses，URI 则放在 URIs。读取时保留切片语义，因为一张证书可以包含多个名称。

func certificateNames(cert *x509.Certificate) (dns []string, ips []string, cn string) {
    // DNSNames 可能有多个值，复制到结果中表示证书允许的 DNS 名称集合。
    dns = append([]string(nil), cert.DNSNames...)

    // IPAddresses 是 []net.IP；这里转成字符串只为展示或日志，不改变证书对象。
    for _, ip := range cert.IPAddresses {
        ips = append(ips, ip.String())
    }

    // CommonName 属于 Subject 主体字段，单独保存，避免和 SAN 混为一谈。
    cn = cert.Subject.CommonName
    return dns, ips, cn
}

如果业务只需要判断某个域名是否出现在 SAN 中，可以遍历 DNSNames 并按你的业务规则比较；不要把 Subject.String() 当成稳定的机器可读格式。若还要处理 URI 或邮箱，继续读取对应的强类型字段，而不是从字符串里猜字段位置。

VerifyHostname 不会回退到 CN

读取字段和执行主机名匹配是两件事。cert.VerifyHostname(host) 会针对输入类型使用证书中的 SAN：普通主机名检查 DNSNames，IP 地址检查 IPAddresses；官方文档明确说明 legacy Common Name 会被忽略。

func matchCertificateName(cert *x509.Certificate, host string) error {
    // VerifyHostname 会根据 host 是域名还是 IP 选择对应的 SAN 字段。
    if err := cert.VerifyHostname(host); err != nil {
        return fmt.Errorf("证书不匹配 %q: %w", host, err)
    }
    return nil
}

这意味着一张证书可能出现“CN 看起来正确，但 VerifyHostname 仍失败”的情况：如果 SAN 没有对应名称，不能把 CN 当成兜底。对新代码来说，应该在证书签发和使用端都把 SAN 当作名称匹配的正式来源。

几个容易混淆的边界

还要注意，解析后的字段来自证书内容，不能把读取结果当成可信性结论。对于来自网络或用户上传的证书，仍要按业务需要单独考虑有效期、用途、信任根和链验证；这些事项不由读取 SAN 这一步自动完成。

常见问题

DNSNames 为空时能不能读取 CommonName 继续匹配

不建议这样做。CommonName 可以作为展示或兼容性诊断信息，但 VerifyHostname 的现代匹配规则不会把它作为回退来源。若业务必须兼容历史系统，应把兼容策略写成显式、隔离且经过评估的规则，不要误称为标准主机名校验。

IP 地址为什么不放在 DNSNames

因为 Go 将 SAN 中的 DNS 名称和 IP 地址建模成不同字段。IP 输入应使用 IPAddresses，并交给 VerifyHostname 统一处理；不要把 IP 字符串当成域名切片的普通文本。

ParseCertificate 成功是不是代表证书可用

不是。它代表 ASN.1 DER 可以解析成 *x509.Certificate。是否被某个根信任、是否在有效期内、是否允许服务器或客户端用途，需要根据实际场景进一步验证。