|
From: Tomas G. <to...@pr...> - 2019-06-29 09:51:38
|
The connection is handled by jboss. You have the database connection configured in jboss. It is not EJBCA itself that does that. Check the jboss data source config. /Tomas On June 29, 2019 10:52:15 AM GMT+02:00, ohaya--- via Ejbca-develop <ejb...@li...> wrote: > 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 > |