Digidocpp and OCSP error

[Antonio Araujo Brett]

Dear friends of esteid-devel, I hope all your activities are fine.
I am testing digidocpp with a certificate stored in a spanish ceres
smart card. The command to create a new BDOC file is the following:

$ digidoc-demo create --file=/tmp/CMakeLists.txt --profile=TM /tmp/
demo-container2.bdoc

When I issue the command I get an error from digidocpp:

...
ERROR [/home/aaraujo/desarrollo/estonia-reponuevo/libdigidocpp/trunk/
src/SignatureTM.cpp:272] - Failed to get OCSP response
...

This error is thrown by:
...
THROW_SIGNATUREEXCEPTION_CAUSE(e, "Failed to get OCSP response");
...

I read the code of SignatureTM.cpp and I could see that in line 263:

status = ocsp.checkCert(cert, issuer, nonce, ocspResponse,
producedAt);

the function checkCert:

digidoc::OCSP::checkCert(X509* cert, X509* issuer,
const std::vector<unsigned char>& nonce, std::vector<unsigned
char>& ocspResponseDER,
tm& producedAt) throw(IOException, OCSPException)

calls the function:

digidoc::OCSP::CertStatus digidoc::OCSP::checkCert(X509* cert, X509*
issuer,
const std::vector<unsigned char>& nonce, OCSP_REQUEST** req,
OCSP_RESPONSE** resp)
throw(IOException, OCSPException)

and this function calls (in OCSP.cpp):

digidoc::OCSP::CertStatus
digidoc::OCSP::validateResponse(OCSP_REQUEST* req, OCSP_RESPONSE*
resp, X509* cert, X509* issuer) throw(OCSPException)

Finally in this function, the following test fails:

// Check that response creation time is in valid time slot.
if(!OCSP_check_validity(thisUpdate, nextUpdate, skew, maxAge))

Could anyone help me to find out why the OpenSSL function
OCSP_check_validity fails? Do I have to change anything in my OCSP
configuration?. Could be a clock problem?. I run my OCSP server in the
same machine I am testing digidoc-demo.

Is this error listed in OCSP responses notes about time in RFC 2560?

4.2.2 Notes on OCSP Responses

4.2.2.1 Time

The thisUpdate and nextUpdate fields define a recommended validity
interval. This interval corresponds to the {thisUpdate, nextUpdate}
interval in CRLs. Responses whose nextUpdate value is earlier than
the local system time value SHOULD be considered unreliable.
Responses whose thisUpdate time is later than the local system time
SHOULD be considered unreliable. Responses where the nextUpdate
value
is not set are equivalent to a CRL with no time for nextUpdate (see
Section 2.4).

The producedAt time is the time at which this response was signed.


Best regards

Antonio Araujo Brett
Mérida, Venezuela