Re: [Ejbca-develop] SOLVED BUT IS THIS CORRECT ANSWER?? was Re: Problem processing OCSP Requests

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

No that is incorrect. The "Name" is not used for anything related to OCSP.

The "Issuer Name Hash" as referenced in the log is defined in OCSP RFC
6960 and is based on the subject DN of the CA certificate.

The Name you enter as name of the CA is an arbitrary string. Typically
something like "My CA v1".

In a debug log of EJBCA it will show regularly (first during startup)
which CA certificates are loaded by EJBCA. Something like:

2019-07-31 10:08:32,086 DEBUG
[org.cesecore.certificates.ca.internal.CaCertificateCache]
(ServerService Thread Pool -- 78) Found the following CA certificates :
CN=TestExportRemoveRestoreCA3,131F6952BCE09394
CN=TestServiceService_TestCA1,3BCF13B76E51DE31
CN=RenamedTestCA,4FE83A6F12880043
CN=TestServiceService_TestCA2,3301346766C4FF66

There is a cache time, and the CA certificate cache is reloaded as a
time interval specified in cache.properties. Always during restart of
course. When importing a new CA certificate, which is only an "External
CA" and can not be used to answer OCSP queries, it takes some time
before it appears in the cache.
OCSP Key Binding are set up to answer queries for "External CAs", you
can either use a "default responder" (which I think is what we discussed
before right?), or you can issue a specific OCSP responder certificate
for all/any CAs.

Regards,
Tomas

On 2019-07-30 22:41, ohaya--- via Ejbca-develop wrote:
> Hi,
> 
> I was just able to get OCSP responses working with this CA/CRL, and I
> *think* that the answer was that EJBCA OCSP Responder did not like the
> *NAME* that I used/entered when I created the Certificate Authority in
> the EJBCA Adminweb!!!
> 
> What I mean is the adminweb page with the URL
> https://XXXXX:8443/ejbca/adminweb/ca/editcas/editcas.jsp, where you use
> the "Import CA Certificate..." button.
> 
> It appears that EJBCA OCSP Responder actually uses the "Name" value (and
> I guess that is what it hashes to get the name hash) to match the issuer
> on the incoming OCSP request.
> 
> There seems to be SOME KIND OF RULE for that Name, but what is that
> rule, EXACTLY?
> 
> My best guess is that that Name has to match the filename of the CA
> cert/PEM, EXACTLY, including the case of the filename, but NOT INCLUDING
> the file extension. 
> 
> In other words, if the CA cert PEM file is "joe_foo.pem", then you have
> to enter "joe_foo" for the Name field when creating the new CA in the
> Adminweb.
> 
> And, "JOE_FOO" or "JoE_FoO" does not work... it has to be "joe_foo".
> 
> Another example is if the CA cert PEM file is
> "This_is_mY_cert.crt.pem.crt", then, for the Name you enter when you
> create the CA in the Admin web, you have to enter:
> 
> This_is_mY_cert.crt.pem
> 
> Is that correct?  Can anyone confirm what the actual Name string has to
> be? 
> 
> This is a kind of time killer... spent almost a whole day trying to
> figure this one out :(...
> 
> Jim
> 
> 
> 
> On Tuesday, July 30, 2019, 7:45:20 PM UTC, oh...@ya...
> <oh...@ya...> wrote:
> 
> 
> Also, FYI, here is the response I get when I test the OCSP request using
> "openssl ocsp":
> 
> OCSP Request Data:
>     Version: 1 (0x0)
>     Requestor List:
>         Certificate ID:
>           Hash Algorithm: sha1
>           Issuer Name Hash: DD109D9D80B22984C50240DF37F6C75E70E2DEDD
>           Issuer Key Hash: BC0F770B8DA3B38543C2369366AC02A977C33D52
>           Serial Number: 3732
>     Request Extensions:
>         OCSP Nonce:
>             04109186E755667555C98040988194088E5D
> Responder Error: unauthorized (6)
> 
> 
> NOTICE the "Responder Error: unauthorized (6)" error.
> 
> I have even deleted the CA from EJBCA OCSP responder and then
> re-imported that CA's cert and the latest CRL and I am still getting the
> same error.
> 
> Thanks,
> Jim
> 
> On Tuesday, July 30, 2019, 4:37:49 PM UTC, oh...@ya...
> <oh...@ya...> wrote:
> 
> 
> Hi,
> 
> I am circling back and trying to do some OCSP response testing with the
> EJBCA OCSP responder, but when I run "openssl ocsp" testing, I am
> getting an error (from the EJBCA logging):
> 
> 16:25:35,230 INFO 
> [org.cesecore.certificates.ocsp.OcspResponseGeneratorSessionBean]
> (default task-7) Received OCSP request for certificate with serNo: 3a1b,
> and issuerNameHash: dd109d9d80b22984c50240df37f6c75e70e2dedd. Client ip
> 192.168.xx.yy.
> 16:25:35,236 ERROR
> [org.cesecore.certificates.ocsp.OcspResponseGeneratorSessionBean]
> (default task-7) Unable to find CA certificate by issuer name hash:
> dd109d9d80b22984c50240df37f6c75e70e2dedd, or even the default responder:
> CN=xxxx.
> 
> I think that I have that CA imported into EJBCA and also the latest CRL.
> 
> Is there a way to find out what that issuer name that it is looking for
> from the "issuer name hash"? 
> 
> I'm guessing there probably isn't, so how can I debug why it is not able
> to find the CA (and CRL from that CA) in EJBCA?
> 
> Thanks,
> Jim
> 
> 
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> 