LTV and OCSP response using RFC's Local Configuration

[alexperezbarreiro]

Hello,

I'm trying to obtain a LTV-compliant signature with Adobe Reader 11.0.12. This is the certificate's chain I am using:

CA --> ICA --> EE

Internal CA --> OCSP Responder

Internal CA --> TSA

I cannot use a OCSP Responder certificate issued by the same CA that the certificate it's been checked, so according to the RFC 2560 4.2.2.2 "Authorized Responders", I would follow case 1 for the signing reponse:

1. Matches a local configuration of OCSP signing authority for the

  certificate in question;

According to Adobe Reader's security documentation acrobat_reader_security_9x.pdf in 5.3.1.1, this "local configuration" is implemented setting the sURL in Adobe_OCSPRevChecker registry keys to authorize responses that come from the URL that is set regardless the response is signed by the same CA or not.

I'm able to set these settings and my internal OCSP server is used instead of the certificate's when signing and validating, the signature is valid, however I can never get a LTV signature and it needs to go online every time I validate the signature.

Enabling the log file for the verification I can see these entries:

OCSP response was not signed by an authorized responder.

Error encountered in processing OCSP responder certificate

Using an embedded CRL I obtain a LTV signature, but I'd rather use OCSP if it were possible. Any help?

[IsakTen-RwIoo2]

Does the error that you describe occur on the same machine where you set up local configuration? If this is the case then there might be some bug which I suggest you report to Acrobat Support.

If it is on a different machine then it should be expected. Local configuration means that it works only locally, You need to have the same local configuration on each machine where your signature will be validated. My guess is that your OCSP is embedded in the signature but is rejected when the signature is validated on a machine without your local configuration and then Acrobat goes on-line to get OCSP.

I suggest that you perform the following experiment. If you have Acrobat Pro, then uncheck "Include signature's revocation status" in the signature "Creation" preferences and sign your PDF, making sure that it is valid. Then right-click on the signature and select "Add Verification Information" (not available in the free Reader). Save and close signed PDF. Re-open this PDF and check in the Signature Properties Revocation tab whether it says that OCSP embedded in the document was used.

[alexperezbarreiro]

Thank you for your answer isakten.

The signature is validated on the same computer where it's been created with the Local Configuration active. To create/validate the signature I override the OCSP address from the AIA extension and it works as expected, from what I read in the Adobe's documentation this is enough to trust the OCSP's certificate as a responder.

I'll give more information to try to find the error, maybe it's my mistake and not Adobe's . This is one of my test configurations I've used, when I change the sURL value, Adobe Reader goes request the OCSP response to the new one successfully.

[HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\11.0\Security\cASPKI\cAdobe_OCSPRevChecker]

"sURL"=hex:68,74,74,70,3a,2f,2f,63,6f,73,69,67,6e,2e,70,6f,76,69,73,61,2e,6e,\

  65,74,3a,38,37,37,37,2f,61,64,73,73,2f,6f,63,73,70,00

"iURLToConsult"=dword:00000001

"iSendNonce"=dword:00000000

sURL is http://cosign.povisa.net:8777/adss/ocsp in binary ending with a null character.

This is a global configuration, in my final settings I'm using cCustomCertPrefs to to target only the specific CA I'm interested in.

I've tried as you suggested adding the verification information not during the signature itself but later, the result is the same. I've been able to do so with the free Adobe Reader 11.0.12 version, I have the option available.

[IsakTen-RwIoo2]

Are you saying that sURL works fine when you use a different OCSP server and that you get OCSP included in LTV when you use this other OCSP server?

If this is the case then something's wrong with  http://cosign.povisa.net:8777/adss/ocsp. Can you reach it? When I tried to open this link in a browser I got "Firefox can't find the server at cosign.povisa.net". Is it behind a firewall? It should not matter if the computer where you sign is on the same network.

Please, clarify.

[alexperezbarreiro]

I meant that the configuration to override the certificate's AIA is working, when I change the sURL, requests point to the new address, the right one is http://cosign.povisa.net:8777/adss/ocsp , other addresses would obviously fail to supply an OCSP response.

That is an internal address not reachable from the internet.

[IsakTen-RwIoo2]

I am having difficulty to understand your response. Please, provide answers to my previous questions one by one.

Additionally: from what you wrote the sURL functionality works for other URLs pointing to different OCSP servers but not for this specific one. By 'works' I mean that the OCSP is used in the signature validation and is included in LTV. Is this correct? With this specific URL the OCSP is still used but is not included in LTV. Is this also correct?

If the answers to the last two questions are affirmative, then something's going on with this specific URL and not with the general LTV functionality in Acrobat. If this is not the case, then, please, describe in details your results.

I am having difficulty to understand what's going on. You did a good job in describing what you did (the original post and Feb 20, 2016 1:52 AM post). Please, be more specific regarding the results that you get (that's the questions in my previous and this posts).

