在X.509证书中，还包括颁发者的名称（在您的示例中为 A 的名称）（如issuerDN）。此外，证书可以包含指向可以下载颁发者证书的位置的扩展名（“授权信息访问”，RFC 5280 的第 4.2.2.1 节）；请注意，由于所有证书都是经过签名的实体，只有在验证了这些签名后才能被接受和使用，因此可以不费吹灰之力地下载和传输它们。最后，在一方可以显示证书的协议中，通常会实际显示包含所需中间 CA 证书的证书列表。例如，这就是在 SSLCertificate消息中发生的情况。

所有这些都为计算机提供了很多方法来构建证书路径，即重建与验证（包括验证密码签名）相关的证书链。

当 CA 颁发证书时，他们使用他们的私钥对其进行签名。只有 CA 的公钥才能验证签名的真实性和证书没有被篡改。

奇怪的是，在很多情况下（.NET 的 X509Certificate 类以及在 Windows 中查看证书时）似乎都缺少签名属性。我发现即使它并不总是显示，它仍然在证书内。给定一个 DER 二进制格式的证书，您可以将其解码为显示签名者签名的纯文本。

openssl x509 -text -noout -inform DER -in certFile.der

Signature Algorithm: sha1WithRSAEncryption
    30:d9:40:ac:d8:0d:46:81:68:14:8a:c6:a7:29:96:4e:b4:58:
    7b:e6:12:3f:45:4f:c6:9b:18:aa:f2:99:23:ee:48:df:5f:c0:
    a3:c7:e4:ba:3a:bc:6f:58:57:fe:a8:a7:23:d0:d1:9a:47:a6:
    42:1a:d8:20:e8:f1:ec:76:43:47:0b:75:d6:a1:d2:71:2b:f7:
    19:96:e3:48:57:e2:36:0f:0c:25:5d:7f:f8:26:50:c2:5e:80:
    8e:17:ac:37:ad:f1:e3:3c:6f:a3:20:a6:16:93:df:2b:04:9c:
    22:d3:01:33:f9:4c:3b:f8:a8:39:f1:6c:41:74:de:ba:96:6a:
    0b:f1:e6:f0:7b:d8:1f:42:ec:b5:73:d1:94:1b:01:4a:4c:13:
    ca:5e:2b:af:fd:2c:eb:43:d3:fc:2f:ea:5a:8d:db:a9:6a:f6:
    b6:9b:58:e1:b7:94:7f:14:6d:11:8b:2c:b7:4e:f3:82:ad:c4:
    92:04:c4:97:a3:7a:52:e5:a0:b1:1b:8f:47:bb:43:a3:2c:1a:
    fb:31:d9:51:7c:23:7b:57:8e:73:46:81:c4:25:f3:48:c5:a1:
    8f:0d:3d:f2:e1:4b:fd:7f:49:b9:f9:b1:2a:c2:22:9e:8a:85:
    61:bd:b7:18:8e:56:33:a4:6e:d2:7d:db:2e:37:d0:fb:9a:35:
    87:c8:2a:69

来自http://en.wikipedia.org/wiki/X.509

要验证此证书，需要与第一个证书的颁发者（Thawte 服务器 CA）匹配的第二个证书。首先，验证第二个证书是 CA 类型的；也就是说，它可以用来颁发其他证书。这是通过检查 X509v3 扩展部分中的 CA 属性的值来完成的。然后来自 CA 证书的 RSA 公钥用于解码第一个证书上的签名以获得 MD5 散列，该散列必须匹配在证书的其余部分计算的实际 MD5 散列。