Re: [Ejbca-develop] Trouble creating Internal Key Binding for OCSP Responder

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

 Hi,

Ok, so now, if we want to use only one signing key for all the CRL/CAs we want to respond for, how do we accomplish that?

Do we (as I described earlier) just have to import the CA cert for each external CA into Adminweb and then import the CRL for that CA into Adminweb?

And, if the answer to that question is "yes, that is all you have to do", then THAT (when I import the CRL into Adminweb) is where I was getting the stacktrace with the NullPointerException that I posted earlier, and I guess that is why I posted it into THIS thread...

Aside: Now that I think about this discussion, maybe THIS is why you might not have seen this NullPointerException, i.e., in your case, you are creating a new binding for each CA/CRL, so you don't get the NullPointerException, but in my case, I am not creating a new binding for each CA/CRL but trying to import the CRL using the same binding for multiple CA/CRLs??? 

If you still think that should be in a separate thread, please let me know? I think that if I put it into a new thread, I will have to also also include a whole bunch of background discussion which we have already covered in THIS thread by now?

Please advise, and thanks for your help!

Jim

     On Wednesday, June 26, 2019, 7:22:10 AM EDT, Tomas Gustavsson <to...@pr...> wrote:  

Ok, if you look at OCSP Key bindings page there is something called
"Default responder". This is used for unknown issuers/missing key
bindings. There is a [?] link that you can click that takes you directly
to the documentation.

We're working with hundreds of CAs, and most use a separate signing key
for each CA. The trust model is quite weak if you have a single
responder for all. There are no technical issues having hundreds of key,
and signing certificate chains up to the CA so the chain of trust is
simple.
That's why I say you should create a new key binding, that remains my
recommendation, even if you can do it differently :-)

Cheers,
Tomas

