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

 Hi Tomas,
I just re-imported that same CA cert and CRL for the CA that was giving me the problem with the OCSP responses yesterday, using a random "name", and then restarted the standalone.sh (I restarted it twice actually), and this is what I get in the server logging:

2019-07-31 11:53:18,560 DEBUG [org.cesecore.certificates.ca.internal.CaCertificateCache] (ServerService Thread Pool -- 97) Found the following CA certificates :
CN=ORCxxxxx,...,C=US,17
CN=DYYY,...,C=US,14
CN=simpleca,OU=simplecaou,O=simplecao,C=US,15CF58B49A5
CN=ManagementCA,O=EJBCA Sample,C=SE,63E9453741C9A8F61061282BE36185F4E9D495B6

The "CN=ORCxxx,...,C=US" is the one I am trying to test OCSP requests with, and now I get this when I run the "openssl ocsp..." test request:
OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: DD109D9D80B22984C50240DF37F6C75E70E2DEDD
          Issuer Key Hash: BC0F770B8DA3B38543C2369366AC02A977C33D52
          Serial Number: 3731
    Request Extensions:
        OCSP Nonce:
            0410C2666B492B583E8ACC716D3698B245AB
Responder Error: unauthorized (6)

and in the server.log I get the following when I run the test request:
12:04:57,036 INFO  [org.cesecore.certificates.ocsp.OcspResponseGeneratorSessionBean] (default task-1) Received OCSP request for certificate with serNo: 3731, and issuerNameHash: dd109d9d80b22984c50240df37f6c75e70e2dedd. Client ip 192.168.20.148.
12:04:57,049 ERROR [org.cesecore.certificates.ocsp.OcspResponseGeneratorSessionBean] (default task-1) Unable to find CA certificate by issuer name hash: dd109d9d80b22984c50240df37f6c75e70e2dedd, or even the default responder: CN=simpleca,OU=simplecaou,O=simplecao,C=US.

So now that I re-imported the CA (with a random Name) and the CRL and restarted, I am getting the same problem with OCSP requests not working again.

Notice the message above in the server log that two of the numbers after the CA strings are really short (2 digits each):
CN=ORCxxxxx,...,C=US,17
CN=DYYY,...,C=US,14

>From what you said, those numbers are the name hash. Is that normal for them to be just 2 digits?  

Is that maybe why the OCSP responses that I am testing for the "CN=ORCxxxxx,...,C=US" CA are failing now again?
Thanks,Jim

    On Wednesday, July 31, 2019, 8:12:45 AM UTC, Tomas Gustavsson <to...@pr...> wrote:  

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
> 

_______________________________________________
Ejbca-develop mailing list
Ejb...@li...
https://lists.sourceforge.net/lists/listinfo/ejbca-develop