[Ejbca-develop] EJBCA OCSP Responder does not appear to be finding revoked certificates in large CRL?

[o h. <oh...@ya...>]

Hi,
As discussed in an earlier thread, it looks like I was able to import a large (> 71MB) CRL file into EJBCA (as an OCSP Responder), so now, I am doing testing, using "openssl ocsp" to send requests into the EJBCA OCSP Responder:
openssl ocsp -issuer <CA_CERT> -VAfile <SIGNING_CERT> -req_text -serial 0x<CERT_SERIAL> -host <HOST:PORT>

But it looks like no matter what serial number I use, whether the serial number is in the CRL or not, returns a response like:
OCSP Request Data:    Version: 1 (0x0)    Requestor List:        Certificate ID:          Hash Algorithm: sha1          Issuer Name Hash: 37...00          Issuer Key Hash: 39...E4          Serial Number: 2FFFF9    Request Extensions:        OCSP Nonce:            041078B1311984A110B5E19C8DC4895F485BResponse verify OK0x2FFFF9: unknown        This Update: Jun 28 18:56:20 2019 GMT
i.e., it looks like the EJBCA OCSP Responder is not able to actually find any revoked certs in the CRL?

FYI, I *KNOW* that the EJBCA OCSP Responder is functioning properly, in general, because I can do the same test against a smaller CRL in the same EJBCA OCSP Responder, for CA simpleca, and I can get an actual "Revoked" response:
[root@ejbca testocspresponder]# openssl ocsp -issuer simpleca.crt -VAfile simplecabinding2.crt -serial 0x008486394c03e1f5d9 -req_text -host 192.168.0.28:80OCSP Request Data:    Version: 1 (0x0)    Requestor List:        Certificate ID:          Hash Algorithm: sha1          Issuer Name Hash: 0C16107310427EA4ADB3C6436915CE44A15FFE55          Issuer Key Hash: E2533BF85F8C7CA60A411BF5458B2DC3B5232B6E          Serial Number: 8486394C03E1F5D9    Request Extensions:        OCSP Nonce:            04109A09CC1C56D26AA73CB4C3FB1EC7CF1FResponse verify OK0x008486394c03e1f5d9: revoked        This Update: Jun 28 19:12:48 2019 GMT        Reason: unspecified        Revocation Time: May 26 12:30:44 2019 GMT
So it seems like the EJBCA OCSP Responder is either not processing the large CRL properly, or maybe the import didn't import the large CRL into the OCSP Responder correctly.
Can anyone tell me how do I diagnose this problem?
Thanks,Jim