On 2019-06-26 13:11, ohaya--- via Ejbca-develop wrote:
> Hi,
> 
> I was kind of afraid that you would say that (need a new OCSP binding
> for OCSP responder for each new CA/CRL).
> 
> 
> BUT, what if we DON'T want to use a different signing key/cert for the
> different CAs/CRLs that our OCSP Responder is supporting?
> 
> 
> For instance, today, the OCSP Responder we are using supports OCSP
> responding for almost 100 CAs (we download CRL files for about 100
> different CAs' CRLs into our OCSP Responder) and all the OCSP responses
> are signed by our ONE signing cert/key.
> 
> 
> If we have to create a new OCSP binding for each of those CAs, we'd have
> to have 100 keys, I think, and I don't think that they (our customer)
> would want that.
> 
> 
> I am really hoping that we are just mis-communicating somehow, but FYI,
> we have worked with a number of OCSP Responder products and none of them
> requires that we create a unique signing key for each new CA/CRL that we
> want our OCSP responder to be able support.
> 
> 
> 
> Jim
> 
> 
> On Wednesday, June 26, 2019, 7:02:17 AM EDT, Tomas Gustavsson
> <to...@pr...> wrote:
> 
> 
> 
> On 2019-06-26 12:41, ohaya--- via Ejbca-develop wrote:
>> -- Re. the question about CSR: So right now, it looks like to issue the
>> signing cert, the process is you click the CSR button in the Adminweb to
>> create the CSR, then we use that CSR to get a signing certificate
>> issued, and then we import that signing cert.
>>
>> That means if we are standing up EJBCA for production in a new
>> environment, we have to do the above (use Adminweb to create a new CSR,
>> etc.), but here, when we build a new production environment, we
>> generally want to have all the artifacts that are needed to build the
>> new production environment. Specifically, relative to EJBCA, we have our
>> own process for issuing certs, where our process ends up with the
>> private key and cert and maybe a P12, and that we would want to be able
>> to use those to construct the new production environment, rather than
>> have the installer click a button to create a CSR in the production
>> environment and then somehow get the CSR over to our CA and then get the
>> CA to issue a cert, and then somehow get the new cert transferred back
>> over to the production environment.
>>
>> So, what I was looking for is if there is a way to just use our own
>> issued key and cert (or a P12) instead of using Adminweb to create the
>> CSR, etc.?
> 
> You can do everything using the CLI, so you can automate that. The keys
> are in a crypto token, you can export and import crypto tokens.
> 
> 
>> -- Re. the question about "incrementally to add more CRLs from different
>> CAs", I think I wasn't clear about what I meant.
>>
>> I didn't mean updating a CRL for a CA that we had already setup
>> previously in the EJBCA OCSP Responder .
>>
>>
>> Rather, what I meant is if we have 2 OTHER CAs whose CRLs we want our
>> EJBCA OCSP Responder to be able to be able to provide OCSP responses
>> for, what do we need to do with EJBCA to do that?
>>
>> So, for example, we now want our EJBCA OCSP Responder to do OCSP
>> responding for 2 more CAs, and we have:
>>
>> CA cert for CA1 and a current CRL file for CA1 (call this ca1.crl)
>> CA cert for CA2 and a current CRL file for CA2 (call this ca2.crl)
>>
>>
>> I think (guess) that the process is something like:
>>
>> Add the new CA cert for CA1 to EJBCA using the Adminweb, then
>> In Adminweb, import a CRL file (ca1.crl) into EJBCA while selecting the
>> CA1 CA
>>
>> Then:
>>
>> Add the new CA cert for CA2 to EJBCA using the Adminweb, then
>> In Adminweb, import a CRL file (ca2.crl) into EJBCA while selecting the
>> CA1 CA
>>
>>
>>
>> My question is: Is the above 2 steps (Add the CA cert for the new CA and
>> then import the CRL file for the new CA) the only steps we need to do in
>> this case, in order to get EJBCA OCSP Responder to be able to respond to
>> OCSP requests for that new CA/CRL?
> 
> OCSP is done by OCSP Key Bindings. You have to create a new OCSP key
> binding for every new CA you want the OCSP responder to answer for (the
> OCSP signing key must be signed by the CA). The CRL import is just to
> update the revocation database so the OCSP responder knows which
> certificates are revoked.
> 
> 
>>
>>
>>
>>
>> Thans,
>> Jim
>>
>> P.S. I am having problems with responding format in Yahoo email, so if
>> response looks weird my apologies.
>>
>>
>>
>>
>> On Wednesday, June 26, 2019, 5:10:23 AM EDT, Tomas Gustavsson
>> <to...@pr... <mailto:to...@pr...>> wrote:
>>
>>
>>
>> On 2019-06-25 20:07, ohaya--- via Ejbca-develop wrote:
>>> Hi,
>>>
>>> FYI, I was able to use Adminweb to create a new CSR and then I issued a
>>> new signing cert with the OCSPSign purpose and I was then able to import
>>> into Adminweb, and I was able to test some good and bad requests (see
>>> below).
>>>
>>> I think that we will still need to be able use a cert/key pair that we
>>> generated outside of EJBCA (i.e., not create a CSR via Adminweb, etc.),
>>> so is there a way to do that?
>>
>> I do not understand what you mean by this.
>> If you want the OCSP Key Binding in EJBCA to generate the key, why would
>> the CSR come from outside of EJBCA?
>> You can always issue certificates to CSRs with EJCBA...if you have a
> CSR...
>>
>>> BTW, also, I am still not clear what we need to do incrementally to add
>>> more CRLs from different CAs? I mean for example, if there are 10 more
>>> CAs with CRLs and we want our EJBCA to do the OCSP responding for those,
>>> what are the steps we need to do to configure EJBCA to do that?
>>
>> There is a service called "CRL Downloader" under Sevrices that can be
>> used to automate import/update of CRLs. It is documented among the
>> "Services".
>>
>>
>>>
>>>
>>> Here's the test:
>>>
>>> E:\INSTALL-FILES\OPENSSL\OpenSSL-Win64\bin>openssl ocsp -CAfile
>>> ./rootCA.crt -issuer ./rootCA.crt -serial 0x8486394C03E1F5D9 -req_text
>>> -url http://192.168.0.28:8080/ejbca/publicweb/status/ocsp
>>> 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:
>>> 041061AAC22F8FD77F35FEEA879361B29CD9
>>> Response verify OK
>>> 0x8486394C03E1F5D9: WARNING: Status times invalid.
>>> 388:error:2707307E:OCSP routines:OCSP_check_validity:status not yet
>>> valid:crypto\ocsp\ocsp_cl.c:320:
>>> revoked
>>> This Update: Jun 25 17:56:47 2019 GMT
>>> Reason: unspecified
>>> Revocation Time: May 26 12:30:44 2019 GMT
>>>
>>>
>>>
>>>
>>> On Tuesday, June 25, 2019, 1:37:30 PM EDT, <oh...@ya...
> <mailto:oh...@ya...>
>> <mailto:oh...@ya... <mailto:oh...@ya...>>> wrote:
>>>
>>>
>>> Hi,
>>>
>>> I am trying to create the Internal Key Binding for the OCSP Responder on
>>> the EJBCA that I just built.
>>>
>>> In the Adminweb, I have created the Internal Key Binding, but now I am
>>> trying to do the "Import externally issued certificate". 
>>>
>>> I have the Internal Key Binding that I created in the OVA based system
>>> previously, and I was hoping that I wouldn't need to issue a new cert
>>> for this new system, so I was wondering if there is any way to get the
>>> private key from that OVA based system so that I can do the import into
>>> the new EJBCA configuration?
>>>
>>> Or, is the only way to create a new CSR on the new EJBCA, and then issue
>>> a new cert?
>>>
>>> Thanks,
>>> Jim
>>
>>>
>>>
>>> _______________________________________________
>>> Ejbca-develop mailing list
>>> Ejb...@li...
> <mailto:Ejb...@li...>
>> <mailto:Ejb...@li...
> <mailto:Ejb...@li...>>
>>> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>>>
>>
>>
>> _______________________________________________
>> Ejbca-develop mailing list
>> Ejb...@li...
> <mailto:Ejb...@li...>
>> <mailto: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...
> <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