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,

Your default responder doesnt exists.
CN=simpleca,OU=simplecaou,O=simplecao,C=US

Wasn't the use case from the beginning that every OCSP response should
be signed by the "default responder"?

Regards,
Tomas

On 2019-07-31 14:36, ohaya--- via Ejbca-develop wrote:
> 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...
> <mailto:oh...@ya...>
>> <oh...@ya... <mailto: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...
> <mailto:oh...@ya...>
>> <oh...@ya... <mailto: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...
> <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
> 