1 person found this helpful
When you open the file Acrobat (and when I say Acrobat I mean both Acrobat & Reader) does the signature validation. As part of the validation process it figures out if it has to go online to download revocation information, or, is all of the revocation information embedded in the PDF file. At this point it knows what it's going to say in the Signature Navigation Panel. If it had to download data then the signature is not LTV enabled, but if all of the revocation collateral is in the file then the signature is LTV enabled.
There has to be something with the CRL that covers the OCSP signing cert that is forcing Acrobat to procure a fresh CRL. Without seeing the CRL it's hard to know what it is, but that's why the signature is not LTV enabled.
Because the other signature has the noCheck flag set Acrobat does not have to do revocation checking on the OCSP signer's cert, thus it doesn't have to download the CRL so the signature is LTV enabled.
Thanks for the detail response.
You can download the problematic PDF document from the following URL:
Can you please look what's wrong due to which "Signature is not LTV enabled" and explain what's missing with the CRL embedded for OCSP response signing certificate?
I downloaded your sample PDF but when I try to validate the signature, I get:
CRL download error
Unable to connect to remote server
Is your CRL server behind a firewall? This is the CRL required to check revocation for the OCSP response required to check revocation for the main signer. That OCSP response was embedded in the document. The fact that when I tried to validate your signature Acrobat XI went on-line to download http://192.168.0.116:8773/adss/console/crls/sample.crl tells me that this CRL is not embedded in DSS or is not usable for a variety of reasons.
I also inspected your sample PDF and the signature in it was not created by Acrobat. The producer of this signature may have missed some revocation info when it created a PAdES signature with LTV in it. It is fairly easy to check it.
1. Open your PDF in Acrobat XI or Reader XI and make sure that the signature's validation status is Valid. You may need to add your root certificate to "Trusted Identities" in Acrobat/Reader.
2. In the Signature Panel or in the PDF right-click on the signature and select "Show Signature Properties..."
3. Click "Show Signer's Certificate". This brings up "Certificate Viewer" for the main signer.
4. For each certificate in the path in the left pane except the root (Simple Sign Cert and ADSS Samples Test CA) do the following:
4.1. Click on Revocation tab.
4.2. The Details window shows you which CRL/OCSP was used for revocation checking and what was the source of revocation info (obtained on-line, embedded in the document, contained in the local cache).
4.3. Click on "Signer's Details..." This brings up "Certificate Viewer" for the CRL/OCSP signer. Repeat all steps in #4 for this signer.
5. Recursively examine all certificates for revocation checking. If any of them shows in #4.2 the source of revocation other than "embedded in the document" then your PDF is not LTV-enabled because of this certificate's revocation info missing.
Thanks for the detailed and informative response.
Revocation information for all signer's certificate chain, TSA certificate chain and OCSP Response signing certificate is embedded in DSS. You can get the Certs, CRLs and OCSP response embedded in PAdES-LTV signature from the following URL:
that this CRL is not embedded in DSS or is not usable for a variety of reasons.
CRL (Crl.crl) is embedded in DSS for OCSP response signing certificate. Can you explain what are the reasons that embedded CRL is not usable?
Sorry for a late response, I was away. Could you, please, provide PDF that you think should be LTV-enabled and is reported as not.
The PDF can be downloaded from the following URL:
and the CRLs and OCSP responses embedded into the PDF document can be downloaded from:
It took some digging to figure it out. The Issuer field in the signer of the OCSP response (Issuer 1), certificate with Subject Name "cn=Sample Sign Cert" and Issuer Name "ou=Development o=Ascertia c=GB cn=ADSS Samples Test CA" is not the same as the Issuer Name in the CRL (Issuer 2) issued by "ou=Development, o=Ascertia, c=GB, cn=ADSS Samples Test CA". Although DNs in both Issuer Names are the same, the attributes in both Issuers are different: Issuer 1 has 4 attributes and Issuer 2 has only 1 attribute. For a CRL being acceptable all attributes must be the same. In this case they are not. Both the certificate-in-question (for which revocation checking is performed) and CRL must be signed by the same CA's certificate unless CRL has an "indirect CRL" designation. Neither condition is satisfied in this case. It seems that the PKI infrastructure that you are using does not conform to standards.
This is why the embedded CRL cannot be used for the revocation checking of the signer of the OCSP response. Hence the signature is not LTV enabled.
In order to skip OCSP signer's revocation checking, the OCSP signer's certificate must have an additional 'OCSP no revocation checking' extension which this OCSP signer does not have.
Thanks for the detailed response. I parsed the certificates, CRL and extraced the RDNs in issuer DN.
There are four RDNs in issuer DN:
CN = ADSS Sample Test CA
O = Ascertia
OU = Development
C = GB
in OCSP resposne certificate issuer, sample sign cert issuer and CRL issuer.
Are you talking about the RDNs (attributes)? Can you please explain and highlight the attributes you are referring?
1 person found this helpful
I fear Isak over-complicated his answer. Forget the RDN, it's leading you down the wrong thought path.
The bottom line is the digital ID used to sign the CRL has to be the same digital ID used to sign the public-key certificate used to sign the OCSP response. That is, you've got a digital ID (a public, private key pair) that is being used to sign OCSP responses. This particular digital ID has an issuer. Forget about the DN in the issuers certificate, just concentrate on the fact that this is a specific digital ID. If you really want to match pieces of data in the certificates in this case you would start with the Subject Key Identifier (SKI).
There is a CRL out there that provides revocation status for the certificate used to sign the OCSP response. This CRL needs to be signed by the same certificate that signed the OCSP responder's certificate. Not just a certificate with the same DN information, but the exact same certificate. If you look at the CRL it may (and should if it was created correctly) contain a Authority Key Identifier (AKI). This AKI should match two things; first it needs to match the SKI in the cert that issued the OCSP responder certificate (or another way to look at this, the last CA in the signing chain), and it should match the SKI in the OCSP responders public-key certificate.
One CA digital ID used to sign both the CRL and the OCSP responders public-key certificate.
Thanks for the detailed and informative response. Its working now and showing Signature is LTV enabled.