[Nfd-dev] How to start a certificate chain from scratch

[Shuo Chen]

Hi Yingdi,

My question is that how to sign a cert with the root cert generated by
another host.

Here is my security model

root---------site1----------router1
   |-----------site2----------router2

I installed certificates of root, site1 and router1 in host1.
used ndnsec cert-dump to dump certificate of root in a file.
The I transferred this certificate file into another machine and used
ndnsec cert-install to install the certificate.
All above works well.
Then
$ ndnsec-certgen -N /root/site2 -s /root site2-cert.req |
ndnsec-cert-install -

It shows “ERROR: private key doesn't exists”

-----
Shuo Chen

On Thu, Nov 20, 2014 at 2:23 AM, Yingdi Yu <yingdi at cs.ucla.edu> wrote:

>
> On Nov 19, 2014, at 10:13 AM, Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
>
> Dear folks
>
> While we are able to request testbed certificates from ndncert website,
> when doing experiments, it's undesirable to request testbed certificates
> for all nodes.
> Suppose someone wants to start a certificate chain from scratch, how could
> this be done?
>
>
> Just to clarify, the scenario you describe is a trust model for the
> ndncert only. For apps that just want to use simple trust model, it is not
> necessary to create so many keys.
>
>
> Specifically, what are the commands to:
>
>    1. generate a root certificate: /example/KEY/ksk-1/ID-CERT
>    2. generate a site certificate and sign it by root certificate:
>    /example/KEY/site1/ksk-2/ID-CERT
>    3. generate a user certificate and sign it by site certificate:
>    /example/site1/KEY/user1/ksk-3/ID-CERT
>    4. publish root, site, user certificate in a repository or ndns system
>    5. generate a data signing certificate and sign it by user
>    certificate: /example/site1/user1/KEY/dsk-4/ID-CERT
>
>
> Another question is: why is testbed root certificate named
> /ndn/KEY/ksk-xxxx/ID-CERT, instead of /KEY/ndn/ksk-xxxx/ID-CERT
>
>
> Because the root of the testbed is "/ndn" rather than "/", and testbed
> publish its root cert under its own prefix.
>
> Yingdi
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150302/e1d0f47c/attachment.html>