[strongSwan] swanctl.conf debugging-- fails to load certificates

[Stephen Ayotte]

First, please check my reasoning for using swanctl: I want ad-hoc
host-to-host transport level connections between all hosts which are A) in
the same subnet and B) have an X509 cert signed by the same CA. I don't see
a syntax that expresses this in ipsec.conf (only specific, known
endpoints), but the local_addrs/remote_addrs/local_ts/remote_ts +
start_action=trap in swanctl.conf looks like it should get the job done.

Short coverage of my starting conditions: I'm using strongswan-5.5.2 on
Debian-8.7/amd64, compiled with these config options:

    ./configure --enable-monolithic \
        --disable-charon --disable-stroke --disable-scepclient \
        --enable-systemd --enable-swanctl
--with-systemdsystemunitdir=/lib/systemd/system/

I went for 5.5.x for the systemd integration; I was having trouble
understanding how to ensure that swanctl.conf was being used and ipsec.conf
being ignored with ipsec-starter in the mix.

I'm using certificates generated using the "ipsec pki" utility, following
the instructions found at this link (
https://wiki.strongswan.org/projects/strongswan/wiki/SimpleCA), with the
exception that I named the files after my hosts rather than e.g.
"peerCert.der". Note that I generated these using 5.4.x from the
Debian-supplied package, since the one I built doesn't include the "ipsec"
tool at all... I also used the 5.4.x package to verify these certs are
loadable and indeed they were (although pinging host-to-host in a static
setup exactly asin this example (
https://www.strongswan.org/testing/testresults/ikev2/host2host-transport/)
didn't provoke any IKE negotiation... but I don't think solving that
problem would help me anyway, so I didn't try).

Ok, now the problem: charon chokes on the certificates with this error:
    08[LIB] building CRED_CERTIFICATE - X509 failed, tried 3 builders

I've stashed my configs in a gist here:
https://gist.github.com/sayotte/9d52580d1bc8620cbc60da47a55bb40f

That error message seems to originate on the charon side of the vici
socket; I found two places it might originate from in the code once the
failure has already happened, but the funky use of function-pointers for
pseudo-OO made it hard to understand where it's actually failing.

Help?

-SA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170511/b8e7c829/attachment.html>