Even though the problem URL is an internal one (inside a firewall) you still must be able to open it in a browser when you are inside the same firewall. If you cannot then Acrobat cannot either.

BTW, how do you determine that OCSP is not included in LTV?

[alexperezbarreiro]

Thank you for your interest isakten, let me answer your questions:

the OCSP is used in the signature validation and is included in LTV. Is this correct?

No. The original OCSP address cannot be used. This is a capture of the certificate's AIA extension:

With this specific URL the OCSP is still used but is not included in LTV. Is this also correct?

Yes. The sURL is used and included in the signature.

you still must be able to open it in a browser when you are inside the same firewall.

There is no network problem involved, we can reach the OCSP and get its response.

The problem comes with the verification of the signature, please see the verification log:

OCSP response was not signed by an authorized responder.DN: cn=Povisa OCSP-FNMT, ou=Informatica, o=Hospital POVISA, email=informatica@povisa.es, l=Vigo, street=Salamanca, 5, postalCode=36211, st=Galicia, c=ES Serial: 011E76DA3F3E604333

Issued by: cn=Povisa OCSP/TSA, ou=Informatica, o=Hospital POVISA, email=informatica@povisa.es, l=Vigo, street=Salamanca, 5, postalCode=36211, st=Galicia, c=ES

Error encountered in processing OCSP responder certificate DN: cn=Povisa OCSP-FNMT, ou=Informatica, o=Hospital POVISA, email=informatica@povisa.es, l=Vigo, street=Salamanca, 5, postalCode=36211, st=Galicia, c=ES Serial: 011E76DA3F3E604333

It seems clear to me that Adobe expects the OCSP signature to be signed by an Authorized Responder, this is not the case and Adobe sets the signature as not LTV because of this. How could I configure Adobe Reader to consider the self-signed certificate as an Authorized Responder for this CA?

[IsakTen-RwIoo2]

I am a bit confused with your 'How could I configure Adobe Reader to consider the self-signed certificate as an Authorized Responder for this CA?' What self-signed has to do with it? From the log you provided it looks like the OCSP that came from http://cosign.povisa.net:8777/adss/ocsp  was signed with the Povisa OCSP-FNMT certificate which was issued by the Povisa OCSP/TSA, It is the latter one that is self-signed (the root), not Povisa OCSP-FNMT, right?

Do you have 'Povisa OCSP/TSA' (the issuer of the certificate with which your OCSP was signed) trusted in Trusted Identities? If you don't then this could be the problem. If you do then I do not know what's going on. It is supposed to work. Some big companies use it. I do not have a setup for local configuration to check this out.

[alexperezbarreiro]

Let me give more details about the certificates involved:

chain of certificates we are using to sign the document:

CA (AC Raiz FNMT-RCM) --> ICA (AC FNMT Usuarios)--> EE

self-signed certificates used to sign the OCSP response and timestamping:

Internal CA (Povisa OCSP/TSA) --> OCSP Responder (Povisa OCSP-FNMT)

Internal CA (Povisa OCSP/TSA) --> TSA (Povisa TSA-FNMT)

As you can see the issuer of the certificate used to sign the OCSP response is different from the issuer of the EE certificate used to sign the document. This is not the recommended configuration, but I thought it was possible to trust as an Authorized Responder the internal CA (Povisa OCSP/TSA) to respond about the CA (AC Raiz FNMT-RCM) according to the RFC2560 and the Adobe documentation already mentioned, but I'm starting to doubt it.

Do you have 'Povisa OCSP/TSA' (the issuer of the certificate with which your OCSP was signed) trusted in Trusted Identities?

Yes, we have it in the Windows store and we trust the windows store in Adobe Reader

[IsakTen-RwIoo2]

Certificates used to sign the OCSP response and timestamping are not self-signed, their issuer (according to your info) is self-signed which is right as it is the root.

Does http://cosign.povisa.net:8777/adss/ocsp server provide OCSP for Povisa OCSP-FNMT? Acrobat performs validation of the signature over OCSP (CRL/Timestamp) and this includes revocation checking. The local configuration you defined applies, I think, to all revocation checkings (OCSP/CRL/Timestamp). If Acrobat cannot check revocation of the OCSP signature, it will invalidate it and reject OCSP. The Security\cASPKI\cAdobe_OCSPRevChecker\iReqRevCheck preference allows you to turn off revocation checking for the OCSP signature.

You mentioned that you are also using CustomCertPrefs. Is it the plan for the future and now you have local configuration in the global preferences, or do you have both? If you use both there could be some mismatch there. Try to start without CustomCertPrefs to figure it out.

Also, try to put Povisa OCSP/TSA in the Acrobat's Trusted Identities. The way you do it should work, but just in case as an experiment.

If none of these work, then I am out of ideas. Could be an Acrobat bug or an obscure design decision not to allow local configured OCSP responses in LTV. If nothing else works I'd consider it a bug, which suggest you report it to Acrobat Support.