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.
path to my plain signed pdf: https://www.sendspace.com/file/vqgl53
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
but I am getting exception on line : addLtvForChain(null, ocspClient, crlClient, getCrlHashKey(crlBytes));
IN SUBMETHOD getCrlHashKey ON FIRST LINE : X509Crl crl = new X509Crl(CertificateList.GetInstance(crlBytes));
exception says : Unknown object in GetInstance: Org.BouncyCastle.Asn1.DerApplicationSpecific
Parameter name: obj
Kindly suggest further.
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).
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));
}
with this:
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);
}
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
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.
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.
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.
