Menu
▾
▴
ejbca-develop — Development discussions
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(3) |
Feb
(2) |
Mar
(8) |
Apr
(3) |
May
(6) |
Jun
(1) |
Jul
(15) |
Aug
(6) |
Sep
|
Oct
(10) |
Nov
(2) |
Dec
(4) |
| 2003 |
Jan
(1) |
Feb
(7) |
Mar
(3) |
Apr
(6) |
May
(7) |
Jun
(5) |
Jul
(5) |
Aug
(25) |
Sep
(14) |
Oct
(2) |
Nov
|
Dec
(2) |
| 2004 |
Jan
(7) |
Feb
(4) |
Mar
(12) |
Apr
(16) |
May
(43) |
Jun
(56) |
Jul
(43) |
Aug
(40) |
Sep
(66) |
Oct
(12) |
Nov
(26) |
Dec
(10) |
| 2005 |
Jan
(13) |
Feb
(33) |
Mar
(16) |
Apr
(7) |
May
(10) |
Jun
(34) |
Jul
(41) |
Aug
(8) |
Sep
(4) |
Oct
(32) |
Nov
(20) |
Dec
(25) |
| 2006 |
Jan
(30) |
Feb
(101) |
Mar
(5) |
Apr
(75) |
May
(74) |
Jun
(22) |
Jul
(6) |
Aug
(70) |
Sep
(19) |
Oct
(21) |
Nov
(31) |
Dec
(50) |
| 2007 |
Jan
(15) |
Feb
(20) |
Mar
(24) |
Apr
(33) |
May
(13) |
Jun
(18) |
Jul
(13) |
Aug
(7) |
Sep
(63) |
Oct
(68) |
Nov
(29) |
Dec
(68) |
| 2008 |
Jan
(30) |
Feb
(33) |
Mar
(30) |
Apr
(103) |
May
(78) |
Jun
(48) |
Jul
(72) |
Aug
(24) |
Sep
(62) |
Oct
(63) |
Nov
(70) |
Dec
(37) |
| 2009 |
Jan
(34) |
Feb
(35) |
Mar
(64) |
Apr
(34) |
May
(34) |
Jun
(58) |
Jul
(30) |
Aug
(30) |
Sep
(46) |
Oct
(52) |
Nov
(12) |
Dec
(23) |
| 2010 |
Jan
(121) |
Feb
(18) |
Mar
(53) |
Apr
(62) |
May
(62) |
Jun
(20) |
Jul
(33) |
Aug
(20) |
Sep
(36) |
Oct
(35) |
Nov
(44) |
Dec
(63) |
| 2011 |
Jan
(19) |
Feb
(32) |
Mar
(94) |
Apr
(41) |
May
(47) |
Jun
(25) |
Jul
(34) |
Aug
(20) |
Sep
(9) |
Oct
(41) |
Nov
(33) |
Dec
(24) |
| 2012 |
Jan
(12) |
Feb
(36) |
Mar
(48) |
Apr
(32) |
May
(20) |
Jun
(15) |
Jul
(32) |
Aug
(13) |
Sep
(33) |
Oct
(54) |
Nov
(25) |
Dec
(16) |
| 2013 |
Jan
(45) |
Feb
(39) |
Mar
(38) |
Apr
(50) |
May
(29) |
Jun
(30) |
Jul
(33) |
Aug
(12) |
Sep
(9) |
Oct
(25) |
Nov
(29) |
Dec
(20) |
| 2014 |
Jan
(25) |
Feb
(19) |
Mar
(16) |
Apr
(33) |
May
(27) |
Jun
(37) |
Jul
(29) |
Aug
(27) |
Sep
(37) |
Oct
(58) |
Nov
(109) |
Dec
(26) |
| 2015 |
Jan
(4) |
Feb
(35) |
Mar
(22) |
Apr
(35) |
May
(28) |
Jun
(20) |
Jul
(4) |
Aug
(16) |
Sep
(37) |
Oct
(13) |
Nov
(13) |
Dec
(14) |
| 2016 |
Jan
(22) |
Feb
(7) |
Mar
(23) |
Apr
(30) |
May
(10) |
Jun
(10) |
Jul
(15) |
Aug
(12) |
Sep
(22) |
Oct
(31) |
Nov
(5) |
Dec
(5) |
| 2017 |
Jan
(30) |
Feb
(25) |
Mar
(28) |
Apr
(4) |
May
(19) |
Jun
(13) |
Jul
(7) |
Aug
(1) |
Sep
(2) |
Oct
(5) |
Nov
(12) |
Dec
(2) |
| 2018 |
Jan
(7) |
Feb
|
Mar
(7) |
Apr
(2) |
May
(8) |
Jun
(18) |
Jul
(6) |
Aug
(3) |
Sep
(15) |
Oct
(33) |
Nov
(13) |
Dec
(7) |
| 2019 |
Jan
(5) |
Feb
(7) |
Mar
(30) |
Apr
(5) |
May
(4) |
Jun
(69) |
Jul
(86) |
Aug
(22) |
Sep
(6) |
Oct
(7) |
Nov
(5) |
Dec
(3) |
| 2020 |
Jan
(10) |
Feb
(12) |
Mar
(22) |
Apr
(5) |
May
(1) |
Jun
(4) |
Jul
(6) |
Aug
|
Sep
(9) |
Oct
|
Nov
|
Dec
(1) |
| 2021 |
Jan
(4) |
Feb
(11) |
Mar
(7) |
Apr
(7) |
May
|
Jun
(3) |
Jul
(10) |
Aug
(6) |
Sep
|
Oct
|
Nov
(18) |
Dec
(2) |
| 2022 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <oh...@ya...> - 2019-07-11 05:43:22
|
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...> 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...> 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...> 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...> 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...> 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...> 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
_______________________________________________
Ejbca-develop mailing list
Ejb...@li...
https://lists.sourceforge.net/lists/listinfo/ejbca-develop
|
|
From: <oh...@ya...> - 2019-07-10 19:40:00
|
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...> 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...> 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...> 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...> 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...> 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
|
|
From: <oh...@ya...> - 2019-07-10 19:09:16
|
Joe,
Thanks for posting! FYI, for some reason, I never received the message that you replied to (from Tomas), so I will respond to him (and you) here....
Tomas,
FYI, I just checked the info in the CertificateData table and it looks like even though I just did the import, and it said it was good, there are no rows in the CertificateData table with issuerDN matching the DN of the CA that I imported.
In other words, it look like even though the import looked like it worked, nothing made it into the CertificateData table for that issuer.
As mentioned awhile ago, the command line I used was like:
./ejbca.sh ca importcrl "XXXXXXXX" "/home/jl/ejbcabuild/CRL-DOWNLOADER/crls/XXXXXXX.crl" -o LENIENT
and when I ran it, it output a bunch of lines with serial numbers that said that serial number was not in the database. I assumed that was because I was not using this as a CA, so the actual certs were not in the database, e.g.:
Certificate '218FAA' missing in the database
Certificate '10D9AD' missing in the database
Certificate '287AE' missing in the database
Certificate '14D298' missing in the database
Certificate '5A0B3' missing in the database
Certificate '18A98F' missing in the database
Certificate '23A593' missing in the database
Certificate '189EBD' missing in the database
Certificate '799A5' missing in the database
Certificate '12A8B0' missing in the database
So I am not sure why the CertificateData doesn't have any rows with issuerDN of that CA?
Does anyone know?
Thanks,Jim
On Wednesday, July 10, 2019, 3:50:57 PM UTC, Joe Browning <joe...@gm...> wrote:
Serial is hex, could it be case sensitive in mysql?0x prefix?this seems to suggest something like that? But mostly ...just a guess
"Unable to find revocation information for certificate with serial '2ffff4' "
Regards,Joe
On Tue, Jul 9, 2019, 06:45 Tomas Gustavsson <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...> 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...> 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...> 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...> 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
_______________________________________________
Ejbca-develop mailing list
Ejb...@li...
https://lists.sourceforge.net/lists/listinfo/ejbca-develop
|
|
From: Joe B. <joe...@gm...> - 2019-07-10 15:51:04
|
Serial is hex, could it be case sensitive in mysql? 0x prefix? this seems to suggest something like that? But mostly ...just a guess "Unable to find revocation information for certificate with serial '2ffff4' " Regards, Joe On Tue, Jul 9, 2019, 06:45 Tomas Gustavsson <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...> 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...> 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...> 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...> 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 >> >> _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
|
From: Tomas G. <to...@pr...> - 2019-07-09 10:45:04
|
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...> 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...> 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...> 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...> 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 > |
|
From: <oh...@ya...> - 2019-07-08 14:59:03
|
[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...> 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...> 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...> 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
|
|
From: <oh...@ya...> - 2019-07-01 12:47:26
|
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...> 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...> 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
|
|
From: <oh...@ya...> - 2019-06-29 19:36:12
|
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...> 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
|
|
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 > |
|
From: <oh...@ya...> - 2019-06-29 08:52:20
|
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
|
|
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 > |
|
From: o h. <oh...@ya...> - 2019-06-29 00:19:08
|
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: 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 |
|
From: o h. <oh...@ya...> - 2019-06-28 19:16:35
|
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 |
|
From: o h. <oh...@ya...> - 2019-06-28 18:19:40
|
Hi,
Finally!!
Summary:Revoked 0 certificatesThere were 1028870 certificates missing in the databaseCRL #3167 stored in the database
Summary, I had to modify the ejbca.sh to add "-Xms2g -Xmx2g" and also add "max_allowed_packet=72M" line to the /etc/my.cnf (to increase packet memory in Mysql server).
So I still would like to know how to cause the ejbca.sh to not spit out all of those messages about missing certs in the DB???? How to do that?
Thanks,Jim
On Friday, June 28, 2019, 05:14:22 PM UTC, o haya <oh...@ya...> wrote:
I spoke too soon :(!!
The program finished with this output:
Certificate '227E7E' missing in the databaseCertificate '355D78' missing in the databaseError: Failed to read response[root@ejbca bin]#
And in the Adminweb, that CA is still showing as NOT HAVING a CRL.
BUT, on the EJBCA server, the log had this:
13:04:54,158 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default task-1) 2019-06-28 13:04:54-04:00;ACCESS_CONTROL;SUCCESS;ACCESSCONTROL;CORE;ejbca;;;;resource0=/ca/116443389513:04:56,492 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default task-1) 2019-06-28 13:04:56-04:00;CRL_STORED;SUCCESS;CRL;CORE;ejbca;1164433895;;;msg=Stored CRL with CRLNumber=3167, fingerprint=1bdc4875f41e9e5d364c41e42247193e5f41b28c, issuerDN 'CN=XXXXXXXXXXX,...'.13:05:37,252 WARN [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-1) SQL Error: 0, SQLState: S100013:05:37,258 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-1) Packet for query is too large (74,450,611 > 4,194,304). You can change this value on the server by setting the 'max_allowed_packet' variable.13:05:37,578 ERROR [org.hibernate.internal.ExceptionMapperStandardImpl] (default task-1) HHH000346: Error during managed flush [org.hibernate.exception.GenericJDBCException: could not execute statement]13:05:37,608 WARN [com.arjuna.ats.arjuna] (default task-1) ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffffc0a8001c:-2208842d:5d162e1c:606, org.wildfly.transaction.client.AbstractTransaction$AssociatingSynchronization@63a7f3b8 >: javax.persistence.PersistenceException: org.hibernate.exception.GenericJDBCException: could not execute statement at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:154) at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:181) at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:188) at org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1460) at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:511) at org.hibernate.internal.SessionImpl.flushBeforeTransactionCompletion(SessionImpl.java:3283) at org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:2479) at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.beforeTransactionCompletion(JdbcCoordinatorImpl.java:473) at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.beforeCompletion(JtaTransactionCoordinatorImpl.java:352) at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.beforeCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:47) at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:37) at org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.beforeCompletion(JCAOrderedLastSynchronizationList.java:113) at org.wildfly.transaction.client.AbstractTransaction.performConsumer(AbstractTransaction.java:236) at org.wildfly.transaction.client.AbstractTransaction.performConsumer(AbstractTransaction.java:247) at org.wildfly.transaction.client.AbstractTransaction$AssociatingSynchronization.beforeCompletion(AbstractTransaction.java:292) at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:360) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91) at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1288) at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89) at org.wildfly.transaction.client.LocalTransaction.commitAndDissociate(LocalTransaction.java:77) at org.wildfly.transaction.client.ContextTransactionManager.commit(ContextTransactionManager.java:71) at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:88) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:261) at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:362) at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:144) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81) at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:619) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:382) at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:556) at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:537) at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:195) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) at java.lang.Thread.run(Thread.java:748)Caused by: org.hibernate.exception.GenericJDBCException: could not execute statement at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:47) at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:113) at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:99) at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:178) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3171) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3686) at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:90) at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:604) at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:478) at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:356) at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:39) at org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1454) ... 62 moreCaused by: com.mysql.cj.jdbc.exceptions.PacketTooBigException: Packet for query is too large (74,450,611 > 4,194,304). You can change this value on the server by setting the 'max_allowed_packet' variable. at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:107) at com.mysql.cj.jdbc.ClientPreparedStatement.executeInternal(ClientPreparedStatement.java:955) at com.mysql.cj.jdbc.ClientPreparedStatement.executeUpdateInternal(ClientPreparedStatement.java:1094) at com.mysql.cj.jdbc.ClientPreparedStatement.executeUpdateInternal(ClientPreparedStatement.java:1042) at com.mysql.cj.jdbc.ClientPreparedStatement.executeLargeUpdate(ClientPreparedStatement.java:1345) at com.mysql.cj.jdbc.ClientPreparedStatement.executeUpdate(ClientPreparedStatement.java:1027) at org.jboss.jca.adapters.jdbc.CachedPreparedStatement.executeUpdate(CachedPreparedStatement.java:121) at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:537) at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:175) ... 70 more
13:05:38,023 ERROR [org.jboss.as.ejb3.invocation] (default task-1) WFLYEJB0034: EJB Invocation failed on component CrlStoreSessionBean for method public abstract void org.cesecore.certificates.crl.CrlStoreSession.storeCRL(org.cesecore.authentication.tokens.AuthenticationToken,byte[],java.lang.String,int,java.lang.String,java.util.Date,java.util.Date,int) throws org.cesecore.certificates.crl.CrlStoreException,org.cesecore.authorization.AuthorizationDeniedException: javax.ejb.EJBTransactionRolledbackException: javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction. at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:114) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:261) at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:362) at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:144) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81) at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:619) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:382) at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:556) at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:537) at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:195) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) at java.lang.Thread.run(Thread.java:748)Caused by: javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction. at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1300) at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89) at org.wildfly.transaction.client.LocalTransaction.commitAndDissociate(LocalTransaction.java:77) at org.wildfly.transaction.client.ContextTransactionManager.commit(ContextTransactionManager.java:71) at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:88) ... 41 more Suppressed: javax.transaction.RollbackException: WFTXN0061: Transaction is marked rollback-only at org.wildfly.transaction.client.AbstractTransaction.setRollbackOnly(AbstractTransaction.java:96) at org.wildfly.transaction.client.LocalTransaction.setRollbackOnly(LocalTransaction.java:149) at org.wildfly.transaction.client.ContextTransactionManager.setRollbackOnly(ContextTransactionManager.java:94) at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionAdapterTransactionManagerImpl.markRollbackOnly(JtaTransactionAdapterTransactionManagerImpl.java:100) at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl$TransactionDriverControlImpl.markRollbackOnly(JtaTransactionCoordinatorImpl.java:456) at org.hibernate.engine.transaction.internal.TransactionImpl.markRollbackOnly(TransactionImpl.java:200) at org.hibernate.internal.AbstractSharedSessionContract.markForRollbackOnly(AbstractSharedSessionContract.java:378) at org.hibernate.internal.ExceptionConverterImpl.handlePersistenceException(ExceptionConverterImpl.java:297) at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:155) at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:181) at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:188) at org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1460) at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:511) at org.hibernate.internal.SessionImpl.flushBeforeTransactionCompletion(SessionImpl.java:3283) at org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:2479) at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.beforeTransactionCompletion(JdbcCoordinatorImpl.java:473) at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.beforeCompletion(JtaTransactionCoordinatorImpl.java:352) at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.beforeCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:47) at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:37) at org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.beforeCompletion(JCAOrderedLastSynchronizationList.java:113) at org.wildfly.transaction.client.AbstractTransaction.performConsumer(AbstractTransaction.java:236) at org.wildfly.transaction.client.AbstractTransaction.performConsumer(AbstractTransaction.java:247) at org.wildfly.transaction.client.AbstractTransaction$AssociatingSynchronization.beforeCompletion(AbstractTransaction.java:292) at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:360) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91) at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1288) ... 46 more Suppressed: javax.transaction.RollbackException: WFTXN0061: Transaction is marked rollback-only at org.wildfly.transaction.client.AbstractTransaction.setRollbackOnly(AbstractTransaction.java:96) at org.wildfly.transaction.client.LocalTransaction.setRollbackOnly(LocalTransaction.java:149) at org.wildfly.transaction.client.ContextTransactionManager.setRollbackOnly(ContextTransactionManager.java:94) at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionAdapterTransactionManagerImpl.markRollbackOnly(JtaTransactionAdapterTransactionManagerImpl.java:100) at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl$TransactionDriverControlImpl.markRollbackOnly(JtaTransactionCoordinatorImpl.java:456) at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.beforeCompletion(JtaTransactionCoordinatorImpl.java:359) at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.beforeCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:47) at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:37) at org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.beforeCompletion(JCAOrderedLastSynchronizationList.java:113) at org.wildfly.transaction.client.AbstractTransaction.performConsumer(AbstractTransaction.java:236) at org.wildfly.transaction.client.AbstractTransaction.performConsumer(AbstractTransaction.java:247) at org.wildfly.transaction.client.AbstractTransaction$AssociatingSynchronization.beforeCompletion(AbstractTransaction.java:292) at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:360) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91) at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1288) ... 46 moreCaused by: javax.persistence.PersistenceException: org.hibernate.exception.GenericJDBCException: could not execute statement at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:154) at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:181) at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:188) at org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1460) at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:511) at org.hibernate.internal.SessionImpl.flushBeforeTransactionCompletion(SessionImpl.java:3283) at org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:2479) at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.beforeTransactionCompletion(JdbcCoordinatorImpl.java:473) at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.beforeCompletion(JtaTransactionCoordinatorImpl.java:352) at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.beforeCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:47) at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:37) at org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.beforeCompletion(JCAOrderedLastSynchronizationList.java:113) at org.wildfly.transaction.client.AbstractTransaction.performConsumer(AbstractTransaction.java:236) at org.wildfly.transaction.client.AbstractTransaction.performConsumer(AbstractTransaction.java:247) at org.wildfly.transaction.client.AbstractTransaction$AssociatingSynchronization.beforeCompletion(AbstractTransaction.java:292) at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:360) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91) at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1288) ... 46 moreCaused by: org.hibernate.exception.GenericJDBCException: could not execute statement at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:47) at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:113) at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:99) at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:178) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3171) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3686) at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:90) at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:604) at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:478) at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:356) at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:39) at org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1454) ... 62 moreCaused by: com.mysql.cj.jdbc.exceptions.PacketTooBigException: Packet for query is too large (74,450,611 > 4,194,304). You can change this value on the server by setting the 'max_allowed_packet' variable. at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:107) at com.mysql.cj.jdbc.ClientPreparedStatement.executeInternal(ClientPreparedStatement.java:955) at com.mysql.cj.jdbc.ClientPreparedStatement.executeUpdateInternal(ClientPreparedStatement.java:1094) at com.mysql.cj.jdbc.ClientPreparedStatement.executeUpdateInternal(ClientPreparedStatement.java:1042) at com.mysql.cj.jdbc.ClientPreparedStatement.executeLargeUpdate(ClientPreparedStatement.java:1345) at com.mysql.cj.jdbc.ClientPreparedStatement.executeUpdate(ClientPreparedStatement.java:1027) at org.jboss.jca.adapters.jdbc.CachedPreparedStatement.executeUpdate(CachedPreparedStatement.java:121) at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:537) at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:175) ... 70 more
I guess that I don't understand something...?? I thought that EJBCA was being used by some organizations that had rather large CRLs already? If that is the case, then why am I running into this kind of problem now? What am I doing wrong?
Thanks,Jim
On Friday, June 28, 2019, 05:05:11 PM UTC, o haya <oh...@ya...> wrote:
Hi,
I modified the ejbca.sh file, to set -Xmx2g and -Xms2g and it (still) seems to be running, but it is spitting out a ton of messages like:
Certificate 'xxxx' missing in the database
This is even though I had set "-o LENIENT", which I thought meant that the program wouldn't care if the certificate in the CRL was not in the EJBCA database?
In our case, we are not using the EJBCA as CA, but rather just as an OCSP responder, so there will not be ANY certs in the EJBCA database, so is there a way to get the ejbca.sh to NOT spit out all of those "Certificate missing in database" messages?
I will report back after the program finishes...
Thanks,Jim
On Friday, June 28, 2019, 04:02:25 PM UTC, o haya <oh...@ya...> wrote:
AAAARGH!!!!
[root@ejbca bin]# ./ejbca.sh ca importcrl "XXXXCA_41" "/home/jl/ejbcabuild/XXX.crl" -o LENIENTCA: XXXXXException in thread "main" java.lang.OutOfMemoryError: Java heap space at java.util.Vector.<init>(Vector.java:138) at java.util.Vector.<init>(Vector.java:151) at java.util.Vector.<init>(Vector.java:160) at org.bouncycastle.asn1.ASN1EncodableVector.<init>(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildEncodableVector(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildDEREncodableVector(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildObject(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.readObject(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildEncodableVector(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildDEREncodableVector(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildObject(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.readObject(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildEncodableVector(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildDEREncodableVector(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildObject(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.readObject(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildEncodableVector(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildDEREncodableVector(Unknown Source)
On Friday, June 28, 2019, 03:50:26 PM UTC, o haya <oh...@ya...> wrote:
Hi,
The "importcrl" is running now, and is taking awhile, so it seems to be doing something.
Is there a way to DELETE the CRL from the DB? The reason for my question is that one of things I need to test and document for our project is memory usage with large CRLs, but I forgot to check the memory before I started the importcrl :(...
Thanks,Jim
On Friday, June 28, 2019, 03:37:07 PM UTC, o haya <oh...@ya...> wrote:
Tomas,
OOPS. Sorry. For some reason I am NOT receiving any emails from the mailing list, so I missed your response below. Maybe it is because of Firefox. Anyway I am typing this on Chrome this time.
I will try your suggestion and post back.
THANKS!!
Jim
On Friday, June 28, 2019, 01:41:52 PM UTC, Tomas Gustavsson <to...@pr...> wrote:
bin/ejbca.sh ca importcrl --help
Cheers,
Tomas
On 2019-06-28 15:37, ohaya--- via Ejbca-develop wrote:
> I think I found the command:
>
> [root@ejbca bin]# ./ejbca.sh ca getcrl --help
>
> GETCRL EJBCA CLI Commands Manual GETCRL
>
> NAME
> getcrl - Retrieves a CRL from a CA. Either the latest CRL or a CRL with
> a specified CRL number.
>
> SYNOPSIS
> getcrl <CA_NAME> <FILE_NAME> [OPTIONAL PARAMETERS]
> getcrl --caname <CA_NAME> -f <FILE_NAME> [OPTIONAL PARAMETERS]
>
> DESCRIPTION
> Retrieves a CRL from a CA. Either the latest CRL or a CRL with a
> specified CRL number.
>
> PARAMETERS
> Mandatory parameters:
> --caname <CA_NAME> (Switch is not required)
> The CA to get the CRL for.
> -f <FILE_NAME> (Switch is not required)
> The file to export to.
>
> Optional parameters:
> --clipassword <CLI_PASSWORD>
> Set the password explicitely in the command line with
> --clipassword=<password>
> --verbose
> Set this value for verbose output of parameter values.
> -crlnumber <CRL_NUMBER>
> Get CRL with the specified CRL number, instead of the latest. Used to read
> historical CRLs.
> -delta
> Fetch the latest delta CRL. Default is regular CRL.
> -p <User will be prompted, input will not be shown>
> Set this flag to be prompted for the username password
> -pem
> Use PEM encoding. Default is DER encoding.
> -u <CLI_USERNAME>
> Username for the CLI user, if required.
>
>
> I am going to try it now...
>
> Jim
>
>
> On Friday, June 28, 2019, 9:01:03 AM EDT, <oh...@ya...> wrote:
>
>
> You will DEFINITELY be missed!
>
> If you have time before you go, can you point me to how to use the CLI
> to import the CRL?
>
> Thanks,
> Jim
>
>
> On Friday, June 28, 2019, 8:30:17 AM EDT, Tomas Gustavsson
> <to...@pr...> wrote:
>
>
>
> I don't. Looks like the security filter (OWASP CSRFGuard) has a built in
> size limit for uploads. As you are using the Web UI for this, you may
> try the CLI instead as that does not go via the web interface.
>
> Cheers,
> Tomas
>
> PS: I will be away on vacation after today and will not be active in
> this list for a couple of weeks now.
>
> On 2019-06-28 14:24, ohaya--- via Ejbca-develop wrote:
>> Does anyone have any solution to this problem?
>>
>> Thanks,
>> Jim
>>
>>
>> On Thursday, June 27, 2019, 3:12:35 PM EDT, <oh...@ya...
> <mailto:oh...@ya...>> wrote:
>>
>>
>> Hi,
>>
>> I tried changing the <http-listener> in the standalone.xml to:
>>
>> <https-listener name="httpspub" socket-binding="httpspub"
>> max-post-size="100000000" max-parameters="2048" ssl-context="httpspub"/>
>> <https-listener name="httpspriv" socket-binding="httpspriv"
>> max-post-size="100000000" max-parameters="2048" ssl-context="httpspriv"/>
>>
>> and now when I try to import the CRL, I get:
>>
>> 14:53:10,355 ERROR [io.undertow.request] (default task-1) UT005023:
>> Exception handling request to /ejbca/adminweb/ca/cafunctions.jsp:
>> java.lang.IllegalArgumentException: byte limit exceeded: -58
>> at
>>
> org.owasp.csrfguard.MultipartFormData.decrementLimit(MultipartFormData.java:1339)
>> at
>>
> org.owasp.csrfguard.MultipartFormData.readData(MultipartFormData.java:1305)
>> at
>>
> org.owasp.csrfguard.MultipartFormData.readPart(MultipartFormData.java:1145)
>>
>>
>> On Thursday, June 27, 2019, 2:25:39 PM EDT, <oh...@ya...
> <mailto:oh...@ya...>> wrote:
>>
>>
>> Hi,
>>
>> I am trying to import a somewhat large (> 70MB) CRL into EJBCA, and when
>> I try that it is throwing an exception and outputting the following
>> stacktrace:
>>
>> 14:17:41,407 ERROR [stderr] (default task-1)
>> io.undertow.server.RequestTooBigException: UT000020: Connection
>> terminated as request was larger than 10485760
>> 14:17:41,408 ERROR [stderr] (default task-1) at
>>
> io.undertow.conduits.FixedLengthStreamSourceConduit.checkMaxSize(FixedLengthStreamSourceConduit.java:168)
>> 14:17:41,408 ERROR
>>
>> How can I import this CRL into EJBCA?
>>
>> Thanks,
>> Jim
>
>>
>>
>> _______________________________________________
>> 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
|
|
From: o h. <oh...@ya...> - 2019-06-28 17:14:27
|
I spoke too soon :(!!
The program finished with this output:
Certificate '227E7E' missing in the databaseCertificate '355D78' missing in the databaseError: Failed to read response[root@ejbca bin]#
And in the Adminweb, that CA is still showing as NOT HAVING a CRL.
BUT, on the EJBCA server, the log had this:
13:04:54,158 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default task-1) 2019-06-28 13:04:54-04:00;ACCESS_CONTROL;SUCCESS;ACCESSCONTROL;CORE;ejbca;;;;resource0=/ca/116443389513:04:56,492 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default task-1) 2019-06-28 13:04:56-04:00;CRL_STORED;SUCCESS;CRL;CORE;ejbca;1164433895;;;msg=Stored CRL with CRLNumber=3167, fingerprint=1bdc4875f41e9e5d364c41e42247193e5f41b28c, issuerDN 'CN=XXXXXXXXXXX,...'.13:05:37,252 WARN [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-1) SQL Error: 0, SQLState: S100013:05:37,258 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-1) Packet for query is too large (74,450,611 > 4,194,304). You can change this value on the server by setting the 'max_allowed_packet' variable.13:05:37,578 ERROR [org.hibernate.internal.ExceptionMapperStandardImpl] (default task-1) HHH000346: Error during managed flush [org.hibernate.exception.GenericJDBCException: could not execute statement]13:05:37,608 WARN [com.arjuna.ats.arjuna] (default task-1) ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffffc0a8001c:-2208842d:5d162e1c:606, org.wildfly.transaction.client.AbstractTransaction$AssociatingSynchronization@63a7f3b8 >: javax.persistence.PersistenceException: org.hibernate.exception.GenericJDBCException: could not execute statement at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:154) at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:181) at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:188) at org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1460) at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:511) at org.hibernate.internal.SessionImpl.flushBeforeTransactionCompletion(SessionImpl.java:3283) at org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:2479) at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.beforeTransactionCompletion(JdbcCoordinatorImpl.java:473) at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.beforeCompletion(JtaTransactionCoordinatorImpl.java:352) at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.beforeCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:47) at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:37) at org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.beforeCompletion(JCAOrderedLastSynchronizationList.java:113) at org.wildfly.transaction.client.AbstractTransaction.performConsumer(AbstractTransaction.java:236) at org.wildfly.transaction.client.AbstractTransaction.performConsumer(AbstractTransaction.java:247) at org.wildfly.transaction.client.AbstractTransaction$AssociatingSynchronization.beforeCompletion(AbstractTransaction.java:292) at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:360) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91) at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1288) at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89) at org.wildfly.transaction.client.LocalTransaction.commitAndDissociate(LocalTransaction.java:77) at org.wildfly.transaction.client.ContextTransactionManager.commit(ContextTransactionManager.java:71) at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:88) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:261) at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:362) at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:144) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81) at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:619) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:382) at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:556) at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:537) at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:195) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) at java.lang.Thread.run(Thread.java:748)Caused by: org.hibernate.exception.GenericJDBCException: could not execute statement at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:47) at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:113) at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:99) at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:178) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3171) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3686) at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:90) at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:604) at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:478) at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:356) at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:39) at org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1454) ... 62 moreCaused by: com.mysql.cj.jdbc.exceptions.PacketTooBigException: Packet for query is too large (74,450,611 > 4,194,304). You can change this value on the server by setting the 'max_allowed_packet' variable. at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:107) at com.mysql.cj.jdbc.ClientPreparedStatement.executeInternal(ClientPreparedStatement.java:955) at com.mysql.cj.jdbc.ClientPreparedStatement.executeUpdateInternal(ClientPreparedStatement.java:1094) at com.mysql.cj.jdbc.ClientPreparedStatement.executeUpdateInternal(ClientPreparedStatement.java:1042) at com.mysql.cj.jdbc.ClientPreparedStatement.executeLargeUpdate(ClientPreparedStatement.java:1345) at com.mysql.cj.jdbc.ClientPreparedStatement.executeUpdate(ClientPreparedStatement.java:1027) at org.jboss.jca.adapters.jdbc.CachedPreparedStatement.executeUpdate(CachedPreparedStatement.java:121) at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:537) at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:175) ... 70 more
13:05:38,023 ERROR [org.jboss.as.ejb3.invocation] (default task-1) WFLYEJB0034: EJB Invocation failed on component CrlStoreSessionBean for method public abstract void org.cesecore.certificates.crl.CrlStoreSession.storeCRL(org.cesecore.authentication.tokens.AuthenticationToken,byte[],java.lang.String,int,java.lang.String,java.util.Date,java.util.Date,int) throws org.cesecore.certificates.crl.CrlStoreException,org.cesecore.authorization.AuthorizationDeniedException: javax.ejb.EJBTransactionRolledbackException: javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction. at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:114) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:261) at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:362) at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:144) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81) at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:619) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:382) at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:556) at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:537) at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:195) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) at java.lang.Thread.run(Thread.java:748)Caused by: javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction. at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1300) at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89) at org.wildfly.transaction.client.LocalTransaction.commitAndDissociate(LocalTransaction.java:77) at org.wildfly.transaction.client.ContextTransactionManager.commit(ContextTransactionManager.java:71) at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:88) ... 41 more Suppressed: javax.transaction.RollbackException: WFTXN0061: Transaction is marked rollback-only at org.wildfly.transaction.client.AbstractTransaction.setRollbackOnly(AbstractTransaction.java:96) at org.wildfly.transaction.client.LocalTransaction.setRollbackOnly(LocalTransaction.java:149) at org.wildfly.transaction.client.ContextTransactionManager.setRollbackOnly(ContextTransactionManager.java:94) at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionAdapterTransactionManagerImpl.markRollbackOnly(JtaTransactionAdapterTransactionManagerImpl.java:100) at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl$TransactionDriverControlImpl.markRollbackOnly(JtaTransactionCoordinatorImpl.java:456) at org.hibernate.engine.transaction.internal.TransactionImpl.markRollbackOnly(TransactionImpl.java:200) at org.hibernate.internal.AbstractSharedSessionContract.markForRollbackOnly(AbstractSharedSessionContract.java:378) at org.hibernate.internal.ExceptionConverterImpl.handlePersistenceException(ExceptionConverterImpl.java:297) at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:155) at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:181) at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:188) at org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1460) at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:511) at org.hibernate.internal.SessionImpl.flushBeforeTransactionCompletion(SessionImpl.java:3283) at org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:2479) at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.beforeTransactionCompletion(JdbcCoordinatorImpl.java:473) at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.beforeCompletion(JtaTransactionCoordinatorImpl.java:352) at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.beforeCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:47) at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:37) at org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.beforeCompletion(JCAOrderedLastSynchronizationList.java:113) at org.wildfly.transaction.client.AbstractTransaction.performConsumer(AbstractTransaction.java:236) at org.wildfly.transaction.client.AbstractTransaction.performConsumer(AbstractTransaction.java:247) at org.wildfly.transaction.client.AbstractTransaction$AssociatingSynchronization.beforeCompletion(AbstractTransaction.java:292) at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:360) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91) at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1288) ... 46 more Suppressed: javax.transaction.RollbackException: WFTXN0061: Transaction is marked rollback-only at org.wildfly.transaction.client.AbstractTransaction.setRollbackOnly(AbstractTransaction.java:96) at org.wildfly.transaction.client.LocalTransaction.setRollbackOnly(LocalTransaction.java:149) at org.wildfly.transaction.client.ContextTransactionManager.setRollbackOnly(ContextTransactionManager.java:94) at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionAdapterTransactionManagerImpl.markRollbackOnly(JtaTransactionAdapterTransactionManagerImpl.java:100) at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl$TransactionDriverControlImpl.markRollbackOnly(JtaTransactionCoordinatorImpl.java:456) at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.beforeCompletion(JtaTransactionCoordinatorImpl.java:359) at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.beforeCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:47) at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:37) at org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.beforeCompletion(JCAOrderedLastSynchronizationList.java:113) at org.wildfly.transaction.client.AbstractTransaction.performConsumer(AbstractTransaction.java:236) at org.wildfly.transaction.client.AbstractTransaction.performConsumer(AbstractTransaction.java:247) at org.wildfly.transaction.client.AbstractTransaction$AssociatingSynchronization.beforeCompletion(AbstractTransaction.java:292) at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:360) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91) at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1288) ... 46 moreCaused by: javax.persistence.PersistenceException: org.hibernate.exception.GenericJDBCException: could not execute statement at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:154) at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:181) at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:188) at org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1460) at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:511) at org.hibernate.internal.SessionImpl.flushBeforeTransactionCompletion(SessionImpl.java:3283) at org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:2479) at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.beforeTransactionCompletion(JdbcCoordinatorImpl.java:473) at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.beforeCompletion(JtaTransactionCoordinatorImpl.java:352) at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.beforeCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:47) at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:37) at org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.beforeCompletion(JCAOrderedLastSynchronizationList.java:113) at org.wildfly.transaction.client.AbstractTransaction.performConsumer(AbstractTransaction.java:236) at org.wildfly.transaction.client.AbstractTransaction.performConsumer(AbstractTransaction.java:247) at org.wildfly.transaction.client.AbstractTransaction$AssociatingSynchronization.beforeCompletion(AbstractTransaction.java:292) at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:360) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91) at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1288) ... 46 moreCaused by: org.hibernate.exception.GenericJDBCException: could not execute statement at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:47) at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:113) at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:99) at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:178) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3171) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3686) at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:90) at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:604) at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:478) at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:356) at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:39) at org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1454) ... 62 moreCaused by: com.mysql.cj.jdbc.exceptions.PacketTooBigException: Packet for query is too large (74,450,611 > 4,194,304). You can change this value on the server by setting the 'max_allowed_packet' variable. at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:107) at com.mysql.cj.jdbc.ClientPreparedStatement.executeInternal(ClientPreparedStatement.java:955) at com.mysql.cj.jdbc.ClientPreparedStatement.executeUpdateInternal(ClientPreparedStatement.java:1094) at com.mysql.cj.jdbc.ClientPreparedStatement.executeUpdateInternal(ClientPreparedStatement.java:1042) at com.mysql.cj.jdbc.ClientPreparedStatement.executeLargeUpdate(ClientPreparedStatement.java:1345) at com.mysql.cj.jdbc.ClientPreparedStatement.executeUpdate(ClientPreparedStatement.java:1027) at org.jboss.jca.adapters.jdbc.CachedPreparedStatement.executeUpdate(CachedPreparedStatement.java:121) at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:537) at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:175) ... 70 more
I guess that I don't understand something...?? I thought that EJBCA was being used by some organizations that had rather large CRLs already? If that is the case, then why am I running into this kind of problem now? What am I doing wrong?
Thanks,Jim
On Friday, June 28, 2019, 05:05:11 PM UTC, o haya <oh...@ya...> wrote:
Hi,
I modified the ejbca.sh file, to set -Xmx2g and -Xms2g and it (still) seems to be running, but it is spitting out a ton of messages like:
Certificate 'xxxx' missing in the database
This is even though I had set "-o LENIENT", which I thought meant that the program wouldn't care if the certificate in the CRL was not in the EJBCA database?
In our case, we are not using the EJBCA as CA, but rather just as an OCSP responder, so there will not be ANY certs in the EJBCA database, so is there a way to get the ejbca.sh to NOT spit out all of those "Certificate missing in database" messages?
I will report back after the program finishes...
Thanks,Jim
On Friday, June 28, 2019, 04:02:25 PM UTC, o haya <oh...@ya...> wrote:
AAAARGH!!!!
[root@ejbca bin]# ./ejbca.sh ca importcrl "XXXXCA_41" "/home/jl/ejbcabuild/XXX.crl" -o LENIENTCA: XXXXXException in thread "main" java.lang.OutOfMemoryError: Java heap space at java.util.Vector.<init>(Vector.java:138) at java.util.Vector.<init>(Vector.java:151) at java.util.Vector.<init>(Vector.java:160) at org.bouncycastle.asn1.ASN1EncodableVector.<init>(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildEncodableVector(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildDEREncodableVector(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildObject(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.readObject(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildEncodableVector(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildDEREncodableVector(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildObject(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.readObject(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildEncodableVector(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildDEREncodableVector(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildObject(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.readObject(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildEncodableVector(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildDEREncodableVector(Unknown Source)
On Friday, June 28, 2019, 03:50:26 PM UTC, o haya <oh...@ya...> wrote:
Hi,
The "importcrl" is running now, and is taking awhile, so it seems to be doing something.
Is there a way to DELETE the CRL from the DB? The reason for my question is that one of things I need to test and document for our project is memory usage with large CRLs, but I forgot to check the memory before I started the importcrl :(...
Thanks,Jim
On Friday, June 28, 2019, 03:37:07 PM UTC, o haya <oh...@ya...> wrote:
Tomas,
OOPS. Sorry. For some reason I am NOT receiving any emails from the mailing list, so I missed your response below. Maybe it is because of Firefox. Anyway I am typing this on Chrome this time.
I will try your suggestion and post back.
THANKS!!
Jim
On Friday, June 28, 2019, 01:41:52 PM UTC, Tomas Gustavsson <to...@pr...> wrote:
bin/ejbca.sh ca importcrl --help
Cheers,
Tomas
On 2019-06-28 15:37, ohaya--- via Ejbca-develop wrote:
> I think I found the command:
>
> [root@ejbca bin]# ./ejbca.sh ca getcrl --help
>
> GETCRL EJBCA CLI Commands Manual GETCRL
>
> NAME
> getcrl - Retrieves a CRL from a CA. Either the latest CRL or a CRL with
> a specified CRL number.
>
> SYNOPSIS
> getcrl <CA_NAME> <FILE_NAME> [OPTIONAL PARAMETERS]
> getcrl --caname <CA_NAME> -f <FILE_NAME> [OPTIONAL PARAMETERS]
>
> DESCRIPTION
> Retrieves a CRL from a CA. Either the latest CRL or a CRL with a
> specified CRL number.
>
> PARAMETERS
> Mandatory parameters:
> --caname <CA_NAME> (Switch is not required)
> The CA to get the CRL for.
> -f <FILE_NAME> (Switch is not required)
> The file to export to.
>
> Optional parameters:
> --clipassword <CLI_PASSWORD>
> Set the password explicitely in the command line with
> --clipassword=<password>
> --verbose
> Set this value for verbose output of parameter values.
> -crlnumber <CRL_NUMBER>
> Get CRL with the specified CRL number, instead of the latest. Used to read
> historical CRLs.
> -delta
> Fetch the latest delta CRL. Default is regular CRL.
> -p <User will be prompted, input will not be shown>
> Set this flag to be prompted for the username password
> -pem
> Use PEM encoding. Default is DER encoding.
> -u <CLI_USERNAME>
> Username for the CLI user, if required.
>
>
> I am going to try it now...
>
> Jim
>
>
> On Friday, June 28, 2019, 9:01:03 AM EDT, <oh...@ya...> wrote:
>
>
> You will DEFINITELY be missed!
>
> If you have time before you go, can you point me to how to use the CLI
> to import the CRL?
>
> Thanks,
> Jim
>
>
> On Friday, June 28, 2019, 8:30:17 AM EDT, Tomas Gustavsson
> <to...@pr...> wrote:
>
>
>
> I don't. Looks like the security filter (OWASP CSRFGuard) has a built in
> size limit for uploads. As you are using the Web UI for this, you may
> try the CLI instead as that does not go via the web interface.
>
> Cheers,
> Tomas
>
> PS: I will be away on vacation after today and will not be active in
> this list for a couple of weeks now.
>
> On 2019-06-28 14:24, ohaya--- via Ejbca-develop wrote:
>> Does anyone have any solution to this problem?
>>
>> Thanks,
>> Jim
>>
>>
>> On Thursday, June 27, 2019, 3:12:35 PM EDT, <oh...@ya...
> <mailto:oh...@ya...>> wrote:
>>
>>
>> Hi,
>>
>> I tried changing the <http-listener> in the standalone.xml to:
>>
>> <https-listener name="httpspub" socket-binding="httpspub"
>> max-post-size="100000000" max-parameters="2048" ssl-context="httpspub"/>
>> <https-listener name="httpspriv" socket-binding="httpspriv"
>> max-post-size="100000000" max-parameters="2048" ssl-context="httpspriv"/>
>>
>> and now when I try to import the CRL, I get:
>>
>> 14:53:10,355 ERROR [io.undertow.request] (default task-1) UT005023:
>> Exception handling request to /ejbca/adminweb/ca/cafunctions.jsp:
>> java.lang.IllegalArgumentException: byte limit exceeded: -58
>> at
>>
> org.owasp.csrfguard.MultipartFormData.decrementLimit(MultipartFormData.java:1339)
>> at
>>
> org.owasp.csrfguard.MultipartFormData.readData(MultipartFormData.java:1305)
>> at
>>
> org.owasp.csrfguard.MultipartFormData.readPart(MultipartFormData.java:1145)
>>
>>
>> On Thursday, June 27, 2019, 2:25:39 PM EDT, <oh...@ya...
> <mailto:oh...@ya...>> wrote:
>>
>>
>> Hi,
>>
>> I am trying to import a somewhat large (> 70MB) CRL into EJBCA, and when
>> I try that it is throwing an exception and outputting the following
>> stacktrace:
>>
>> 14:17:41,407 ERROR [stderr] (default task-1)
>> io.undertow.server.RequestTooBigException: UT000020: Connection
>> terminated as request was larger than 10485760
>> 14:17:41,408 ERROR [stderr] (default task-1) at
>>
> io.undertow.conduits.FixedLengthStreamSourceConduit.checkMaxSize(FixedLengthStreamSourceConduit.java:168)
>> 14:17:41,408 ERROR
>>
>> How can I import this CRL into EJBCA?
>>
>> Thanks,
>> Jim
>
>>
>>
>> _______________________________________________
>> 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
|
|
From: o h. <oh...@ya...> - 2019-06-28 17:05:05
|
Hi,
I modified the ejbca.sh file, to set -Xmx2g and -Xms2g and it (still) seems to be running, but it is spitting out a ton of messages like:
Certificate 'xxxx' missing in the database
This is even though I had set "-o LENIENT", which I thought meant that the program wouldn't care if the certificate in the CRL was not in the EJBCA database?
In our case, we are not using the EJBCA as CA, but rather just as an OCSP responder, so there will not be ANY certs in the EJBCA database, so is there a way to get the ejbca.sh to NOT spit out all of those "Certificate missing in database" messages?
I will report back after the program finishes...
Thanks,Jim
On Friday, June 28, 2019, 04:02:25 PM UTC, o haya <oh...@ya...> wrote:
AAAARGH!!!!
[root@ejbca bin]# ./ejbca.sh ca importcrl "XXXXCA_41" "/home/jl/ejbcabuild/XXX.crl" -o LENIENTCA: XXXXXException in thread "main" java.lang.OutOfMemoryError: Java heap space at java.util.Vector.<init>(Vector.java:138) at java.util.Vector.<init>(Vector.java:151) at java.util.Vector.<init>(Vector.java:160) at org.bouncycastle.asn1.ASN1EncodableVector.<init>(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildEncodableVector(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildDEREncodableVector(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildObject(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.readObject(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildEncodableVector(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildDEREncodableVector(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildObject(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.readObject(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildEncodableVector(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildDEREncodableVector(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildObject(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.readObject(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildEncodableVector(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildDEREncodableVector(Unknown Source)
On Friday, June 28, 2019, 03:50:26 PM UTC, o haya <oh...@ya...> wrote:
Hi,
The "importcrl" is running now, and is taking awhile, so it seems to be doing something.
Is there a way to DELETE the CRL from the DB? The reason for my question is that one of things I need to test and document for our project is memory usage with large CRLs, but I forgot to check the memory before I started the importcrl :(...
Thanks,Jim
On Friday, June 28, 2019, 03:37:07 PM UTC, o haya <oh...@ya...> wrote:
Tomas,
OOPS. Sorry. For some reason I am NOT receiving any emails from the mailing list, so I missed your response below. Maybe it is because of Firefox. Anyway I am typing this on Chrome this time.
I will try your suggestion and post back.
THANKS!!
Jim
On Friday, June 28, 2019, 01:41:52 PM UTC, Tomas Gustavsson <to...@pr...> wrote:
bin/ejbca.sh ca importcrl --help
Cheers,
Tomas
On 2019-06-28 15:37, ohaya--- via Ejbca-develop wrote:
> I think I found the command:
>
> [root@ejbca bin]# ./ejbca.sh ca getcrl --help
>
> GETCRL EJBCA CLI Commands Manual GETCRL
>
> NAME
> getcrl - Retrieves a CRL from a CA. Either the latest CRL or a CRL with
> a specified CRL number.
>
> SYNOPSIS
> getcrl <CA_NAME> <FILE_NAME> [OPTIONAL PARAMETERS]
> getcrl --caname <CA_NAME> -f <FILE_NAME> [OPTIONAL PARAMETERS]
>
> DESCRIPTION
> Retrieves a CRL from a CA. Either the latest CRL or a CRL with a
> specified CRL number.
>
> PARAMETERS
> Mandatory parameters:
> --caname <CA_NAME> (Switch is not required)
> The CA to get the CRL for.
> -f <FILE_NAME> (Switch is not required)
> The file to export to.
>
> Optional parameters:
> --clipassword <CLI_PASSWORD>
> Set the password explicitely in the command line with
> --clipassword=<password>
> --verbose
> Set this value for verbose output of parameter values.
> -crlnumber <CRL_NUMBER>
> Get CRL with the specified CRL number, instead of the latest. Used to read
> historical CRLs.
> -delta
> Fetch the latest delta CRL. Default is regular CRL.
> -p <User will be prompted, input will not be shown>
> Set this flag to be prompted for the username password
> -pem
> Use PEM encoding. Default is DER encoding.
> -u <CLI_USERNAME>
> Username for the CLI user, if required.
>
>
> I am going to try it now...
>
> Jim
>
>
> On Friday, June 28, 2019, 9:01:03 AM EDT, <oh...@ya...> wrote:
>
>
> You will DEFINITELY be missed!
>
> If you have time before you go, can you point me to how to use the CLI
> to import the CRL?
>
> Thanks,
> Jim
>
>
> On Friday, June 28, 2019, 8:30:17 AM EDT, Tomas Gustavsson
> <to...@pr...> wrote:
>
>
>
> I don't. Looks like the security filter (OWASP CSRFGuard) has a built in
> size limit for uploads. As you are using the Web UI for this, you may
> try the CLI instead as that does not go via the web interface.
>
> Cheers,
> Tomas
>
> PS: I will be away on vacation after today and will not be active in
> this list for a couple of weeks now.
>
> On 2019-06-28 14:24, ohaya--- via Ejbca-develop wrote:
>> Does anyone have any solution to this problem?
>>
>> Thanks,
>> Jim
>>
>>
>> On Thursday, June 27, 2019, 3:12:35 PM EDT, <oh...@ya...
> <mailto:oh...@ya...>> wrote:
>>
>>
>> Hi,
>>
>> I tried changing the <http-listener> in the standalone.xml to:
>>
>> <https-listener name="httpspub" socket-binding="httpspub"
>> max-post-size="100000000" max-parameters="2048" ssl-context="httpspub"/>
>> <https-listener name="httpspriv" socket-binding="httpspriv"
>> max-post-size="100000000" max-parameters="2048" ssl-context="httpspriv"/>
>>
>> and now when I try to import the CRL, I get:
>>
>> 14:53:10,355 ERROR [io.undertow.request] (default task-1) UT005023:
>> Exception handling request to /ejbca/adminweb/ca/cafunctions.jsp:
>> java.lang.IllegalArgumentException: byte limit exceeded: -58
>> at
>>
> org.owasp.csrfguard.MultipartFormData.decrementLimit(MultipartFormData.java:1339)
>> at
>>
> org.owasp.csrfguard.MultipartFormData.readData(MultipartFormData.java:1305)
>> at
>>
> org.owasp.csrfguard.MultipartFormData.readPart(MultipartFormData.java:1145)
>>
>>
>> On Thursday, June 27, 2019, 2:25:39 PM EDT, <oh...@ya...
> <mailto:oh...@ya...>> wrote:
>>
>>
>> Hi,
>>
>> I am trying to import a somewhat large (> 70MB) CRL into EJBCA, and when
>> I try that it is throwing an exception and outputting the following
>> stacktrace:
>>
>> 14:17:41,407 ERROR [stderr] (default task-1)
>> io.undertow.server.RequestTooBigException: UT000020: Connection
>> terminated as request was larger than 10485760
>> 14:17:41,408 ERROR [stderr] (default task-1) at
>>
> io.undertow.conduits.FixedLengthStreamSourceConduit.checkMaxSize(FixedLengthStreamSourceConduit.java:168)
>> 14:17:41,408 ERROR
>>
>> How can I import this CRL into EJBCA?
>>
>> Thanks,
>> Jim
>
>>
>>
>> _______________________________________________
>> 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
|
|
From: o h. <oh...@ya...> - 2019-06-28 16:02:15
|
AAAARGH!!!!
[root@ejbca bin]# ./ejbca.sh ca importcrl "XXXXCA_41" "/home/jl/ejbcabuild/XXX.crl" -o LENIENTCA: XXXXXException in thread "main" java.lang.OutOfMemoryError: Java heap space at java.util.Vector.<init>(Vector.java:138) at java.util.Vector.<init>(Vector.java:151) at java.util.Vector.<init>(Vector.java:160) at org.bouncycastle.asn1.ASN1EncodableVector.<init>(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildEncodableVector(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildDEREncodableVector(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildObject(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.readObject(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildEncodableVector(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildDEREncodableVector(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildObject(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.readObject(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildEncodableVector(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildDEREncodableVector(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildObject(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.readObject(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildEncodableVector(Unknown Source) at org.bouncycastle.asn1.ASN1InputStream.buildDEREncodableVector(Unknown Source)
On Friday, June 28, 2019, 03:50:26 PM UTC, o haya <oh...@ya...> wrote:
Hi,
The "importcrl" is running now, and is taking awhile, so it seems to be doing something.
Is there a way to DELETE the CRL from the DB? The reason for my question is that one of things I need to test and document for our project is memory usage with large CRLs, but I forgot to check the memory before I started the importcrl :(...
Thanks,Jim
On Friday, June 28, 2019, 03:37:07 PM UTC, o haya <oh...@ya...> wrote:
Tomas,
OOPS. Sorry. For some reason I am NOT receiving any emails from the mailing list, so I missed your response below. Maybe it is because of Firefox. Anyway I am typing this on Chrome this time.
I will try your suggestion and post back.
THANKS!!
Jim
On Friday, June 28, 2019, 01:41:52 PM UTC, Tomas Gustavsson <to...@pr...> wrote:
bin/ejbca.sh ca importcrl --help
Cheers,
Tomas
On 2019-06-28 15:37, ohaya--- via Ejbca-develop wrote:
> I think I found the command:
>
> [root@ejbca bin]# ./ejbca.sh ca getcrl --help
>
> GETCRL EJBCA CLI Commands Manual GETCRL
>
> NAME
> getcrl - Retrieves a CRL from a CA. Either the latest CRL or a CRL with
> a specified CRL number.
>
> SYNOPSIS
> getcrl <CA_NAME> <FILE_NAME> [OPTIONAL PARAMETERS]
> getcrl --caname <CA_NAME> -f <FILE_NAME> [OPTIONAL PARAMETERS]
>
> DESCRIPTION
> Retrieves a CRL from a CA. Either the latest CRL or a CRL with a
> specified CRL number.
>
> PARAMETERS
> Mandatory parameters:
> --caname <CA_NAME> (Switch is not required)
> The CA to get the CRL for.
> -f <FILE_NAME> (Switch is not required)
> The file to export to.
>
> Optional parameters:
> --clipassword <CLI_PASSWORD>
> Set the password explicitely in the command line with
> --clipassword=<password>
> --verbose
> Set this value for verbose output of parameter values.
> -crlnumber <CRL_NUMBER>
> Get CRL with the specified CRL number, instead of the latest. Used to read
> historical CRLs.
> -delta
> Fetch the latest delta CRL. Default is regular CRL.
> -p <User will be prompted, input will not be shown>
> Set this flag to be prompted for the username password
> -pem
> Use PEM encoding. Default is DER encoding.
> -u <CLI_USERNAME>
> Username for the CLI user, if required.
>
>
> I am going to try it now...
>
> Jim
>
>
> On Friday, June 28, 2019, 9:01:03 AM EDT, <oh...@ya...> wrote:
>
>
> You will DEFINITELY be missed!
>
> If you have time before you go, can you point me to how to use the CLI
> to import the CRL?
>
> Thanks,
> Jim
>
>
> On Friday, June 28, 2019, 8:30:17 AM EDT, Tomas Gustavsson
> <to...@pr...> wrote:
>
>
>
> I don't. Looks like the security filter (OWASP CSRFGuard) has a built in
> size limit for uploads. As you are using the Web UI for this, you may
> try the CLI instead as that does not go via the web interface.
>
> Cheers,
> Tomas
>
> PS: I will be away on vacation after today and will not be active in
> this list for a couple of weeks now.
>
> On 2019-06-28 14:24, ohaya--- via Ejbca-develop wrote:
>> Does anyone have any solution to this problem?
>>
>> Thanks,
>> Jim
>>
>>
>> On Thursday, June 27, 2019, 3:12:35 PM EDT, <oh...@ya...
> <mailto:oh...@ya...>> wrote:
>>
>>
>> Hi,
>>
>> I tried changing the <http-listener> in the standalone.xml to:
>>
>> <https-listener name="httpspub" socket-binding="httpspub"
>> max-post-size="100000000" max-parameters="2048" ssl-context="httpspub"/>
>> <https-listener name="httpspriv" socket-binding="httpspriv"
>> max-post-size="100000000" max-parameters="2048" ssl-context="httpspriv"/>
>>
>> and now when I try to import the CRL, I get:
>>
>> 14:53:10,355 ERROR [io.undertow.request] (default task-1) UT005023:
>> Exception handling request to /ejbca/adminweb/ca/cafunctions.jsp:
>> java.lang.IllegalArgumentException: byte limit exceeded: -58
>> at
>>
> org.owasp.csrfguard.MultipartFormData.decrementLimit(MultipartFormData.java:1339)
>> at
>>
> org.owasp.csrfguard.MultipartFormData.readData(MultipartFormData.java:1305)
>> at
>>
> org.owasp.csrfguard.MultipartFormData.readPart(MultipartFormData.java:1145)
>>
>>
>> On Thursday, June 27, 2019, 2:25:39 PM EDT, <oh...@ya...
> <mailto:oh...@ya...>> wrote:
>>
>>
>> Hi,
>>
>> I am trying to import a somewhat large (> 70MB) CRL into EJBCA, and when
>> I try that it is throwing an exception and outputting the following
>> stacktrace:
>>
>> 14:17:41,407 ERROR [stderr] (default task-1)
>> io.undertow.server.RequestTooBigException: UT000020: Connection
>> terminated as request was larger than 10485760
>> 14:17:41,408 ERROR [stderr] (default task-1) at
>>
> io.undertow.conduits.FixedLengthStreamSourceConduit.checkMaxSize(FixedLengthStreamSourceConduit.java:168)
>> 14:17:41,408 ERROR
>>
>> How can I import this CRL into EJBCA?
>>
>> Thanks,
>> Jim
>
>>
>>
>> _______________________________________________
>> 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
|
|
From: o h. <oh...@ya...> - 2019-06-28 15:50:27
|
Hi,
The "importcrl" is running now, and is taking awhile, so it seems to be doing something.
Is there a way to DELETE the CRL from the DB? The reason for my question is that one of things I need to test and document for our project is memory usage with large CRLs, but I forgot to check the memory before I started the importcrl :(...
Thanks,Jim
On Friday, June 28, 2019, 03:37:07 PM UTC, o haya <oh...@ya...> wrote:
Tomas,
OOPS. Sorry. For some reason I am NOT receiving any emails from the mailing list, so I missed your response below. Maybe it is because of Firefox. Anyway I am typing this on Chrome this time.
I will try your suggestion and post back.
THANKS!!
Jim
On Friday, June 28, 2019, 01:41:52 PM UTC, Tomas Gustavsson <to...@pr...> wrote:
bin/ejbca.sh ca importcrl --help
Cheers,
Tomas
On 2019-06-28 15:37, ohaya--- via Ejbca-develop wrote:
> I think I found the command:
>
> [root@ejbca bin]# ./ejbca.sh ca getcrl --help
>
> GETCRL EJBCA CLI Commands Manual GETCRL
>
> NAME
> getcrl - Retrieves a CRL from a CA. Either the latest CRL or a CRL with
> a specified CRL number.
>
> SYNOPSIS
> getcrl <CA_NAME> <FILE_NAME> [OPTIONAL PARAMETERS]
> getcrl --caname <CA_NAME> -f <FILE_NAME> [OPTIONAL PARAMETERS]
>
> DESCRIPTION
> Retrieves a CRL from a CA. Either the latest CRL or a CRL with a
> specified CRL number.
>
> PARAMETERS
> Mandatory parameters:
> --caname <CA_NAME> (Switch is not required)
> The CA to get the CRL for.
> -f <FILE_NAME> (Switch is not required)
> The file to export to.
>
> Optional parameters:
> --clipassword <CLI_PASSWORD>
> Set the password explicitely in the command line with
> --clipassword=<password>
> --verbose
> Set this value for verbose output of parameter values.
> -crlnumber <CRL_NUMBER>
> Get CRL with the specified CRL number, instead of the latest. Used to read
> historical CRLs.
> -delta
> Fetch the latest delta CRL. Default is regular CRL.
> -p <User will be prompted, input will not be shown>
> Set this flag to be prompted for the username password
> -pem
> Use PEM encoding. Default is DER encoding.
> -u <CLI_USERNAME>
> Username for the CLI user, if required.
>
>
> I am going to try it now...
>
> Jim
>
>
> On Friday, June 28, 2019, 9:01:03 AM EDT, <oh...@ya...> wrote:
>
>
> You will DEFINITELY be missed!
>
> If you have time before you go, can you point me to how to use the CLI
> to import the CRL?
>
> Thanks,
> Jim
>
>
> On Friday, June 28, 2019, 8:30:17 AM EDT, Tomas Gustavsson
> <to...@pr...> wrote:
>
>
>
> I don't. Looks like the security filter (OWASP CSRFGuard) has a built in
> size limit for uploads. As you are using the Web UI for this, you may
> try the CLI instead as that does not go via the web interface.
>
> Cheers,
> Tomas
>
> PS: I will be away on vacation after today and will not be active in
> this list for a couple of weeks now.
>
> On 2019-06-28 14:24, ohaya--- via Ejbca-develop wrote:
>> Does anyone have any solution to this problem?
>>
>> Thanks,
>> Jim
>>
>>
>> On Thursday, June 27, 2019, 3:12:35 PM EDT, <oh...@ya...
> <mailto:oh...@ya...>> wrote:
>>
>>
>> Hi,
>>
>> I tried changing the <http-listener> in the standalone.xml to:
>>
>> <https-listener name="httpspub" socket-binding="httpspub"
>> max-post-size="100000000" max-parameters="2048" ssl-context="httpspub"/>
>> <https-listener name="httpspriv" socket-binding="httpspriv"
>> max-post-size="100000000" max-parameters="2048" ssl-context="httpspriv"/>
>>
>> and now when I try to import the CRL, I get:
>>
>> 14:53:10,355 ERROR [io.undertow.request] (default task-1) UT005023:
>> Exception handling request to /ejbca/adminweb/ca/cafunctions.jsp:
>> java.lang.IllegalArgumentException: byte limit exceeded: -58
>> at
>>
> org.owasp.csrfguard.MultipartFormData.decrementLimit(MultipartFormData.java:1339)
>> at
>>
> org.owasp.csrfguard.MultipartFormData.readData(MultipartFormData.java:1305)
>> at
>>
> org.owasp.csrfguard.MultipartFormData.readPart(MultipartFormData.java:1145)
>>
>>
>> On Thursday, June 27, 2019, 2:25:39 PM EDT, <oh...@ya...
> <mailto:oh...@ya...>> wrote:
>>
>>
>> Hi,
>>
>> I am trying to import a somewhat large (> 70MB) CRL into EJBCA, and when
>> I try that it is throwing an exception and outputting the following
>> stacktrace:
>>
>> 14:17:41,407 ERROR [stderr] (default task-1)
>> io.undertow.server.RequestTooBigException: UT000020: Connection
>> terminated as request was larger than 10485760
>> 14:17:41,408 ERROR [stderr] (default task-1) at
>>
> io.undertow.conduits.FixedLengthStreamSourceConduit.checkMaxSize(FixedLengthStreamSourceConduit.java:168)
>> 14:17:41,408 ERROR
>>
>> How can I import this CRL into EJBCA?
>>
>> Thanks,
>> Jim
>
>>
>>
>> _______________________________________________
>> 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
|
|
From: o h. <oh...@ya...> - 2019-06-28 15:36:59
|
Tomas,
OOPS. Sorry. For some reason I am NOT receiving any emails from the mailing list, so I missed your response below. Maybe it is because of Firefox. Anyway I am typing this on Chrome this time.
I will try your suggestion and post back.
THANKS!!
Jim
On Friday, June 28, 2019, 01:41:52 PM UTC, Tomas Gustavsson <to...@pr...> wrote:
bin/ejbca.sh ca importcrl --help
Cheers,
Tomas
On 2019-06-28 15:37, ohaya--- via Ejbca-develop wrote:
> I think I found the command:
>
> [root@ejbca bin]# ./ejbca.sh ca getcrl --help
>
> GETCRL EJBCA CLI Commands Manual GETCRL
>
> NAME
> getcrl - Retrieves a CRL from a CA. Either the latest CRL or a CRL with
> a specified CRL number.
>
> SYNOPSIS
> getcrl <CA_NAME> <FILE_NAME> [OPTIONAL PARAMETERS]
> getcrl --caname <CA_NAME> -f <FILE_NAME> [OPTIONAL PARAMETERS]
>
> DESCRIPTION
> Retrieves a CRL from a CA. Either the latest CRL or a CRL with a
> specified CRL number.
>
> PARAMETERS
> Mandatory parameters:
> --caname <CA_NAME> (Switch is not required)
> The CA to get the CRL for.
> -f <FILE_NAME> (Switch is not required)
> The file to export to.
>
> Optional parameters:
> --clipassword <CLI_PASSWORD>
> Set the password explicitely in the command line with
> --clipassword=<password>
> --verbose
> Set this value for verbose output of parameter values.
> -crlnumber <CRL_NUMBER>
> Get CRL with the specified CRL number, instead of the latest. Used to read
> historical CRLs.
> -delta
> Fetch the latest delta CRL. Default is regular CRL.
> -p <User will be prompted, input will not be shown>
> Set this flag to be prompted for the username password
> -pem
> Use PEM encoding. Default is DER encoding.
> -u <CLI_USERNAME>
> Username for the CLI user, if required.
>
>
> I am going to try it now...
>
> Jim
>
>
> On Friday, June 28, 2019, 9:01:03 AM EDT, <oh...@ya...> wrote:
>
>
> You will DEFINITELY be missed!
>
> If you have time before you go, can you point me to how to use the CLI
> to import the CRL?
>
> Thanks,
> Jim
>
>
> On Friday, June 28, 2019, 8:30:17 AM EDT, Tomas Gustavsson
> <to...@pr...> wrote:
>
>
>
> I don't. Looks like the security filter (OWASP CSRFGuard) has a built in
> size limit for uploads. As you are using the Web UI for this, you may
> try the CLI instead as that does not go via the web interface.
>
> Cheers,
> Tomas
>
> PS: I will be away on vacation after today and will not be active in
> this list for a couple of weeks now.
>
> On 2019-06-28 14:24, ohaya--- via Ejbca-develop wrote:
>> Does anyone have any solution to this problem?
>>
>> Thanks,
>> Jim
>>
>>
>> On Thursday, June 27, 2019, 3:12:35 PM EDT, <oh...@ya...
> <mailto:oh...@ya...>> wrote:
>>
>>
>> Hi,
>>
>> I tried changing the <http-listener> in the standalone.xml to:
>>
>> <https-listener name="httpspub" socket-binding="httpspub"
>> max-post-size="100000000" max-parameters="2048" ssl-context="httpspub"/>
>> <https-listener name="httpspriv" socket-binding="httpspriv"
>> max-post-size="100000000" max-parameters="2048" ssl-context="httpspriv"/>
>>
>> and now when I try to import the CRL, I get:
>>
>> 14:53:10,355 ERROR [io.undertow.request] (default task-1) UT005023:
>> Exception handling request to /ejbca/adminweb/ca/cafunctions.jsp:
>> java.lang.IllegalArgumentException: byte limit exceeded: -58
>> at
>>
> org.owasp.csrfguard.MultipartFormData.decrementLimit(MultipartFormData.java:1339)
>> at
>>
> org.owasp.csrfguard.MultipartFormData.readData(MultipartFormData.java:1305)
>> at
>>
> org.owasp.csrfguard.MultipartFormData.readPart(MultipartFormData.java:1145)
>>
>>
>> On Thursday, June 27, 2019, 2:25:39 PM EDT, <oh...@ya...
> <mailto:oh...@ya...>> wrote:
>>
>>
>> Hi,
>>
>> I am trying to import a somewhat large (> 70MB) CRL into EJBCA, and when
>> I try that it is throwing an exception and outputting the following
>> stacktrace:
>>
>> 14:17:41,407 ERROR [stderr] (default task-1)
>> io.undertow.server.RequestTooBigException: UT000020: Connection
>> terminated as request was larger than 10485760
>> 14:17:41,408 ERROR [stderr] (default task-1) at
>>
> io.undertow.conduits.FixedLengthStreamSourceConduit.checkMaxSize(FixedLengthStreamSourceConduit.java:168)
>> 14:17:41,408 ERROR
>>
>> How can I import this CRL into EJBCA?
>>
>> Thanks,
>> Jim
>
>>
>>
>> _______________________________________________
>> 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
|
|
From: <oh...@ya...> - 2019-06-28 15:33:16
|
Hi,
Ok, so I KNOW that this is going to be confusing, but I THINK that I found the reason for the NullPointerException below.
What I found was that one of the CAs (and the CA cert) that was there before, was GONE/DISAPPEARED. This was the "simpleca" CA, which I also used ot make the crypto token that was used for the OCSP binding.
So, I didn't know what else to try, so I imported that simpleCA cert back into EJBCA and "voila!", the token came back (and also some other CAs that had disappeared).
So anyway, I tried that "./ejbca.sh ca getcrl" command again and got the same result:
No CRL exists for CA XXXXCA_41.
and in the log I get the same error:
11:29:36,453 INFO [org.cesecore.certificates.crl.CrlStoreSessionBean] (default task-1) Error retrieving CRL for issuer 'CN=XXX,...,C=US' with CRL number 0.
NOW, looking at the error in the log, I am wondering "Why is that error saying 'with CRL number 0'?"???
Is that why it is failing, because there is no CRL number 0 in the EJBCA???
Anyone know why that is failing??
Thanks,
Jim
On Friday, June 28, 2019, 10:55:57 AM EDT, <oh...@ya...> wrote:
Hi,
I think that I should've included an earlier part of the log also, so here it is:
10:49:49,858 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default task-3) 2019-06-28 10:49:49-04:00;ACCESS_CONTROL;SUCCESS;ACCESSCONTROL;CORE;CN=SuperAdmin;;;;resource0=/administrator;resource1=/internalkeybinding/view
10:49:49,887 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default task-3) 2019-06-28 10:49:49-04:00;ACCESS_CONTROL;SUCCESS;ACCESSCONTROL;CORE;CN=SuperAdmin;;;;resource0=/administrator
10:49:49,979 INFO [org.cesecore.certificates.ca.CaSessionBean] (default task-3) CA with id -713150820 does not exist.
10:49:49,980 ERROR [io.undertow.request] (default task-3) UT005023: Exception handling request to /ejbca/adminweb/keybind/keybindings.jsp: javax.servlet.ServletException: /keybind/keybindings.jsp(68,1) '#{internalKeyBindingMBean.internalKeyBindingGuiList}' java.lang.NullPointerException
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:683)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
at org.ejbca.ui.web.admin.NoCacheFilter.doFilter(NoCacheFilter.java:68)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at org.owasp.filters.ContentSecurityPolicyFilter.doFilter(ContentSecurityPolicyFilter.java:216)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:357)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at org.ejbca.ui.web.admin.ProxiedAuthenticationFilter.doFilter(ProxiedAuthenticationFilter.java:104)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:55)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.apache.jasper.el.JspELException: /keybind/keybindings.jsp(68,1) '#{internalKeyBindingMBean.internalKeyBindingGuiList}' java.lang.NullPointerException
at org.apache.jasper.el.JspValueExpression.getValue(JspValueExpression.java:123)
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:200)
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:187)
at javax.faces.component.UIData.getValue(UIData.java:766)
at javax.faces.component.UIData.getDataModel(UIData.java:1880)
at javax.faces.component.UIData.setRowIndexWithoutRowStatePreserved(UIData.java:503)
at javax.faces.component.UIData.setRowIndex(UIData.java:492)
at com.sun.faces.renderkit.html_basic.TableRenderer.encodeBegin(TableRenderer.java:81)
at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:892)
at javax.faces.component.UIData.encodeBegin(UIData.java:1184)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1903)
at javax.faces.render.Renderer.encodeChildren(Renderer.java:176)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:918)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1905)
On Friday, June 28, 2019, 10:45:14 AM EDT, <oh...@ya...> wrote:
Hi,
FYI, I just noticed that if I try to go to the Internal Key Bindings=>OCSP Bindings, it is causing an Internal Server error, and in the log I am getting:
10:14:49,360 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /ejbca/adminweb/keybind/keybindings.jsp: javax.servlet.ServletException: /keybind/keybindings.jsp(68,1) '#{internalKeyBindingMBean.internalKeyBindingGuiList}' java.lang.NullPointerException
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:683)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
at org.ejbca.ui.web.admin.NoCacheFilter.doFilter(NoCacheFilter.java:68)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at org.owasp.filters.ContentSecurityPolicyFilter.doFilter(ContentSecurityPolicyFilter.java:216)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:357)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at org.ejbca.ui.web.admin.ProxiedAuthenticationFilter.doFilter(ProxiedAuthenticationFilter.java:104)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:55)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
On Friday, June 28, 2019, 10:03:28 AM EDT, <oh...@ya...> wrote:
Also, in the EJBCA/JBOSS stdoutput I am seeing:
10:00:17,862 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default task-3) 2019-06-28 10:00:17-04:00;ACCESS_CONTROL;SUCCESS;ACCESSCONTROL;CORE;ejbca;;;;resource0=/ca/1164433895
10:00:17,896 INFO [org.cesecore.certificates.crl.CrlStoreSessionBean] (default task-1) Error retrieving CRL for issuer 'CN=XXXCA-41,OU=PKI,OU=YYY,O=ZZZ,C=US' with CRL number 0.
Jim
On Friday, June 28, 2019, 9:49:42 AM EDT, <oh...@ya...> wrote:
Hi,
Actually, now I am not sure if this is the right command to *IMPORT* a CRL?
I tried:
./ejbca.sh ca getcrl --caname XXXCA_41 -f /home/jl/ejbcabuild/CRL-DOWNLOADER/crls/XXXCA_41.crl
and the response I got was:
No CRL exists for CA XXXCA_41.
????
On Friday, June 28, 2019, 9:37:27 AM EDT, <oh...@ya...> wrote:
I think I found the command:
[root@ejbca bin]# ./ejbca.sh ca getcrl --help
GETCRL EJBCA CLI Commands Manual GETCRL
NAME
getcrl - Retrieves a CRL from a CA. Either the latest CRL or a CRL with a specified CRL number.
SYNOPSIS
getcrl <CA_NAME> <FILE_NAME> [OPTIONAL PARAMETERS]
getcrl --caname <CA_NAME> -f <FILE_NAME> [OPTIONAL PARAMETERS]
DESCRIPTION
Retrieves a CRL from a CA. Either the latest CRL or a CRL with a specified CRL number.
PARAMETERS
Mandatory parameters:
--caname <CA_NAME> (Switch is not required)
The CA to get the CRL for.
-f <FILE_NAME> (Switch is not required)
The file to export to.
Optional parameters:
--clipassword <CLI_PASSWORD>
Set the password explicitely in the command line with --clipassword=<password>
--verbose
Set this value for verbose output of parameter values.
-crlnumber <CRL_NUMBER>
Get CRL with the specified CRL number, instead of the latest. Used to read
historical CRLs.
-delta
Fetch the latest delta CRL. Default is regular CRL.
-p <User will be prompted, input will not be shown>
Set this flag to be prompted for the username password
-pem
Use PEM encoding. Default is DER encoding.
-u <CLI_USERNAME>
Username for the CLI user, if required.
I am going to try it now...
Jim
On Friday, June 28, 2019, 9:01:03 AM EDT, <oh...@ya...> wrote:
You will DEFINITELY be missed!
If you have time before you go, can you point me to how to use the CLI to import the CRL?
Thanks,
Jim
On Friday, June 28, 2019, 8:30:17 AM EDT, Tomas Gustavsson <to...@pr...> wrote:
I don't. Looks like the security filter (OWASP CSRFGuard) has a built in
size limit for uploads. As you are using the Web UI for this, you may
try the CLI instead as that does not go via the web interface.
Cheers,
Tomas
PS: I will be away on vacation after today and will not be active in
this list for a couple of weeks now.
On 2019-06-28 14:24, ohaya--- via Ejbca-develop wrote:
> Does anyone have any solution to this problem?
>
> Thanks,
> Jim
>
>
> On Thursday, June 27, 2019, 3:12:35 PM EDT, <oh...@ya...> wrote:
>
>
> Hi,
>
> I tried changing the <http-listener> in the standalone.xml to:
>
> <https-listener name="httpspub" socket-binding="httpspub"
> max-post-size="100000000" max-parameters="2048" ssl-context="httpspub"/>
> <https-listener name="httpspriv" socket-binding="httpspriv"
> max-post-size="100000000" max-parameters="2048" ssl-context="httpspriv"/>
>
> and now when I try to import the CRL, I get:
>
> 14:53:10,355 ERROR [io.undertow.request] (default task-1) UT005023:
> Exception handling request to /ejbca/adminweb/ca/cafunctions.jsp:
> java.lang.IllegalArgumentException: byte limit exceeded: -58
> at
> org.owasp.csrfguard.MultipartFormData.decrementLimit(MultipartFormData.java:1339)
> at
> org.owasp.csrfguard.MultipartFormData.readData(MultipartFormData.java:1305)
> at
> org.owasp.csrfguard.MultipartFormData.readPart(MultipartFormData.java:1145)
>
>
> On Thursday, June 27, 2019, 2:25:39 PM EDT, <oh...@ya...> wrote:
>
>
> Hi,
>
> I am trying to import a somewhat large (> 70MB) CRL into EJBCA, and when
> I try that it is throwing an exception and outputting the following
> stacktrace:
>
> 14:17:41,407 ERROR [stderr] (default task-1)
> io.undertow.server.RequestTooBigException: UT000020: Connection
> terminated as request was larger than 10485760
> 14:17:41,408 ERROR [stderr] (default task-1) at
> io.undertow.conduits.FixedLengthStreamSourceConduit.checkMaxSize(FixedLengthStreamSourceConduit.java:168)
> 14:17:41,408 ERROR
>
> How can I import this CRL into EJBCA?
>
> 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
|
|
From: <oh...@ya...> - 2019-06-28 14:56:08
|
Hi,
I think that I should've included an earlier part of the log also, so here it is:
10:49:49,858 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default task-3) 2019-06-28 10:49:49-04:00;ACCESS_CONTROL;SUCCESS;ACCESSCONTROL;CORE;CN=SuperAdmin;;;;resource0=/administrator;resource1=/internalkeybinding/view
10:49:49,887 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default task-3) 2019-06-28 10:49:49-04:00;ACCESS_CONTROL;SUCCESS;ACCESSCONTROL;CORE;CN=SuperAdmin;;;;resource0=/administrator
10:49:49,979 INFO [org.cesecore.certificates.ca.CaSessionBean] (default task-3) CA with id -713150820 does not exist.
10:49:49,980 ERROR [io.undertow.request] (default task-3) UT005023: Exception handling request to /ejbca/adminweb/keybind/keybindings.jsp: javax.servlet.ServletException: /keybind/keybindings.jsp(68,1) '#{internalKeyBindingMBean.internalKeyBindingGuiList}' java.lang.NullPointerException
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:683)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
at org.ejbca.ui.web.admin.NoCacheFilter.doFilter(NoCacheFilter.java:68)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at org.owasp.filters.ContentSecurityPolicyFilter.doFilter(ContentSecurityPolicyFilter.java:216)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:357)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at org.ejbca.ui.web.admin.ProxiedAuthenticationFilter.doFilter(ProxiedAuthenticationFilter.java:104)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:55)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.apache.jasper.el.JspELException: /keybind/keybindings.jsp(68,1) '#{internalKeyBindingMBean.internalKeyBindingGuiList}' java.lang.NullPointerException
at org.apache.jasper.el.JspValueExpression.getValue(JspValueExpression.java:123)
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:200)
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:187)
at javax.faces.component.UIData.getValue(UIData.java:766)
at javax.faces.component.UIData.getDataModel(UIData.java:1880)
at javax.faces.component.UIData.setRowIndexWithoutRowStatePreserved(UIData.java:503)
at javax.faces.component.UIData.setRowIndex(UIData.java:492)
at com.sun.faces.renderkit.html_basic.TableRenderer.encodeBegin(TableRenderer.java:81)
at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:892)
at javax.faces.component.UIData.encodeBegin(UIData.java:1184)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1903)
at javax.faces.render.Renderer.encodeChildren(Renderer.java:176)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:918)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1905)
On Friday, June 28, 2019, 10:45:14 AM EDT, <oh...@ya...> wrote:
Hi,
FYI, I just noticed that if I try to go to the Internal Key Bindings=>OCSP Bindings, it is causing an Internal Server error, and in the log I am getting:
10:14:49,360 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /ejbca/adminweb/keybind/keybindings.jsp: javax.servlet.ServletException: /keybind/keybindings.jsp(68,1) '#{internalKeyBindingMBean.internalKeyBindingGuiList}' java.lang.NullPointerException
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:683)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
at org.ejbca.ui.web.admin.NoCacheFilter.doFilter(NoCacheFilter.java:68)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at org.owasp.filters.ContentSecurityPolicyFilter.doFilter(ContentSecurityPolicyFilter.java:216)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:357)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at org.ejbca.ui.web.admin.ProxiedAuthenticationFilter.doFilter(ProxiedAuthenticationFilter.java:104)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:55)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
On Friday, June 28, 2019, 10:03:28 AM EDT, <oh...@ya...> wrote:
Also, in the EJBCA/JBOSS stdoutput I am seeing:
10:00:17,862 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default task-3) 2019-06-28 10:00:17-04:00;ACCESS_CONTROL;SUCCESS;ACCESSCONTROL;CORE;ejbca;;;;resource0=/ca/1164433895
10:00:17,896 INFO [org.cesecore.certificates.crl.CrlStoreSessionBean] (default task-1) Error retrieving CRL for issuer 'CN=XXXCA-41,OU=PKI,OU=YYY,O=ZZZ,C=US' with CRL number 0.
Jim
On Friday, June 28, 2019, 9:49:42 AM EDT, <oh...@ya...> wrote:
Hi,
Actually, now I am not sure if this is the right command to *IMPORT* a CRL?
I tried:
./ejbca.sh ca getcrl --caname XXXCA_41 -f /home/jl/ejbcabuild/CRL-DOWNLOADER/crls/XXXCA_41.crl
and the response I got was:
No CRL exists for CA XXXCA_41.
????
On Friday, June 28, 2019, 9:37:27 AM EDT, <oh...@ya...> wrote:
I think I found the command:
[root@ejbca bin]# ./ejbca.sh ca getcrl --help
GETCRL EJBCA CLI Commands Manual GETCRL
NAME
getcrl - Retrieves a CRL from a CA. Either the latest CRL or a CRL with a specified CRL number.
SYNOPSIS
getcrl <CA_NAME> <FILE_NAME> [OPTIONAL PARAMETERS]
getcrl --caname <CA_NAME> -f <FILE_NAME> [OPTIONAL PARAMETERS]
DESCRIPTION
Retrieves a CRL from a CA. Either the latest CRL or a CRL with a specified CRL number.
PARAMETERS
Mandatory parameters:
--caname <CA_NAME> (Switch is not required)
The CA to get the CRL for.
-f <FILE_NAME> (Switch is not required)
The file to export to.
Optional parameters:
--clipassword <CLI_PASSWORD>
Set the password explicitely in the command line with --clipassword=<password>
--verbose
Set this value for verbose output of parameter values.
-crlnumber <CRL_NUMBER>
Get CRL with the specified CRL number, instead of the latest. Used to read
historical CRLs.
-delta
Fetch the latest delta CRL. Default is regular CRL.
-p <User will be prompted, input will not be shown>
Set this flag to be prompted for the username password
-pem
Use PEM encoding. Default is DER encoding.
-u <CLI_USERNAME>
Username for the CLI user, if required.
I am going to try it now...
Jim
On Friday, June 28, 2019, 9:01:03 AM EDT, <oh...@ya...> wrote:
You will DEFINITELY be missed!
If you have time before you go, can you point me to how to use the CLI to import the CRL?
Thanks,
Jim
On Friday, June 28, 2019, 8:30:17 AM EDT, Tomas Gustavsson <to...@pr...> wrote:
I don't. Looks like the security filter (OWASP CSRFGuard) has a built in
size limit for uploads. As you are using the Web UI for this, you may
try the CLI instead as that does not go via the web interface.
Cheers,
Tomas
PS: I will be away on vacation after today and will not be active in
this list for a couple of weeks now.
On 2019-06-28 14:24, ohaya--- via Ejbca-develop wrote:
> Does anyone have any solution to this problem?
>
> Thanks,
> Jim
>
>
> On Thursday, June 27, 2019, 3:12:35 PM EDT, <oh...@ya...> wrote:
>
>
> Hi,
>
> I tried changing the <http-listener> in the standalone.xml to:
>
> <https-listener name="httpspub" socket-binding="httpspub"
> max-post-size="100000000" max-parameters="2048" ssl-context="httpspub"/>
> <https-listener name="httpspriv" socket-binding="httpspriv"
> max-post-size="100000000" max-parameters="2048" ssl-context="httpspriv"/>
>
> and now when I try to import the CRL, I get:
>
> 14:53:10,355 ERROR [io.undertow.request] (default task-1) UT005023:
> Exception handling request to /ejbca/adminweb/ca/cafunctions.jsp:
> java.lang.IllegalArgumentException: byte limit exceeded: -58
> at
> org.owasp.csrfguard.MultipartFormData.decrementLimit(MultipartFormData.java:1339)
> at
> org.owasp.csrfguard.MultipartFormData.readData(MultipartFormData.java:1305)
> at
> org.owasp.csrfguard.MultipartFormData.readPart(MultipartFormData.java:1145)
>
>
> On Thursday, June 27, 2019, 2:25:39 PM EDT, <oh...@ya...> wrote:
>
>
> Hi,
>
> I am trying to import a somewhat large (> 70MB) CRL into EJBCA, and when
> I try that it is throwing an exception and outputting the following
> stacktrace:
>
> 14:17:41,407 ERROR [stderr] (default task-1)
> io.undertow.server.RequestTooBigException: UT000020: Connection
> terminated as request was larger than 10485760
> 14:17:41,408 ERROR [stderr] (default task-1) at
> io.undertow.conduits.FixedLengthStreamSourceConduit.checkMaxSize(FixedLengthStreamSourceConduit.java:168)
> 14:17:41,408 ERROR
>
> How can I import this CRL into EJBCA?
>
> 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
|
|
From: <oh...@ya...> - 2019-06-28 14:45:16
|
Hi,
FYI, I just noticed that if I try to go to the Internal Key Bindings=>OCSP Bindings, it is causing an Internal Server error, and in the log I am getting:
10:14:49,360 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /ejbca/adminweb/keybind/keybindings.jsp: javax.servlet.ServletException: /keybind/keybindings.jsp(68,1) '#{internalKeyBindingMBean.internalKeyBindingGuiList}' java.lang.NullPointerException
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:683)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
at org.ejbca.ui.web.admin.NoCacheFilter.doFilter(NoCacheFilter.java:68)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at org.owasp.filters.ContentSecurityPolicyFilter.doFilter(ContentSecurityPolicyFilter.java:216)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:357)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at org.ejbca.ui.web.admin.ProxiedAuthenticationFilter.doFilter(ProxiedAuthenticationFilter.java:104)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:55)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
On Friday, June 28, 2019, 10:03:28 AM EDT, <oh...@ya...> wrote:
Also, in the EJBCA/JBOSS stdoutput I am seeing:
10:00:17,862 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default task-3) 2019-06-28 10:00:17-04:00;ACCESS_CONTROL;SUCCESS;ACCESSCONTROL;CORE;ejbca;;;;resource0=/ca/1164433895
10:00:17,896 INFO [org.cesecore.certificates.crl.CrlStoreSessionBean] (default task-1) Error retrieving CRL for issuer 'CN=XXXCA-41,OU=PKI,OU=YYY,O=ZZZ,C=US' with CRL number 0.
Jim
On Friday, June 28, 2019, 9:49:42 AM EDT, <oh...@ya...> wrote:
Hi,
Actually, now I am not sure if this is the right command to *IMPORT* a CRL?
I tried:
./ejbca.sh ca getcrl --caname XXXCA_41 -f /home/jl/ejbcabuild/CRL-DOWNLOADER/crls/XXXCA_41.crl
and the response I got was:
No CRL exists for CA XXXCA_41.
????
On Friday, June 28, 2019, 9:37:27 AM EDT, <oh...@ya...> wrote:
I think I found the command:
[root@ejbca bin]# ./ejbca.sh ca getcrl --help
GETCRL EJBCA CLI Commands Manual GETCRL
NAME
getcrl - Retrieves a CRL from a CA. Either the latest CRL or a CRL with a specified CRL number.
SYNOPSIS
getcrl <CA_NAME> <FILE_NAME> [OPTIONAL PARAMETERS]
getcrl --caname <CA_NAME> -f <FILE_NAME> [OPTIONAL PARAMETERS]
DESCRIPTION
Retrieves a CRL from a CA. Either the latest CRL or a CRL with a specified CRL number.
PARAMETERS
Mandatory parameters:
--caname <CA_NAME> (Switch is not required)
The CA to get the CRL for.
-f <FILE_NAME> (Switch is not required)
The file to export to.
Optional parameters:
--clipassword <CLI_PASSWORD>
Set the password explicitely in the command line with --clipassword=<password>
--verbose
Set this value for verbose output of parameter values.
-crlnumber <CRL_NUMBER>
Get CRL with the specified CRL number, instead of the latest. Used to read
historical CRLs.
-delta
Fetch the latest delta CRL. Default is regular CRL.
-p <User will be prompted, input will not be shown>
Set this flag to be prompted for the username password
-pem
Use PEM encoding. Default is DER encoding.
-u <CLI_USERNAME>
Username for the CLI user, if required.
I am going to try it now...
Jim
On Friday, June 28, 2019, 9:01:03 AM EDT, <oh...@ya...> wrote:
You will DEFINITELY be missed!
If you have time before you go, can you point me to how to use the CLI to import the CRL?
Thanks,
Jim
On Friday, June 28, 2019, 8:30:17 AM EDT, Tomas Gustavsson <to...@pr...> wrote:
I don't. Looks like the security filter (OWASP CSRFGuard) has a built in
size limit for uploads. As you are using the Web UI for this, you may
try the CLI instead as that does not go via the web interface.
Cheers,
Tomas
PS: I will be away on vacation after today and will not be active in
this list for a couple of weeks now.
On 2019-06-28 14:24, ohaya--- via Ejbca-develop wrote:
> Does anyone have any solution to this problem?
>
> Thanks,
> Jim
>
>
> On Thursday, June 27, 2019, 3:12:35 PM EDT, <oh...@ya...> wrote:
>
>
> Hi,
>
> I tried changing the <http-listener> in the standalone.xml to:
>
> <https-listener name="httpspub" socket-binding="httpspub"
> max-post-size="100000000" max-parameters="2048" ssl-context="httpspub"/>
> <https-listener name="httpspriv" socket-binding="httpspriv"
> max-post-size="100000000" max-parameters="2048" ssl-context="httpspriv"/>
>
> and now when I try to import the CRL, I get:
>
> 14:53:10,355 ERROR [io.undertow.request] (default task-1) UT005023:
> Exception handling request to /ejbca/adminweb/ca/cafunctions.jsp:
> java.lang.IllegalArgumentException: byte limit exceeded: -58
> at
> org.owasp.csrfguard.MultipartFormData.decrementLimit(MultipartFormData.java:1339)
> at
> org.owasp.csrfguard.MultipartFormData.readData(MultipartFormData.java:1305)
> at
> org.owasp.csrfguard.MultipartFormData.readPart(MultipartFormData.java:1145)
>
>
> On Thursday, June 27, 2019, 2:25:39 PM EDT, <oh...@ya...> wrote:
>
>
> Hi,
>
> I am trying to import a somewhat large (> 70MB) CRL into EJBCA, and when
> I try that it is throwing an exception and outputting the following
> stacktrace:
>
> 14:17:41,407 ERROR [stderr] (default task-1)
> io.undertow.server.RequestTooBigException: UT000020: Connection
> terminated as request was larger than 10485760
> 14:17:41,408 ERROR [stderr] (default task-1) at
> io.undertow.conduits.FixedLengthStreamSourceConduit.checkMaxSize(FixedLengthStreamSourceConduit.java:168)
> 14:17:41,408 ERROR
>
> How can I import this CRL into EJBCA?
>
> 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
|
|
From: <oh...@ya...> - 2019-06-28 14:03:39
|
Also, in the EJBCA/JBOSS stdoutput I am seeing:
10:00:17,862 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default task-3) 2019-06-28 10:00:17-04:00;ACCESS_CONTROL;SUCCESS;ACCESSCONTROL;CORE;ejbca;;;;resource0=/ca/1164433895
10:00:17,896 INFO [org.cesecore.certificates.crl.CrlStoreSessionBean] (default task-1) Error retrieving CRL for issuer 'CN=XXXCA-41,OU=PKI,OU=YYY,O=ZZZ,C=US' with CRL number 0.
Jim
On Friday, June 28, 2019, 9:49:42 AM EDT, <oh...@ya...> wrote:
Hi,
Actually, now I am not sure if this is the right command to *IMPORT* a CRL?
I tried:
./ejbca.sh ca getcrl --caname XXXCA_41 -f /home/jl/ejbcabuild/CRL-DOWNLOADER/crls/XXXCA_41.crl
and the response I got was:
No CRL exists for CA XXXCA_41.
????
On Friday, June 28, 2019, 9:37:27 AM EDT, <oh...@ya...> wrote:
I think I found the command:
[root@ejbca bin]# ./ejbca.sh ca getcrl --help
GETCRL EJBCA CLI Commands Manual GETCRL
NAME
getcrl - Retrieves a CRL from a CA. Either the latest CRL or a CRL with a specified CRL number.
SYNOPSIS
getcrl <CA_NAME> <FILE_NAME> [OPTIONAL PARAMETERS]
getcrl --caname <CA_NAME> -f <FILE_NAME> [OPTIONAL PARAMETERS]
DESCRIPTION
Retrieves a CRL from a CA. Either the latest CRL or a CRL with a specified CRL number.
PARAMETERS
Mandatory parameters:
--caname <CA_NAME> (Switch is not required)
The CA to get the CRL for.
-f <FILE_NAME> (Switch is not required)
The file to export to.
Optional parameters:
--clipassword <CLI_PASSWORD>
Set the password explicitely in the command line with --clipassword=<password>
--verbose
Set this value for verbose output of parameter values.
-crlnumber <CRL_NUMBER>
Get CRL with the specified CRL number, instead of the latest. Used to read
historical CRLs.
-delta
Fetch the latest delta CRL. Default is regular CRL.
-p <User will be prompted, input will not be shown>
Set this flag to be prompted for the username password
-pem
Use PEM encoding. Default is DER encoding.
-u <CLI_USERNAME>
Username for the CLI user, if required.
I am going to try it now...
Jim
On Friday, June 28, 2019, 9:01:03 AM EDT, <oh...@ya...> wrote:
You will DEFINITELY be missed!
If you have time before you go, can you point me to how to use the CLI to import the CRL?
Thanks,
Jim
On Friday, June 28, 2019, 8:30:17 AM EDT, Tomas Gustavsson <to...@pr...> wrote:
I don't. Looks like the security filter (OWASP CSRFGuard) has a built in
size limit for uploads. As you are using the Web UI for this, you may
try the CLI instead as that does not go via the web interface.
Cheers,
Tomas
PS: I will be away on vacation after today and will not be active in
this list for a couple of weeks now.
On 2019-06-28 14:24, ohaya--- via Ejbca-develop wrote:
> Does anyone have any solution to this problem?
>
> Thanks,
> Jim
>
>
> On Thursday, June 27, 2019, 3:12:35 PM EDT, <oh...@ya...> wrote:
>
>
> Hi,
>
> I tried changing the <http-listener> in the standalone.xml to:
>
> <https-listener name="httpspub" socket-binding="httpspub"
> max-post-size="100000000" max-parameters="2048" ssl-context="httpspub"/>
> <https-listener name="httpspriv" socket-binding="httpspriv"
> max-post-size="100000000" max-parameters="2048" ssl-context="httpspriv"/>
>
> and now when I try to import the CRL, I get:
>
> 14:53:10,355 ERROR [io.undertow.request] (default task-1) UT005023:
> Exception handling request to /ejbca/adminweb/ca/cafunctions.jsp:
> java.lang.IllegalArgumentException: byte limit exceeded: -58
> at
> org.owasp.csrfguard.MultipartFormData.decrementLimit(MultipartFormData.java:1339)
> at
> org.owasp.csrfguard.MultipartFormData.readData(MultipartFormData.java:1305)
> at
> org.owasp.csrfguard.MultipartFormData.readPart(MultipartFormData.java:1145)
>
>
> On Thursday, June 27, 2019, 2:25:39 PM EDT, <oh...@ya...> wrote:
>
>
> Hi,
>
> I am trying to import a somewhat large (> 70MB) CRL into EJBCA, and when
> I try that it is throwing an exception and outputting the following
> stacktrace:
>
> 14:17:41,407 ERROR [stderr] (default task-1)
> io.undertow.server.RequestTooBigException: UT000020: Connection
> terminated as request was larger than 10485760
> 14:17:41,408 ERROR [stderr] (default task-1) at
> io.undertow.conduits.FixedLengthStreamSourceConduit.checkMaxSize(FixedLengthStreamSourceConduit.java:168)
> 14:17:41,408 ERROR
>
> How can I import this CRL into EJBCA?
>
> 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
|
|
From: <oh...@ya...> - 2019-06-28 13:49:43
|
Hi,
Actually, now I am not sure if this is the right command to *IMPORT* a CRL?
I tried:
./ejbca.sh ca getcrl --caname XXXCA_41 -f /home/jl/ejbcabuild/CRL-DOWNLOADER/crls/XXXCA_41.crl
and the response I got was:
No CRL exists for CA XXXCA_41.
????
On Friday, June 28, 2019, 9:37:27 AM EDT, <oh...@ya...> wrote:
I think I found the command:
[root@ejbca bin]# ./ejbca.sh ca getcrl --help
GETCRL EJBCA CLI Commands Manual GETCRL
NAME
getcrl - Retrieves a CRL from a CA. Either the latest CRL or a CRL with a specified CRL number.
SYNOPSIS
getcrl <CA_NAME> <FILE_NAME> [OPTIONAL PARAMETERS]
getcrl --caname <CA_NAME> -f <FILE_NAME> [OPTIONAL PARAMETERS]
DESCRIPTION
Retrieves a CRL from a CA. Either the latest CRL or a CRL with a specified CRL number.
PARAMETERS
Mandatory parameters:
--caname <CA_NAME> (Switch is not required)
The CA to get the CRL for.
-f <FILE_NAME> (Switch is not required)
The file to export to.
Optional parameters:
--clipassword <CLI_PASSWORD>
Set the password explicitely in the command line with --clipassword=<password>
--verbose
Set this value for verbose output of parameter values.
-crlnumber <CRL_NUMBER>
Get CRL with the specified CRL number, instead of the latest. Used to read
historical CRLs.
-delta
Fetch the latest delta CRL. Default is regular CRL.
-p <User will be prompted, input will not be shown>
Set this flag to be prompted for the username password
-pem
Use PEM encoding. Default is DER encoding.
-u <CLI_USERNAME>
Username for the CLI user, if required.
I am going to try it now...
Jim
On Friday, June 28, 2019, 9:01:03 AM EDT, <oh...@ya...> wrote:
You will DEFINITELY be missed!
If you have time before you go, can you point me to how to use the CLI to import the CRL?
Thanks,
Jim
On Friday, June 28, 2019, 8:30:17 AM EDT, Tomas Gustavsson <to...@pr...> wrote:
I don't. Looks like the security filter (OWASP CSRFGuard) has a built in
size limit for uploads. As you are using the Web UI for this, you may
try the CLI instead as that does not go via the web interface.
Cheers,
Tomas
PS: I will be away on vacation after today and will not be active in
this list for a couple of weeks now.
On 2019-06-28 14:24, ohaya--- via Ejbca-develop wrote:
> Does anyone have any solution to this problem?
>
> Thanks,
> Jim
>
>
> On Thursday, June 27, 2019, 3:12:35 PM EDT, <oh...@ya...> wrote:
>
>
> Hi,
>
> I tried changing the <http-listener> in the standalone.xml to:
>
> <https-listener name="httpspub" socket-binding="httpspub"
> max-post-size="100000000" max-parameters="2048" ssl-context="httpspub"/>
> <https-listener name="httpspriv" socket-binding="httpspriv"
> max-post-size="100000000" max-parameters="2048" ssl-context="httpspriv"/>
>
> and now when I try to import the CRL, I get:
>
> 14:53:10,355 ERROR [io.undertow.request] (default task-1) UT005023:
> Exception handling request to /ejbca/adminweb/ca/cafunctions.jsp:
> java.lang.IllegalArgumentException: byte limit exceeded: -58
> at
> org.owasp.csrfguard.MultipartFormData.decrementLimit(MultipartFormData.java:1339)
> at
> org.owasp.csrfguard.MultipartFormData.readData(MultipartFormData.java:1305)
> at
> org.owasp.csrfguard.MultipartFormData.readPart(MultipartFormData.java:1145)
>
>
> On Thursday, June 27, 2019, 2:25:39 PM EDT, <oh...@ya...> wrote:
>
>
> Hi,
>
> I am trying to import a somewhat large (> 70MB) CRL into EJBCA, and when
> I try that it is throwing an exception and outputting the following
> stacktrace:
>
> 14:17:41,407 ERROR [stderr] (default task-1)
> io.undertow.server.RequestTooBigException: UT000020: Connection
> terminated as request was larger than 10485760
> 14:17:41,408 ERROR [stderr] (default task-1) at
> io.undertow.conduits.FixedLengthStreamSourceConduit.checkMaxSize(FixedLengthStreamSourceConduit.java:168)
> 14:17:41,408 ERROR
>
> How can I import this CRL into EJBCA?
>
> 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
|
|
From: Tomas G. <to...@pr...> - 2019-06-28 13:40:40
|
bin/ejbca.sh ca importcrl --help Cheers, Tomas On 2019-06-28 15:37, ohaya--- via Ejbca-develop wrote: > I think I found the command: > > [root@ejbca bin]# ./ejbca.sh ca getcrl --help > > GETCRL EJBCA CLI Commands Manual GETCRL > > NAME > getcrl - Retrieves a CRL from a CA. Either the latest CRL or a CRL with > a specified CRL number. > > SYNOPSIS > getcrl <CA_NAME> <FILE_NAME> [OPTIONAL PARAMETERS] > getcrl --caname <CA_NAME> -f <FILE_NAME> [OPTIONAL PARAMETERS] > > DESCRIPTION > Retrieves a CRL from a CA. Either the latest CRL or a CRL with a > specified CRL number. > > PARAMETERS > Mandatory parameters: > --caname <CA_NAME> (Switch is not required) > The CA to get the CRL for. > -f <FILE_NAME> (Switch is not required) > The file to export to. > > Optional parameters: > --clipassword <CLI_PASSWORD> > Set the password explicitely in the command line with > --clipassword=<password> > --verbose > Set this value for verbose output of parameter values. > -crlnumber <CRL_NUMBER> > Get CRL with the specified CRL number, instead of the latest. Used to read > historical CRLs. > -delta > Fetch the latest delta CRL. Default is regular CRL. > -p <User will be prompted, input will not be shown> > Set this flag to be prompted for the username password > -pem > Use PEM encoding. Default is DER encoding. > -u <CLI_USERNAME> > Username for the CLI user, if required. > > > I am going to try it now... > > Jim > > > On Friday, June 28, 2019, 9:01:03 AM EDT, <oh...@ya...> wrote: > > > You will DEFINITELY be missed! > > If you have time before you go, can you point me to how to use the CLI > to import the CRL? > > Thanks, > Jim > > > On Friday, June 28, 2019, 8:30:17 AM EDT, Tomas Gustavsson > <to...@pr...> wrote: > > > > I don't. Looks like the security filter (OWASP CSRFGuard) has a built in > size limit for uploads. As you are using the Web UI for this, you may > try the CLI instead as that does not go via the web interface. > > Cheers, > Tomas > > PS: I will be away on vacation after today and will not be active in > this list for a couple of weeks now. > > On 2019-06-28 14:24, ohaya--- via Ejbca-develop wrote: >> Does anyone have any solution to this problem? >> >> Thanks, >> Jim >> >> >> On Thursday, June 27, 2019, 3:12:35 PM EDT, <oh...@ya... > <mailto:oh...@ya...>> wrote: >> >> >> Hi, >> >> I tried changing the <http-listener> in the standalone.xml to: >> >> <https-listener name="httpspub" socket-binding="httpspub" >> max-post-size="100000000" max-parameters="2048" ssl-context="httpspub"/> >> <https-listener name="httpspriv" socket-binding="httpspriv" >> max-post-size="100000000" max-parameters="2048" ssl-context="httpspriv"/> >> >> and now when I try to import the CRL, I get: >> >> 14:53:10,355 ERROR [io.undertow.request] (default task-1) UT005023: >> Exception handling request to /ejbca/adminweb/ca/cafunctions.jsp: >> java.lang.IllegalArgumentException: byte limit exceeded: -58 >> at >> > org.owasp.csrfguard.MultipartFormData.decrementLimit(MultipartFormData.java:1339) >> at >> > org.owasp.csrfguard.MultipartFormData.readData(MultipartFormData.java:1305) >> at >> > org.owasp.csrfguard.MultipartFormData.readPart(MultipartFormData.java:1145) >> >> >> On Thursday, June 27, 2019, 2:25:39 PM EDT, <oh...@ya... > <mailto:oh...@ya...>> wrote: >> >> >> Hi, >> >> I am trying to import a somewhat large (> 70MB) CRL into EJBCA, and when >> I try that it is throwing an exception and outputting the following >> stacktrace: >> >> 14:17:41,407 ERROR [stderr] (default task-1) >> io.undertow.server.RequestTooBigException: UT000020: Connection >> terminated as request was larger than 10485760 >> 14:17:41,408 ERROR [stderr] (default task-1) at >> > io.undertow.conduits.FixedLengthStreamSourceConduit.checkMaxSize(FixedLengthStreamSourceConduit.java:168) >> 14:17:41,408 ERROR >> >> How can I import this CRL into EJBCA? >> >> Thanks, >> Jim > >> >> >> _______________________________________________ >> 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 > |
106 messages has been excluded from this view by a project administrator.
