Menu
▾
▴
Re: [Ejbca-develop] Trouble creating Internal Key Binding for OCSP Responder
|
From: Tomas G. <to...@pr...> - 2019-06-26 12:35:34
|
On 2019-06-26 13:40, ohaya--- via Ejbca-develop wrote: > 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... Yes, that should be all you have to do. The NullPointerException is likely related to some other CRL related detail. Post that stacktrace in a new thread "NullPointerException trying to import CRL". > > > 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... <mailto: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...> > <mailto: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...>> >>> <mailto: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...>> >>> <mailto: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...>> >>> <mailto: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...> >> <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 > |
