Here's the relevant part of OCSP 2560:
2.5 Response Pre-production
OCSP responders MAY pre-produce signed responses specifying the status of certificates at a specified time. The time at which the status was known to be correct SHALL be reflected in the thisUpdate field of the response. The time at or before which newer information will be available is reflected in the nextUpdate field, while the time at which the response was produced will appear in the producedAt field of the response.
What that means is that producedAt indicates when the OCSP response was actually produced. It has no bearing on the time period for which this OCSP response is valid. The Acrobat wording in the Certificate Viewer may be a bit off, but it conveys, IMO, the information the user needs, i.e. the starting time for this OCSP to be used.
I wouldnt mind if it was just the wording. But like I explained, since it considers (wrongly) the thisUpdate as the signing time, it validates that this signing time falls between the notBefore and notAfter values of the OCSP responder certificate. So it fails when thisUpdate is set before the ocsp certificate existence. If producedAt was used as the signing time (like the RFC describes), this error would probably not occur.
In other words, lets say we issue ocsp responders for short time periods, it seems they cannot produce responses with thisUpdate prior to their existence, even though they are using validation info directly from their parent CA (whose validation info dates back from the beginning). I dont see anything in the RFC which prohibits thisUpdate set to a time BEFORE the ocsp responser certificate notBefore (I may be wrong here).
I know this case is covered by the Archive Cutoff extension, but considering the thisUpdate as the signing time instead of producedAt looks like a bug IMO.
I think I just ran into this problem too. In my case users need to be able to validate PDF files off-line in a network environment where Internet access is prohibited. Also long-term archival is expected by embedding revocation information and protecting them with document time stamps.
What I found is that Adobe Acrobat Pro DC (version 15.006.30201) will nicely validate all signatures with embedded OCSP responses after they are created. However, the next day these validations fail, as Adobe wants to download revocation data which it obviously can't due to lack of Internet access. I go like "Why does it want to download revocation NOW when all embedded information was OK YESTERDAY?" Acrobat also wrote that OCSP response is expired. I digged into RFCs looking for expiry of OCSP responses but I couldn't find any (I only found NextUpdate which is NOT the expiry of the revocation information). So this means that latest Adobe products (both Acrobat and Reader DC) cannot handle OCSP responses rendering this type of revocation useless.
So it sure looks like a bug the way OCSP responses are handled. I wonder why not many others have come across this problem before?