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

[Tomas G. <to...@pr...>]

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
>