|
From: Tomas G. <to...@pr...> - 2019-06-29 07:25:08
|
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 > |