使用自签名证书验证数字签名
我有一个关于使用自签名证书验证数字签名的问题:
以下教程适合我: http://www.oracle.com/technetwork/ articles/javase/dig-signature-api-140772.html
但是,当 X.509 证书是自签名时,接收者如何信任附加到 XML 消息的证书数据?任何人都可以生成自签名证书并声称是同一发件人。上述教程中的验证始终返回 true。发送者的证书必须加载到接收者的信任库中,以便接收者可以使用信任库中的任何内容来验证签名的文档。我找不到这种情况的任何参考。
I have a question regarding validation of digital signatures using a self-signed certificate:
The following tutorial works for me:
http://www.oracle.com/technetwork/articles/javase/dig-signature-api-140772.html
However, when a X.509 certificate is self-signed, how can a receiver trust certificate data attached to an XML message? Any one can generate a self-signed cert and claim to be the same sender. The validation in the above tutorial always returns true. Sender’s cert must be loaded to receiver’s truststore, so receiver can use whatever in the truststore to validate signed doc. I cannot find any reference for such a scenario.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您的理解是正确的 - 使用自签名证书,任何人都可以创建证书并且签名验证就可以了。原因是签名验证首先执行所有加密操作,该操作已成功完成。第二步是验证证书本身及其来源。使用 CA 签名的证书时,将使用 CA 证书(直至受信任的 CA(或已知的根 CA))来验证证书。使用自签名证书验证是不可能的。在上面的教程中,为了简单起见,跳过了证书验证过程,因为它非常复杂并且超出了教程的范围。
Your understanding is correct - with self-signed certificates anyone can create a certificate and signature validation will be ok. The reason is that signature validation performs first of all cryptographic operation, which is completed successfully. The second step is to validate the certificate itself AND also it's origins. When the CA-signed certificate is used, the certificate is validated using CA certificate(s) up to trusted CA (or known root CA). With self-signed certificate validation is not possible. In the above tutorial the procedure of certificate validation was skipped for simplicity as it's quite complex and beyond the scope of tutorial.
您描述的问题通常可以通过公钥基础设施 (PKI) 来解决。
例如,这是验证 HTTPS 站点证书的传统模型。它从一组受信任的证书颁发机构 (CA) 开始,您可以从中导入“受信任”的 CA 证书。然后,通过在要验证的证书和您知道的 CA 证书之间构建证书路径(可能通过中间 CA 证书将证书链接到受信任的颁发者),根据这组受信任的锚点验证您获得的实体证书。
RFC 5280 中描述了执行此操作的各种规则。 PKI 系统不仅适用于 Web 服务器,还适用于任何实体(除了拥有有效证书之外,Web 服务器还有其他规则来验证它们是否是您想要与之通信的服务器)。
是因为选择信任的 CA 证书通常是由操作系统或浏览器供应商代表用户完成的,至少在默认情况下是这样,因此该模型并不完美,但它是最常用的。)
(特别 ,提前建立一个您信任的自签名证书列表并没有什么问题。
无论哪种方式,您都需要通过带外机制预先设置您信任的内容(例如,通过与您信任的人会面并使用他们亲自给您的证书)。
由于发行者 DN 和主体 DN 的概念,该 PKI 模型与 X.509 格式齐头并进。您可以有其他模型,例如依赖 PGP 证书,您可以在其中构建信任网络;您仍然需要一组初始的可信锚点。
对于 Java 中的 XML-DSig,您应该实现一个仅返回您信任的密钥的
X509KeySelector
。在一个简单的场景中,如果您有一组预定义的您信任的自签名证书,您可以迭代包含这些受信任证书的密钥库。否则,请使用 Java PKI 程序员指南(如您使用的教程中的链接)。The problem you're describing is usually addressed by Public Key Infrastructures (PKI).
This is the traditional model for verifying certificates for HTTPS sites, for example. It starts with a set of trusted Certification Authorities (CAs) from which you import the CA certificates as "trusted". The entity certificates that you get are then verified against this set of trusted anchors by building a certification path between the certificate to verify and a CA certificate you know (linking the certificate to a trusted issuer, perhaps via intermediate CA certificates).
The various rules to do this are described in RFC 5280. The PKI system doesn't apply only to web servers, but to any entity (there are additional rules for web servers to verify that they're the one you want to talk to, on top of having a valid certificate).
(In particular because the choice of which CA certificates to trust is often done on behalf of the user, at least by default, by the OS or browser vendor, this model isn't perfect, but it's the most common in use.)
Alternatively, there's nothing wrong with establishing a list of self-signed certificates you would trust in advance.
Either way, you need to pre-set what you trust by mechanisms out of bands (e.g. by meeting someone you trust and using the certificate they give you in person).
This PKI model goes hand-in-hand with the X.509 format thanks to the notion of Issuer DN and Subject DN. You could have other models, for example relying on PGP certificates, where you would build a web of trust; you would still need an initial set of trusted anchors.
For XML-DSig in Java, you should implement a
X509KeySelector
that only returns a key that you trust. In a simple scenario, where you have a pre-defined set of self-signed certificates you trust, you can iterate over a keystore containing those trusted certificates. Otherwise, use the Java PKI Programmer Guide (as linked from the tutorial you've used).