22

通过bouncycastle wiki 页面，我能够了解如何创建 X.509 根证书和认证请求，但我不太了解之后如何进行概念和编程。

让我们假设甲方提出了一个证书请求并从 CA 获得了他的客户端证书。B方如何验证A的证书？A需要什么样的证书？根证书？“普通”客户端证书？

如果我们假设 A 已经成功地将他的 DER 或 PEM 格式的证书发送给 B，那么验证在编程级别上是如何工作的？

任何帮助深表感谢。

最好的问候，罗伯

4

2 回答 2

38

从程序员的角度来看，您需要做一些事情来验证 X.509 证书。

  1. 一组“信任锚”——您所依赖的 CA 的根证书。这些应该被保护不被篡改，这样攻击者就不会用他自己的假证书替换 CA 证书。这些证书中的公钥用于验证其他证书上的数字签名。
  2. 中级证书的集合。应用程序可能会保留这些证书的集合，但大多数使用证书的协议（如 SSL 和 S/MIME）都有提供额外证书的标准方法。存储这些不需要任何特别的照顾；它们的完整性受根 CA 的签名保护。
  3. 撤销信息。即使证书是由 CA 颁发的，它也可能因为私钥被泄露，或者最终实体改变了他们的身份而被提前撤销。（例如，一个人换了工作，其中包含其旧公司名称的证书被吊销。）CRL 或类似 OCSP 的 Web 服务可用于获取有关证书状态的更新。

有了这些可用的输入，您就可以使用内置的 PKIX 支持来构建和验证证书路径。

/* Givens. */
InputStream trustStoreInput = ...
char[] password = ...
List<X509Certificate> chain = ...
Collection<X509CRL> crls = ...

/* Construct a valid path. */
KeyStore anchors = KeyStore.getInstance(KeyStore.getDefaultType());
anchors.load(trustStoreInput, password);
X509CertSelector target = new X509CertSelector();
target.setCertificate(chain.get(0));
PKIXBuilderParameters params = new PKIXBuilderParameters(anchors, target);
CertStoreParameters intermediates = new CollectionCertStoreParameters(chain)
params.addCertStore(CertStore.getInstance("Collection", intermediates));
CertStoreParameters revoked = new CollectionCertStoreParameters(crls);
params.addCertStore(CertStore.getInstance("Collection", revoked));
CertPathBuilder builder = CertPathBuilder.getInstance("PKIX");
/* 
 * If build() returns successfully, the certificate is valid. More details 
 * about the valid path can be obtained through the PKIXBuilderResult.
 * If no valid path can be found, a CertPathBuilderException is thrown.
 */
PKIXBuilderResult r = (PKIXBuilderResult) builder.build(params);

需要注意的重要一点是，如果找不到路径，您将无法获得有关原因的太多信息。这可能令人沮丧，但设计就是这样。一般来说，有许多潜在的路径。如果它们都因不同的原因而失败，路径构建器将如何决定报告什么作为原因？

于 2010-03-16T21:36:45.203 回答
9

好的，CAs背后的想法如下：

  • CA 是每个人都信任的人。为此，您的浏览器/电子邮件客户端/甚至我的手机上都提供了一系列受信任的 CA。在您的情况下，您的公共根密钥（证书）应该在您的应用程序中。
  • 用户使用公钥向 CA 发送 PEM 格式证书的请求。CA 对最终用户进行一些（我故意留下这种模棱两可的）形式的验证，例如向他们收费或在增强验证（绿色）证书的情况下进行背景调查。
  • 如果 CA 认为用户的请求无效，他们会以某种方式传达此信息。
  • 如果他们这样做了，他们会签署公钥并生成包含此信息的证书。这是您处理 cert-req 并将其转换为 X.509 证书的地方。
  • 其他用户遇到了我们的虚拟用户，想知道他们是否可以信任他们。因此，他们查看了证书，发现它是由他们信任列表中的某个人进行数字签名的。因此，他们信任根 CA 并且只有根 CA 可以签署（通过他们的私钥）该用户的公钥并且 CA 信任该用户，我们推断新用户可以信任虚构的 mr。

在编程级别上，您可以通过阅读 X.509 证书并确定 CA 应该是谁来实现这一点。鉴于 CA 的指纹，您可以在数据库中找到它并验证签名。如果匹配，您就有了信任链。

这是因为，正如我所说，只有 CA 可以创建数字签名，但任何人都可以验证它。这与加密概念正好相反。您所做的是“使用私钥加密”您希望签署的数据，并验证“使用公钥解密”是否等于您拥有的数据。

于 2010-03-16T20:45:48.380 回答