On Thu, 17 Sep 2020 at 12:42, Antony Antony <ant...@phenome.org> wrote:
> On Wed, Sep 16, 2020 at 10:35:07PM -0400, Andrew Cagney wrote: > > First, I believe ikev2-03-basic-rawrsa-ckaid is fixed. It uses > the CKAID to > > directly locate the raw key in the NSS DB. To confirm it is working, > look in > > west.pluto.log for "CKAID". > > add an empty file ipsec.secrets in the test directory. > or rm /etc/ipsec.secrets explictly in the initscripts. > > also add "cat /etc/ipsec.secrets" in the *tinit.sh as saftey check. > > We have been back and forth fixed and wip on this issue many times, may be > due the confusion ipsec.secrets is copied from > baseconfig/<hostname>/etc/ipsec.secrets. To avoid have an empty file in > the > test directory. > Right. The ckaid test: - deletes ipsec.secrets - provides the rsasigkey for east - and the ckaid for west's raw key > > The use case for this test is pretty easy: > > - generate the raw key > > - use certutil to find the ckaid > > - add ...ckaid= to the config file > > (how does the other end get the pubkey?) > > > > So what's the use case for basic-pluto-01-nosecrets? Why would an end > use this > > when they can specify the raw key using the ckaid? And what sequence of > > commands would be used to configure it? > > > > For what it is worth, the fix means either a double lookup at "up" time: > > -> using @west find the raw rsapubkey > > -> using the raw rsapubkey's ckaid find the raw private key in the NSS DB > > or, like basic-pluto-01, an attempt to load the raw key during "add" time > > > > > _______________________________________________ > > Swan-dev mailing list > > Swan-dev@lists.libreswan.org > > https://lists.libreswan.org/mailman/listinfo/swan-dev > >
_______________________________________________ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev