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

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

 Hi Tomas,

I already had the max_allowed_packet configured on the Mysql server-side (in /etc/my.cnf).

So as I said, when testing with mysql (client) I had to include "--max_allowed_packet=100M" on the mysql (client) command line, e.g.:

mysql -u root -p --max_allowed_packet=100M

If I did NOT include the "--max_allowed_packet=100M" on that command line, then when I did a "select" on the field base64Crl, I would get an error.

I suspect that EJBCA is acting as a Mysql client, so, in order to work with such large CRLs, there needs to be some way to set the equivalent of the "--max_allowed_packet=100M" on the EJBCA side. 

How can I do that?

If that can't be done, then I think that when EJBCA tries to retrieve the CRL from the Mysql, it (EJBCA) will see the same error.

Thanks,
Jim

     On Saturday, June 29, 2019, 3:25:47 AM EDT, Tomas Gustavsson <to...@pr...> wrote:  
 
 
You configure max allowed packet size in you MySQL configuration on the
MySQL server.

/Tomas

On 2019-06-29 02:19, o haya via Ejbca-develop wrote:
> I am not 100% sure, but I think I know what might be causing this problem.
> 
> I did a test, where I just tried to log into mysql and do the following
> select:
> 
> select base64Crl INTO OUTFILE '/var/lib/mysql-files/xx.out' from CRLData
> where cRLNumber=3167; 
> 
> and I got an error saying that the result was more than max_allowed_packet.
> 
> So then I did the same thing, but for the mysql command I used:
> 
> mysql -u root -p --max_allowed_packet=100M
> 
> and then when I did that same select, I was able to output the entire
> CRL as a PEM.
> 
> So, I am theorizing that that is what is happening with EJBCA, i.e.,
> when I run the "openssl ocsp" command, EJBCA is querying the base64CRL
> but the result is too large and so that is causing the query to fail.
> 
> So the question now is:  How can I cause EJBCA OCSP Responder to run
> with a larger max_allowed_packet so that the query succeeds (and then
> hopefully EJBCA OCSP Responder will be able to check the revocation
> properly)?
> 
> Does anyone know how that can be done?
> 
> Thanks,
> Jim
> 
> 
> 
> 
> 
> 
> 
> On Friday, June 28, 2019, 07:16:39 PM UTC, o haya <oh...@ya...> wrote:
> 
> 
> 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:
>             041078B1311984A110B5E19C8DC4895F485B
> Response verify OK
> 0x2FFFF9: 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:80
> OCSP 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:
>             04109A09CC1C56D26AA73CB4C3FB1EC7CF1F
> Response verify OK
> 0x008486394c03e1f5d9: 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
> 
> 
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> 


_______________________________________________
Ejbca-develop mailing list
Ejb...@li...
https://lists.sourceforge.net/lists/listinfo/ejbca-develop