[Swan-dev] nss vs newhostkey / showhostkey

Andrew Cagney andrew.cagney at gmail.com
Wed May 25 17:14:02 UTC 2016

On 24 May 2016 at 17:36, Paul Wouters <paul at nohats.ca> wrote:
> On Tue, 24 May 2016, Andrew Cagney wrote:
>> In the old days this sort of thing worked:
>>   ipsec newhostkey --output /etc/ipsec.secrets
>>   ipsec showhostkey --file /etc/ipsec.secrets
> the better term is "that sort of thing was required"

Ok.  I think I'm getting to the right head space.  The dogma is
s/ipsec.secrets/ipsec.d/.  I.e., where as before it would meddle with
/etc/ipsec.secrets, it now meddles with /etc/ipsec.d.

In the case of newhostkey (a quick look at the man page shows it very

    [ --configdir <nssdbdir> ] the directory containing the NSS DB, by
default "/etc/ipsec.d" (some make variable)
    --password <password> the password for accessing the NSS DB, if
required, should this be required.  Nice to have is slurping the
password out of /etc/ipsec.secrets


  --output <ipsec.secrets> is either optional or gone and appending to
/etc/ipsec.secrets is not the default

(a way to dump the certificate into a file would be nice to have, mind)

so provided /etc/ipsec.d (and perhaps /etc/ipsec.secrets) are set up then:

   ipsec newhostkey

will add a key to the NSS DB.  I suspect it, in addition to:

  [root at east nss-cert-ocsp-07-nourl]# ipsec newhostkey
  Generated RSA key pair was stored in the NSS database

it should print information that identifies the generated key.

>> this was because newhostkey wrote all the details of the generated key
>> to /etc/ipsec.secrets where showhostkey could find it.
>> /etc/ipsec.secrets, in effect, was a "trust store" - a pool of
>> certificates that are blindly trusted.
>> With NSS, this is no longer true.  The keying material gets stored in
>> the database and instead a nickname or ckaid can be used to locate it.
> Right. If we can avoid id, neither public or private keys should require
> anything in ipsec.secrets.
>> But what should newhostkey / showhostkey do?
>> - could be change to generate/parse ipsec.conf *ckaid= lines but I
>> suspect that wouldn't be helpful
>>  a critical feature is certificate fall-over and specifying an exact
>> CKAID would prevent that
>>  I could add ckaid2.... I guess
> I would say newhostkey should not touch ipsec.secrets at all.
> showhostkey should be able to find public keys (within a certificate
> or not) and return the (optional friendly_name), the cert it was in (if
> any) and the ckaid and pubkey blob.
>> - they could be changed to generate/parse ipsec.conf *rsasigkey= lines
>> directly
>> So instead I'm changing newhostkey/showhostkey et.al. so that they
>> handle an ipsec.secrets file containing just:
>> - generate/parse ipsec.secrets that contains a very minimal entry like:
>>    : RSA {
>>              CKAIDNSS .....
>>    }
>> i.e, have ipsec.secrets specify a list of keys, that can be found in
>> NSS, to add to the 'trust store" (I've already changed to to require
>> just Modulus/PublicExponent/CAKIDNSS).
> What's the use of this?
> eg we just need something like:
> root at thinkpad:/etc/ipsec.d# certutil -K -d sql:/etc/ipsec.d
> certutil: Checking token "NSS Certificate DB" in slot "NSS User Private
> Key and Certificate Services"
> < 0> rsa      825c07463fabbe48abbc9d6b25e72be7329fd77d   (orphan)
> < 1> rsa      e413910e49698e8611cb0ca9fdc194689abbf002   (orphan)

And showhostkey will print the public bits in various formats.

> except we want to also display any potential friendly_name, and the
> pubkey blob as well. (the blob displayed now is ckaid)

It seems that the current friendly name is "(orphan)" aka NULL.  I
guess, without --id (or ckaid or nickname?), it should list "orphans"
on the assumption that they are host keys.

> Paul

More information about the Swan-dev mailing list