Menu
▾
▴
Re: [Ejbca-develop] EJBCA OCSP Responder does not appear to
|
From: Tomas G. <to...@pr...> - 2019-07-18 14:32:22
|
Hi,
Just run create index script.
Create index should run pretty fast even with millions of records in the database. I suspect that your database is configured very slow, perhaps running everything on disl, without RAM, using slow disks?
A standard installation of mysql/mariadb on a centos machine should run faster. Then you have pretty low amount of ram for running everything on one box, handing millions of records.
Regards,
Tomas
On July 18, 2019 4:22:56 PM GMT+02:00, ohaya--- via Ejbca-develop <ejb...@li...> wrote:
> Hi,
>I had taken a snapshot of the machine before I tried to do the index
>earlier, so I restored that snapshot.
>Then, I tried running the "optimize-ejbca-mysql.sql" and I got a
>different/new error:
>ERROR 1091 (42000) at line 27: Can't DROP 'certificatedata_idx5'; check
>that column/key exists
>
>Jim
>
>
>
>
>
>
>On Thursday, July 18, 2019, 2:15:07 PM UTC, oh...@ya...
><oh...@ya...> wrote:
>
> Hi,
>Oh oh, I just got this from the mysql execution:
>ERROR 1071 (42000) at line 23: Specified key was too long; max key
>length is 1000 bytes
>
>Jim
>
>
>
>
>
>
>On Thursday, July 18, 2019, 2:09:26 PM UTC, oh...@ya...
><oh...@ya...> wrote:
>
> Hi,
>FYI, I am running the create-index-ejbca.sql script now, but that seems
>to be taking FOREVER?
>I had stopped the earlier import, and then deleted all the rows for
>that CA DN in CertificateData table, and then bounced the machine, then
>I ran the create-index-ejbca.sql.
>Why is it taking so long? Should I have done something in addition to
>deleting the rows? I am guessing that the reason the sql script is
>taking so long is that it's somehow still trying to index the rows were
>deleted or something like that?
>Thanks,Jim
>
>
>
>On Thursday, July 18, 2019, 1:52:53 PM UTC, oh...@ya...
><oh...@ya...> wrote:
>
> Hi,
>
>I notice that there is:
>- create-index-ejbca.sql
>- optimize-ejbca-mysql.sql
>Should I run BOTH of them, or just the "create-index-ejbca.sql "?
>Thanks,Jim
>
>
>On Thursday, July 18, 2019, 7:40:03 AM UTC, Tomas Gustavsson
><to...@pr...> wrote:
>
>Yes, i could see from your output from top that mysql takes all CPU.
>This indicates that you don't have any indexes in your database, which
>makes it horribly slow as numbers grow.
>
>Apply database indexes from doc/sql-scripts.
>
>Regards,
>Tomas
>
>
>On July 18, 2019 4:43:45 AM GMT+02:00, ohaya--- via Ejbca-develop
><ejb...@li...> wrote:
> Hi,
>So far, processed only 185706 entries, and it looks like the processing
>is going to a crawl (really slow now).
>Which kind of makes me wonder if maybe part of reason for the slowness
>is that it is having to search the certificate database for the serial
>number, and now, as there are more dummy certs in the database, that
>search is taking longer and longer?
>Jim
>
>On Wednesday, July 17, 2019, 6:03:37 PM UTC, ohaya--- via Ejbca-develop
><ejb...@li...> wrote:
>
> Hi,
>This is what top is showing now (the import is still running):
>top - 13:56:19 up 1 day, 1:09, 3 users, load average: 1.18, 1.11,
>1.07
>Tasks: 167 total, 2 running, 165 sleeping, 0 stopped, 0 zombie
>%Cpu(s): 47.4 us, 2.0 sy, 0.0 ni, 50.3 id, 0.0 wa, 0.0 hi, 0.3
>si, 0.0 st
>KiB Mem : 4045880 total, 123192 free, 3053072 used, 869616
>buff/cache
>KiB Swap: 3905532 total, 3753980 free, 151552 used. 688136 avail
>Mem
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
>COMMAND
> 1489 mysql 20 0 1580320 129624 4396 S 92.7 3.2 1227:41
>mysqld
> 3322 root 20 0 4031732 1.3g 7236 S 6.0 33.2 139:05.67
>java
> 3617 root 20 0 3546412 1.1g 7256 S 1.3 29.3 176:26.68
>java
>22466 root 20 0 0 0 0 S 0.7 0.0 0:00.73
>kworker/u4:1
>
>That is running on 2-CPU machine with 4GB RAM.
>Jim
>
>
>
>
>On Wednesday, July 17, 2019, 2:33:45 PM UTC, Tomas Gustavsson
><to...@pr...> wrote:
>
> Yes, like top.
>
>
>On July 17, 2019 3:52:53 PM GMT+02:00, ohaya--- via Ejbca-develop
><ejb...@li...> wrote:
> Hi Tomas,
>I'm sorry that I missed the message below, but I am not clear what you
>are asking me to check/monitor? Do you mean like running something
>like "top" command?
>Thanks,Jim
>
>On Tuesday, July 16, 2019, 7:43:45 PM UTC, Tomas Gustavsson
><to...@pr...> wrote:
>
> To verify that the changes actually happen...
>
>Do you monitor CPU usage to see what processes use CPU and memory?
>
>
>On July 16, 2019 8:52:37 PM GMT+02:00, ohaya--- via Ejbca-develop
><ejb...@li...> wrote:
> Hi,
>The import has been running for about an hour now and has imported
>17836 entries.
>Per what I had said previously, this CRL file has 1002255entries, that
>means it would take about 56+ hours to import this CRL.
>So, this import processing is still way too slow.
>I don't know what is involved, or even how much it would improve
>things, but I think that the next thing to try is to eliminated both
>the check for the serial number in the DB AND the dummy cert creation.
>Jim
>
>On Tuesday, July 16, 2019, 5:54:54 PM UTC, ohaya--- via Ejbca-develop
><ejb...@li...> wrote:
>
> Hi,
>Ok, I rebuilt the JAR using your Java class, and it is running now, and
>creating rows in the CertificateData, but it still SEEMS kind of slow.
>
>
>I am running now and will try to get a measurement of revoked
>entries/time and will post back.
>Jim
>
>
>
>On Tuesday, July 16, 2019, 5:25:32 PM UTC, oh...@ya...
><oh...@ya...> wrote:
>
> Hi,
>So I just tried what I said (emptying the "if") and you are right, it
>doesn't create the rows in the CeritificateData table :(...
>Ok, I will try your version...
>Jim
>
>On Tuesday, July 16, 2019, 3:57:31 PM UTC, Tomas Gustavsson
><to...@pr...> wrote:
>
>
>Hi,
>
>I don't think so, no quite actually. In order to use the API to
>populate
>the database you need the certificate object it seems. Something like
>the attached file should work, it still creates a dummy certificate,
>but
>uses a static hard coded key, so no key generation.
>
>The file assumes you are on 6.15.x.
>
>Regards,
>Tomas
>
>On 2019-07-16 15:02, ohaya--- via Ejbca-develop wrote:
>> For testing (only...), I am thinking that if I modify this If clause
>in
>> CaImportCrlCommand.java:
>>
>> if (adaptive)
>> {
>> Date time = new Date();
>> KeyPair key_pair = KeyTools.genKeys("2048", "RSA");
>>
>> SubjectPublicKeyInfo pkinfo =
>> SubjectPublicKeyInfo.getInstance(key_pair.getPublic().getEncoded());
>> X500Name dnName = new X500Name("CN=Dummy Missing in
>> Imported CRL, serialNumber=" + serialHex);
>> Date notAfter = new Date(time.getTime() +
>315360000000L);
>> X509v3CertificateBuilder certbuilder = new
>> X509v3CertificateBuilder(X500Name.getInstance(cacert
>> .getSubjectX500Principal().getEncoded()), serialNr,
>> time, notAfter, dnName, pkinfo);
>> ContentSigner signer = new BufferingContentSigner(new
>>
>JcaContentSignerBuilder("SHA1withRSA").setProvider("BC").build(key_pair
>> .getPrivate()), 20480);
>> X509CertificateHolder certHolder =
>certbuilder.build(signer);
>> X509Certificate certificate =
>>
>(X509Certificate)CertTools.getCertfromByteArray(certHolder.getEncoded(),
>> X509Certificate.class);
>>
>> String fingerprint =
>> CertTools.getFingerprintAsString(certificate);
>>
>> EndEntityInformation missingUserEndEntityInformation =
>>
>((EndEntityAccessSessionRemote)EjbRemoteHelper.INSTANCE.getRemoteSession(EndEntityAccessSessionRemote.class)).findUser(getAuthenticationToken(),
>> missing_user_name);
>> if (missingUserEndEntityInformation == null)
>> {
>> log.debug("Loading/updating user " +
>missing_user_name);
>>
>> EndEntityInformation userdataNew = new
>> EndEntityInformation(missing_user_name,
>> CertTools.getSubjectDN(certificate), cainfo.getCAId(), null, null,
>10,
>> new EndEntityType(EndEntityTypes.ENDUSER), 1, 1, null, null, 1, 0,
>null);
>>
>> userdataNew.setPassword("foo123");
>>
>>
>((EndEntityManagementSessionRemote)EjbRemoteHelper.INSTANCE.getRemoteSession(EndEntityManagementSessionRemote.class)).addUser(getAuthenticationToken(),
>> userdataNew, false);
>>
>> log.info("User '" + missing_user_name + "' has been
>> added.");
>>
>>
>((EndEntityManagementSessionRemote)EjbRemoteHelper.INSTANCE.getRemoteSession(EndEntityManagementSessionRemote.class)).setUserStatus(getAuthenticationToken(),
>> missing_user_name, 50);
>>
>> log.info("User '" + missing_user_name + "' has been
>> updated.");
>> }
>>
>>
>((CertificateStoreSessionRemote)EjbRemoteHelper.INSTANCE.getRemoteSession(CertificateStoreSessionRemote.class)).storeCertificateRemote(getAuthenticationToken(),
>>
>> EJBTools.wrap(certificate), missing_user_name,
>> fingerprint, 20, 1, 1, 0, null, new Date()
>>
>> .getTime());
>> log.info("Dummy certificate '" + serialHex + "' has
>been
>> stored.");
>> }
>>
>> to (for example):
>>
>> if (adaptive)
>> {
>>
>> log.info("*** SKIPPING *** Dummy certificate '" +
>> serialHex + "' has been stored.");
>> }
>>
>>
>> Would THAT work??
>>
>> Thanks,
>> Jim
>>
>>
>>
>>
>> On Tuesday, July 16, 2019, 10:59:31 AM UTC, ohaya--- via
>Ejbca-develop
>> <ejb...@li...> wrote:
>>
>>
>> Hi Tomas (or anyone else),
>>
>> Sorry - I was typing my last msg on phone, and it wasn't as detailed
>or
>> clear as I wanted.
>>
>> Basically what I was saying is I was thinking that, as a quick sanity
>> test, if there was one or two places where the code in
>> the CaImportCRLCommand.java was maybe making a method call to create
>the
>> dummy cert and put it into the database, then maybe I could decompile
>> and modify the CaImportCRLCommand.java, and comment out those method
>> calls, then, re-do my large CRL import test and time it?
>>
>> If so, can you let me know specifically where those calls are, and if
>I
>> just comment them out, would that work?
>>
>> Ironically, that (not doing the dummy cert creation and writing) was
>> what I *thought* the "LENIENT" option was doing).
>>
>> Thanks,
>> Jim
>>
>> P. S. I have time today to try this if I figure out what needs to be
>done.
>>
>>
>>
>> On Monday, July 15, 2019, 6:24:53 PM UTC, ohaya--- via Ejbca-develop
>> <ejb...@li...> wrote:
>>
>>
>>
>> Yes, we are definitely interested/willing to test patches. I
>actually
>> was wondering if it would be a quick test to mod the code somewhere
>to
>> avoid a call that creates the dummy cert, to get an idea if that
>would
>> reduce the import time enough??
>>
>>
>> Sent from Yahoo Mail on Android
>>
><https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>
>>
>> On Mon, Jul 15, 2019 at 12:10 PM, Tomas Gustavsson
>> <to...@pr...> wrote:
>> Most large users, some very very large, typically uses on line
>> updates directly from the CA. Many CAs today don't accept only
>> importing CRLs, as they need to keep track of issued certificates
>as
>> well not only revoked (can't use "non existing is good").
>> Having said thst, it's interesting to be able to import large
>CRLs,
>> so improving it is of interest.
>>
>> Importing CRLs would actually not have to generate a dummy cert at
>> all, since a certificate object is not needed on the responder,
>> which should make it very fast.
>>
>> If you are willing to test patches, we can work with you on
>improving.
>>
>> Regards,
>> Tomas
>>
>>
>> On July 15, 2019 5:26:08 PM GMT+02:00, ohaya--- via Ejbca-develop
>> <ejb...@li...> wrote:
>>
>> Hi,
>>
>> I am curious whether you have other users that import large
>CRLs
>> like this?
>>
>> Are we the only ones who would encounter these really long
>> import times, because the other users who might have large
>CRLs
>> use the EJBCA CA also, so they don't run into having the dummy
>> certs being created for every entry in the CRL?
>>
>> Jim
>>
>> On Monday, July 15, 2019, 1:42:57 PM UTC, Tomas Gustavsson
>> <to...@pr...> wrote:
>>
>>
>>
>> I see...
>>
>> I can see that a new key pair is being generated for each
>dummy
>> cert.
>>
>> In CaImportCRLCommand.java:
>>
>> final KeyPair key_pair = KeyTools.genKeys("2048",
>> AlgorithmConstants.KEYALGORITHM_RSA);
>>
>> Chaning that to 1024 or 512 would be an easy improvement. A
>bit more
>> complex, but even larger speedup would be to use a "hard
>coded"
>> dummy
>> key, i.e. same key for all dummy certs.
>>
>> You can experiment by changing 2048 to 512 (not secure but it
>> doesn't
>> have to be for this dummy cert).
>>
>> Regards,
>> Tomas
>>
>> On 2019-07-11 14:19, ohaya--- via Ejbca-develop wrote:
>> > FYI, the is running, but it is REALLY slow. The CRL file
>has
>> 1002255
>> > entries in it, and the import is only up to 8899 now, after
>> about 40
>> > minutes... which would take about 75 hours!!
>> >
>> > In our production systems, we are required to update some
>CRLs
>> every
>> > hour, so that would be a problem.
>> >
>> > What can I do to speed that up??
>> >
>> > Thanks,
>> > Jim
>> >
>> >
>> > On Thursday, July 11, 2019, 11:09:33 AM UTC, ohaya--- via
>> Ejbca-develop
>> > <ejb...@li...
>> <mailto:ejb...@li...>> wrote:
>> >
>> >
>> > AHHH... Ok, it is running now, and from checking the
>> CertificateData in
>> > the Mysql database, I can see that it is now populating the
>> > CertificateData!!
>> >
>> > Thanks!
>> >
>> > Jim
>> >
>> >
>> >
>> > On Thursday, July 11, 2019, 11:07:22 AM UTC, ohaya--- via
>> Ejbca-develop
>> > <ejb...@li...
>> <mailto:ejb...@li...>> wrote:
>> >
>> >
>> > I wasn't sure if we should use ADAPTIVE, since we are not
>> using the CA part.
>> >
>> >
>> > I will try with "-o ADAPTIVE" now.
>> >
>> >
>> >
>> >
>> > On Thursday, July 11, 2019, 7:42:14 AM UTC, Tomas Gustavsson
>> > <to...@pr... <mailto:to...@pr...>> wrote:
>> >
>> >
>> >
>> > It should be ADAPTIVE.
>> >
>> > The documentation says:
>> > bin/ejbca.sh ca importcrl --help
>> > ---
>> > ADAPTIVE means that missing certficates will be replaced by
>dummy
>> > certificates to cater for proper CRLs for missing
>certificates.
>> > ---
>> >
>> > Regards,
>> > Tomas
>> >
>> > On 2019-07-11 08:05, ohaya--- via Ejbca-develop wrote:
>> >> Hi,
>> >>
>> >> I've been looking at the code in CaImportCRLCommand, and I
>am
>> wondering
>> >> if, when the command is run in LENIENT mode and it doesn't
>> find the cert
>> >> in the database (and outputs the "missing in database"
>error
>> message),
>> >> what is supposed to happen?
>> >>
>> >> Mind you, the only error messages I am seeing are the
>"missing in
>> >> database" error messages. I don't see any of the other
>error
>> messages
>> >> that are in/from CaImportCRLCommand.java.
>> >>
>> >> I am wondering if, when the command is run with "-o
>LENIENT",
>> and when
>> >> it outputs the "missing in database" error message, then
>the
>> ejbca.sh is
>> >> basically not doing anything (and not storing anything into
>the
>> >> CertificateData table)?
>> >>
>> >> From the lack of any other error messages (vs. what I see
>in the
>> >> CaImportCRLCommand.java code), that is what it looks like
>is
>> happening.
>> >>
>> >> So given I am using EJBCA for OCSP responder only, is
>running the
>> >> ejbca.sh in the "-o LENIENT" mode correct?
>> >>
>> >> Jim
>> >>
>> >>
>> >>
>> >> On Thursday, July 11, 2019, 5:43:37 AM UTC, ohaya--- via
>> Ejbca-develop
>> >> <ejb...@li...
>> <mailto:ejb...@li...>
>> > <mailto:ejb...@li...
>> <mailto:ejb...@li...>>> wrote:
>> >>
>> >>
>> >> Hi,
>> >>
>> >> I've been doing a bunch of testing with trying to import
>the
>> large CRL,
>> >> and wanted to summarize:
>> >>
>> >> - The ejbca.sh runs fine - it completes without outputting
>an
>> errors,
>> >> except for outputting a bunch of the "cert xxxx missing in
>> database"
>> >> messages.
>> >>
>> >> - When the import completes, and I check the Mysql
>database,
>> the crlData
>> >> (the full PEM of the CRL) is in the database, but there is
>no
>> rows in
>> >> the CertificateData table for that CA at all.
>> >>
>> >> - I even figured out how to get the ejbca.sh to log using
>> >> log4j.properties, and it output a bunch of logging, mainly
>> the missing
>> >> in database errors, but other than that I didn't see any
>> obvious errors.
>> >>
>> >>
>> >> So, bottom line is that even though the ejbca.sh seems to
>run
>> without
>> >> errors (other than the missing in database errors), the
>import is
>> >> causing the CRL PEM to be stored in the database, but the
>> >> CertificateData table is not being populated at all for
>that CA.
>> >>
>> >>
>> >> Jim
>> >>
>> >>
>> >>
>> >> On Wednesday, July 10, 2019, 7:40:16 PM UTC, ohaya--- via
>> Ejbca-develop
>> >> <ejb...@li...
>> <mailto:ejb...@li...>
>> > <mailto:ejb...@li...
>> <mailto:ejb...@li...>>> wrote:
>> >>
>> >>
>> >> Hi,
>> >>
>> >> Ok, I found Tomas' original message... it was in my Spam
>> folder....
>> >>
>> >> I also tried re-running the "./ejbca.sh ca importcrl"
>command
>> a bunch of
>> >> ways. I think it is running without outputting any errors,
>> but still,
>> >> no rows are appearing with that issuerDN at all.
>> >>
>> >>
>> >>
>> >>
>> >> On Tuesday, July 9, 2019, 10:45:01 AM UTC, Tomas Gustavsson
>> >> <to...@pr... <mailto:to...@pr...>
>> <mailto:to...@pr... <mailto:to...@pr...>>> wrote:
>> >>
>> >>
>> >> Hi,
>> >>
>> >> OCSP responses does not have anything to do with the CRL
>> itself. Once
>> >> the CRL has been imported each certificate status is in its
>> own record
>> >> in the CertificateData table. This is where status is read
>> when reponses
>> >> are created.
>> >> If there are issues, it is in that case related to the
>import
>> of the CRL.
>> >>
>> >> Verify that certificate records are created in
>> CertificateData when
>> >> importing the CRL.
>> >> Also, a debug log when making OCSP request will tell exact
>> details of
>> >> what the responder finds in the database or not.
>> >>
>> >> Regards,
>> >> Tomas
>> >>
>> >>
>> >> On July 8, 2019 4:59:06 PM GMT+02:00, ohaya--- via
>Ejbca-develop
>> >> <ejb...@li...
>> <mailto:ejb...@li...>
>> > <mailto:ejb...@li...
>> <mailto:ejb...@li...>>> wrote:
>> >>
>> >> [Re-sending, as this (handling of large CRLs) is still a
>> problem and
>> >> is still not working.]
>> >>
>> >>
>> >>
>> >> On Monday, July 1, 2019, 12:47:23 PM UTC,
><oh...@ya...
>> <mailto:oh...@ya...>
>> > <mailto:oh...@ya... <mailto:oh...@ya...>>> wrote:
>> >>
>> >>
>> >> Hi,
>> >>
>> >> I think that I've found how to set/change the
>> max_allowed_packet on
>> >> the client (i.e., EJBCA) side, by editing the Mysql URL
>in the
>> >> standalone/configuration/standalone.xml to:
>> >>
>> >>
>> >
>>
><connection-url>jdbc:mysql://127.0.0.1:3306/ejbca?maxAllowedPacket=104857600</connection-url>
>> >>
>> >> However, when I test the OCSP Responder with a serial
>> number (and CA
>> >> cert) from the CA with the large (>71MB) CRL file, I am
>still
>> >> getting "unknown" and EJBCA OCSP Responder is still NOT
>> FINDING the
>> >> cert serial number.
>> >>
>> >> NOTE, again, that I can test with certs (and CA cert)
>that
>> have
>> >> smaller CRL files, and those tests work.
>> >>
>> >> So it is only when testing with the large CRL file that
>is
>> failing
>> >> with the OCSP Responder.
>> >>
>> >> This seems like a potential BUG for EJBCA OCSP
>Responder?
>> >>
>> >> Please advise.
>> >>
>> >> Thanks,
>> >> Jim
>> >> On Saturday, June 29, 2019, 3:36:18 PM EDT,
>> <oh...@ya... <mailto:oh...@ya...>
>> > <mailto:oh...@ya... <mailto:oh...@ya...>>> wrote:
>> >>
>> >>
>> >> Hi,
>> >>
>> >> BTW, just to check, I have actually gone through the
>> process of
>> >> getting the crlData from the MySQL using mysql client (I
>> had to add
>> >> the --max_allowed-packet=100M to the mysql command) and
>I
>> was able
>> >> to actually get the PEM from the Mysql database that
>way.
>> >>
>> >> So, I KNOW that the entire CRL is in the Mysql database,
>> and yet
>> >> when I run an "openssl ocsp" test against the EJBCA OCSP
>> Responder,
>> >> it says it cannot find the revocation.
>> >>
>> >> OCSP Request Data:
>> >> Version: 1 (0x0)
>> >> Requestor List:
>> >> Certificate ID:
>> >> Hash Algorithm: sha1
>> >> Issuer Name Hash:
>37E3972FD58A03EEC31D8DF5F6F03F6AE4F5C600
>> >> Issuer Key Hash:
>3929A80864E28F83AA816147119133F85A37A6E4
>> >> Serial Number: 2FFFF4
>> >> Request Extensions:
>> >> OCSP Nonce:
>> >> 04103054A60A55E389B239A55228033D8F62
>> >> Response verify OK
>> >> 0x2FFFF4: unknown
>> >> This Update: Jun 29 19:31:02 2019 GMT
>> >>
>> >>
>> >> In the server log:
>> >>
>> >> 2019-06-29 15:31:02,150 DEBUG
>> >>
>>
>[org.cesecore.certificates.ocsp.OcspResponseGeneratorSessionBean]
>> >> (default task-1) Unable to find revocation information
>for
>> >> certificate with serial '2ffff4' from issuer
>'CN=XXX....'
>> >>
>> >>
>> >> Honestly, I am no 100% sure that the problem is that
>> >> max_allowe_packet is too small on the mysql client side,
>> but that is
>> >> my best guess.
>> >>
>> >> What I AM sure is that the CRL is in mysql, but when I
>do
>> a test
>> >> with OCSP Responder, it cannot find the cert serial
>number
>> in the CRL.
>> >>
>> >> Jim
>> >>
>> >>
>> >> On Saturday, June 29, 2019, 4:52:20 AM EDT,
>> <oh...@ya... <mailto:oh...@ya...>
>> > <mailto:oh...@ya... <mailto:oh...@ya...>>> 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... <mailto:to...@pr...>
>> <mailto:to...@pr... <mailto: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... <mailto:oh...@ya...>
>> <mailto:oh...@ya... <mailto:oh...@ya...>>
>> >> <mailto:oh...@ya... <mailto:oh...@ya...>
>> <mailto:oh...@ya... <mailto: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 <mailto:root@ejbca> <mailto:root@ejbca
>> <mailto:root@ejbca>> <mailto:root@ejbca <mailto:root@ejbca>
>> > <mailto:root@ejbca <mailto: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...
>> <mailto:Ejb...@li...>
>> > <mailto:Ejb...@li...
>> <mailto:Ejb...@li...>>
>> >> <mailto:Ejb...@li...
>> <mailto:Ejb...@li...>
>> > <mailto:Ejb...@li...
>> <mailto:Ejb...@li...>>>
>> >> >
>https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>> >> >
>> >>
>> >>
>> >> _______________________________________________
>> >> Ejbca-develop mailing list
>> >> Ejb...@li...
>> <mailto:Ejb...@li...>
>> > <mailto:Ejb...@li...
>> <mailto:Ejb...@li...>>
>> >> <mailto:Ejb...@li...
>> <mailto:Ejb...@li...>
>> > <mailto:Ejb...@li...
>> <mailto:Ejb...@li...>>>
>> >>
>https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>> >>
>> >> _______________________________________________
>> >> Ejbca-develop mailing list
>> >> Ejb...@li...
>> <mailto:Ejb...@li...>
>> > <mailto:Ejb...@li...
>> <mailto:Ejb...@li...>>
>> >> <mailto:Ejb...@li...
>> <mailto:Ejb...@li...>
>> > <mailto:Ejb...@li...
>> <mailto:Ejb...@li...>>>
>> >> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>> >> _______________________________________________
>> >> Ejbca-develop mailing list
>> >> Ejb...@li...
>> <mailto:Ejb...@li...>
>> > <mailto:Ejb...@li...
>> <mailto:Ejb...@li...>>
>> >> <mailto:Ejb...@li...
>> <mailto:Ejb...@li...>
>> > <mailto:Ejb...@li...
>> <mailto:Ejb...@li...>>>
>> >
>> >> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>> >>
>> >>
>> >> _______________________________________________
>> >> Ejbca-develop mailing list
>> >> Ejb...@li...
>> <mailto:Ejb...@li...>
>> > <mailto:Ejb...@li...
>> <mailto:Ejb...@li...>>
>> >> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>> >>
>> >
>> >
>> > _______________________________________________
>> > Ejbca-develop mailing list
>> > Ejb...@li...
>> <mailto:Ejb...@li...>
>> > <mailto:Ejb...@li...
>> <mailto:Ejb...@li...>>
>> > https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>> > _______________________________________________
>> > Ejbca-develop mailing list
>> > Ejb...@li...
>> <mailto:Ejb...@li...>
>> > <mailto:Ejb...@li...
>> <mailto:Ejb...@li...>>
>> > https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>> > _______________________________________________
>> > Ejbca-develop mailing list
>> > Ejb...@li...
>> <mailto:Ejb...@li...>
>> > <mailto:Ejb...@li...
>> <mailto:Ejb...@li...>>
>> > https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>> >
>> >
>> > _______________________________________________
>> > Ejbca-develop mailing list
>> > Ejb...@li...
>> <mailto:Ejb...@li...>
>> > https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>> >
>>
>>
>> _______________________________________________
>> Ejbca-develop mailing list
>> Ejb...@li...
>> <mailto:Ejb...@li...>
>> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>>
>> _______________________________________________
>> Ejbca-develop mailing list
>> Ejb...@li...
>> <mailto:Ejb...@li...>
>> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>> _______________________________________________
>> Ejbca-develop mailing list
>> Ejb...@li...
>> <mailto:Ejb...@li...>
>> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>>
>>
>> _______________________________________________
>> 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
> _______________________________________________
>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
>
>
|
