Menu
▾
▴
Re: [Ejbca-develop] EJBCA OCSP Responder does not appear to be finding revoked certificates in large CRL?
|
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
|
