签署时在pdf中添加撤销详细信息 [英] add revocation detail in pdf while signing same
问题描述
我已使用libarary itext sharp在pc中附加的数字令牌对pdf进行了数字签名，以在其上附加相同的内容，当我在Adobe Reader中打开它时，它表明无法执行撤销，并且当我看到详细信息时，它表明签发者证书的吊销没有检查错误，即:BER解码时遇到错误.
I am have digitally signed a pdf using digital token attached in pc using libarary itext sharp to append same, when i open same in adobe reader it shows revocation can not be performed and when i see details then it shows that one of the issuers certificate's revocation is not checked with error : error encountered while BER decoding.
我的纯签名pdf路径: https://www.sendspace.com/file/vqgl53
path to my plain signed pdf: https://www.sendspace.com/file/vqgl53
作为一种解决方案，我认为如果可以在文档(我的纯正签名的pdf)中添加CRL信息本身，那么我就不会遇到这个问题.所以我添加了在此ans中提到的代码:
As a solution i thought if i can add CRL information itself in document(my plain signed pdf) then i won't face this problem. So i added code mentioned in this ans : I want to sign a pdf document with ITextSharp and return ltv pdf enabled file
但是我在第addLtvForChain(null, ocspClient, crlClient, getCrlHashKey(crlBytes));
在第一行的 getCrlHashKey中:X509Crl crl = new X509Crl(CertificateList.GetInstance(crlBytes));
异常说:
GetInstance中的未知对象: Org.BouncyCastle.Asn1.DerApplicationSpecific参数名称:obj
Unknown object in GetInstance: Org.BouncyCastle.Asn1.DerApplicationSpecific Parameter name: obj
请进一步提出建议.
推荐答案
扩展AdobeLtvEnabling
产生异常的原因是，对于一个证书，相关的CRL是base64编码的，而AdobeLtvEnabling类是不希望的(这里的期望是检索二进制版本，不需要解码).
Extending AdobeLtvEnabling
The cause of the exception is that for one certificate the associated CRL is base64 encoded which the AdobeLtvEnabling class does not expect (the expectation here is to retrieve a binary version, no decoding required).
您可以如下扩展AdobeLtvEnabling以也能够处理base64编码的CRL:搜索AdobeLtvEnabling方法addLtvForChain并替换CRL处理循环
You can extend the AdobeLtvEnabling as follows to also be able to handle base64 encoded CRLs: search the AdobeLtvEnabling method addLtvForChain and replace the CRL handling loop
Console.WriteLine(" with {0} CRLs\n", crl.Count);
foreach (byte[] crlBytes in crl)
{
validationData.crls.Add(crlBytes);
addLtvForChain(null, ocspClient, crlClient, getCrlHashKey(crlBytes));
}
与此:
Console.WriteLine(" with {0} CRLs\n", crl.Count);
foreach (byte[] crlBytes in crl)
{
PdfName hashKey = null;
byte[] bytes = null;
try
{
hashKey = getCrlHashKey(crlBytes);
bytes = crlBytes;
}
catch (Exception e)
{
Console.WriteLine(" CRL decoding exception, assuming Base64 encoding, trying to decode - {0}\n", e.Message);
bytes = Convert.FromBase64String(new String(Encoding.Default.GetChars(crlBytes)));
hashKey = getCrlHashKey(bytes);
}
validationData.crls.Add(bytes);
addLtvForChain(null, ocspClient, crlClient, hashKey);
}
但是，
您的签名
虽然当前其他有问题的非根证书的撤销是指嵌入式CRL，但对于一个证书仍然存在问题，Adobe Reader中"RCAI 2类2014(SAFESCRYPTONLINE_15)的SafeScrypt子CA的撤销"选项卡表演
Your signature, though
While revocation of the other non-root certificates in question now refers to embedded CRLs, for one certificate there still is an issue, the revocation tab for "SafeScrypt sub-CA for RCAI Class 2 2014 (SAFESCRYPTONLINE_15)" in Adobe Reader shows
CRL processing error
Issuer: cn=SafeScrypt CA 2014, houseIdentifier=II Floor, Tidel Park, street=No.4, Rajiv Gandhi Salai, Taramani, Chennai, st=Tamil Nadu, postalCode=600 113, ou=Certifying Authority, o=Sify Technologies Limited, c=IN
This update: 20180303183000Z
Next update: 20190303182959Z
CRL has expired or is not yet valid
实际上，具有下一个更新值20190303182959Z的CRL已过期，因此，如果没有适当的POE，则现在不能将其用于验证.因此，确实，Adobe Reader完全正确地指出，基于CRL(当前由PKI服务)，它无法确定未撤销.
Indeed, a CRL with a next update value of 20190303182959Z is expired and, therefore, cannot be used now for validation without appropriate POEs. So indeed, Adobe Reader ist completely correct in stating that based on that CRL (currently served by the PKI) it cannot determine non-Revocation.
但是可以从其他信息中获得吗?嗯，证书中有一个OCSP响应者可以使用的AIA属性.但是尝试使用它失败， http://ocsp.safescrypt.com 当前不接受任何请求.因此，这不是实际的选择.
But could it from other information? Well, there is an AIA attribute in the certificate for an OCSP responder that could alternatively be used. But an attempt to use it fails, http://ocsp.safescrypt.com currently accepts no requests. So this is no actual alternative.
所有这些使该CA的服务质量显得令人怀疑.如果此状态继续，则可能要切换到其他CA.
All in all this makes the quality of service of this CA appear questionable. If this state continues, you might want to switch to a different CA.
这篇关于签署时在pdf中添加撤销详细信息的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
