KB Article #179841

Error: Unable to validate the response from the VA

Problem

The DV file log reports the error "Unable to validate the response from the VA" when using OCSP or OCSP(aia) as the validation protocol, similar to the following:


I: [01/Jan/2000 00:00:00.000 -0700] Certificate Revocation Status
Calling Application: certutil.exe
Certificate Name: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
Certificate Issuer: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
Certificate Serial Number: 04E1E7A4DC5CF2F36DC02B42B85D159F
Revocation Status: Unable to verify
Validation Protocol: OCSP(aia)
Validation Url: http://ocsp.digicert.com
Responder Key Hash: B13EC36903F8BF4701D498261A0802EF63642BC3
Error: Unable to validate the response from the VA
Transaction Id: 1528-3


Resolution


The error means that DV cannot find the OCSP signing certificate for the OCSP Responder. The fix is to go to CA Specific Validation Options in DV and to configure the OCSP method with the proper OCSP responder URL and the proper OCSP signing certificate.


The question then becomes, what is the proper OCSP signing certificate? There are three types of certificates that are permitted to sign OCSP responses according to the OCSP RFC:


  1. The CA that issued the certificate.
  2. A certificate delegated by the CA that signed the certificate.
  3. A certificate locally configured on the client.


The OCSP response itself may contain the OCSP signing certificate, but this is only typical for certificates delegated by the CA. It should not be done for certificates of the third type because there is no way you can trust it and it is unnecessary for certificates of the first type because you need to already have the CA in order to validate the certificate to begin with.


In the example given, ocsp.digicert.com is not returning a certificate and the responder key hash matches the fingerprint of the DigiCert High Assurance EV Root CA, which is the CA that issued this certificate. That indicates that the OCSP response was signed by the DigiCert High Assurance EV Root CA cert itself, so this is of the first type. For the OCSP AIA method, DV only checks the certificate included in the response, which we've already said only happens for certificates delegated by the CA. So we must configure CA Specific Validation Options, find the DigiCert High Assurance EV Root CA in the list, then configure the OCSP method against http://ocsp.digicert.com/ and then include a copy of the DigiCert High Assurance EV Root CA there, which is easily located with an internet search:

image93deabe1cf06d305ea1249d21a5cde45_000.png


The same is true of the other DigiCert CAs and each would need to be individually configured in the same manner, each with a different signing certificate matching the CA that is being configured. This is because a responder can sign OCSP responses for different CAs with different keys. In this case, ocsp.digicert.com is signing responses for each CA with that CA's certificate, which means that there's a different OCSP signing cert used for each CA.


In other cases, the owner of the responder must be contacted to supply a copy of the relevant OCSP signing certificates. In the case of VA Responders, if the certificate is not of type 2, it can also be obtained by using the vatest utility, e.g. vatest getconf -url http://SITE:PORT/ Refer to the Admin Guide and the output of vatest help getconf verbose for further details on usage. Finally, note that vatest attempts to write the certificate retrieved to the current directory. If you run it from a non-writeable directory, which normally includes the /Axway/VA/tools directory it is located in, it will fail with an fopen error. You can add the tools directory to your path and then call it from your home directory or desktop to deal with that.

Still need help?

If this information wasn't helpful to you, just drop us a line. We'll get back to you as soon as possible.