1

I'm trying to create a VPN tunnel between two VMs (named A and B) with strongSwan (for what matters, I use swanctl here) using a host-to-host configuration (as described here ) and a smartcard for B's authentication

I generated CA certificate and I signed CRT for A and B with this one, and it worked as intended. (tunnel was created with no problem)

After that, I decided to generate a crt on my yubikey (using yubikey-manager), that i signed with my CA and I configured strongSwan to use opensc's module to access to this card.

My swanctl --load-creds worked properly, so did my swanctl --load-conns

Here is the result of my swanctl --load-creds 

loaded certificate from '/etc/swanctl/x509ca/ca.crt' #
loaded key tokenyubikey from token [keyid: "..."]

But when I try to initiate with swanctl --initiate I have some errors

Here are my inputs on each host before every attempt

systemctl restart swanctl
swanctl --load-conns
swanctl --load-creds

When I try to connect from B (The one with the Yubikey) to A, here is the output on A (using swanctl --log)

The command I use is swanctl --initiate --child host-host

10[NET] sending packet: from <IP A>[500] to <IP B>[500] (273 bytes)
09[NET] received packet: from <IP B>[4500] to <IP A>[4500] (1104 bytes)
09[ENC] parsed IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
09[DMN] thread 9 received 11
09[LIB]  dumping 20 stack frame addresses:
09[LIB]   /lib/x86_64-linux-gnu/libpthread.so.0 @ 0x7f0c30448000 [0x7f0c3045a890]
09[LIB]     -> ??:?
09[LIB]   /usr/lib/ipsec/libstrongswan.so.0 @ 0x7f0c308f9000 [0x7f0c3092b170]
09[LIB]     -> /home/john/strongswan-5.8.1/src/libstrongswan/networking/host.c:84
09[LIB]   /usr/lib/ipsec/libstrongswan.so.0 @ 0x7f0c308f9000 (host_printf_hook+0x37) [0x7f0c3092b347]
09[LIB]     -> /home/john/strongswan-5.8.1/src/libstrongswan/networking/host.c:114
09[LIB]   /usr/lib/ipsec/libstrongswan.so.0 @ 0x7f0c308f9000 [0x7f0c309456a6]
09[LIB]     -> /home/john/strongswan-5.8.1/src/libstrongswan/utils/printf_hook/printf_hook_glibc.c:118
09[LIB]   /lib/x86_64-linux-gnu/libc.so.6 @ 0x7f0c30057000 [0x7f0c300b0473]
09[LIB]     -> /build/glibc-OTsEL5/glibc-2.27/stdio-common/vfprintf.c:2004
09[LIB]   /lib/x86_64-linux-gnu/libc.so.6 @ 0x7f0c30057000 (_IO_vfprintf+0x192a) [0x7f0c300b3cba]
09[LIB]     -> /build/glibc-OTsEL5/glibc-2.27/stdio-common/vfprintf.c:1688
09[LIB]   /lib/x86_64-linux-gnu/libc.so.6 @ 0x7f0c30057000 (__vsnprintf_chk+0xa9) [0x7f0c30189169]
09[LIB]     -> /build/glibc-OTsEL5/glibc-2.27/debug/vsnprintf_chk.c:65
09[LIB]   /usr/lib/ipsec/libcharon.so.0 @ 0x7f0c30667000 [0x7f0c30676c42]
09[LIB]     -> /home/john/strongswan-5.8.1/src/libcharon/bus/bus.c:398
09[LIB]   /usr/lib/ipsec/libcharon.so.0 @ 0x7f0c30667000 [0x7f0c30676e2a]
09[LIB]     -> /home/john/strongswan-5.8.1/src/libcharon/bus/bus.c:441
09[LIB]   /usr/lib/ipsec/libcharon.so.0 @ 0x7f0c30667000 [0x7f0c3069ab36]
09[LIB]     -> /home/john/strongswan-5.8.1/src/libcharon/sa/ike_sa.c:973
09[LIB]   /usr/lib/ipsec/plugins/libstrongswan-connmark.so @ 0x7f0c2f6ae000 [0x7f0c2f6af6bb]
09[LIB]     -> ??:0
09[LIB]   /usr/lib/ipsec/libcharon.so.0 @ 0x7f0c30667000 [0x7f0c30675a47]
09[LIB]     -> /home/john/strongswan-5.8.1/src/libcharon/bus/bus.c:885
09[LIB]   /usr/lib/ipsec/libcharon.so.0 @ 0x7f0c30667000 [0x7f0c30698e21]
09[LIB]     -> /home/john/strongswan-5.8.1/src/libcharon/sa/ike_sa.c:1114
09[LIB]   /usr/lib/ipsec/libcharon.so.0 @ 0x7f0c30667000 [0x7f0c306a875c]
09[LIB]     -> /home/john/strongswan-5.8.1/src/libcharon/sa/ikev2/task_manager_v2.c:1585
09[LIB]   /usr/lib/ipsec/libcharon.so.0 @ 0x7f0c30667000 [0x7f0c30697f47]
09[LIB]     -> /home/john/strongswan-5.8.1/src/libcharon/sa/ike_sa.c:1587
09[LIB]   /usr/lib/ipsec/libcharon.so.0 @ 0x7f0c30667000 [0x7f0c3069182f]
09[LIB]     -> /home/john/strongswan-5.8.1/src/libcharon/processing/jobs/process_message_job.c:74
09[LIB]   /usr/lib/ipsec/libstrongswan.so.0 @ 0x7f0c308f9000 [0x7f0c30931806]
09[LIB]     -> /home/john/strongswan-5.8.1/src/libstrongswan/processing/processor.c:235
09[LIB]   /usr/lib/ipsec/libstrongswan.so.0 @ 0x7f0c308f9000 [0x7f0c30943d7b]
09[LIB]     -> /home/john/strongswan-5.8.1/src/libstrongswan/threading/thread.c:332 (discriminator 4)
09[LIB]   /lib/x86_64-linux-gnu/libpthread.so.0 @ 0x7f0c30448000 [0x7f0c3044f6db]
09[LIB]     -> /build/glibc-OTsEL5/glibc-2.27/nptl/pthread_create.c:463
09[LIB]   /lib/x86_64-linux-gnu/libc.so.6 @ 0x7f0c30057000 (clone+0x3f) [0x7f0c3017888f]
09[LIB]     -> /build/glibc-OTsEL5/glibc-2.27/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:97
09[DMN] killing ourself, received critical signal

And from here, my StrongSwan seems to be dead and I have to restart it.

I have the same problem when i try to initialize from A to B (as it's an host-host connection)

I tried it with a different VM as A, and I had this output when trying from B to A. The new A host uses sterongswan swanctl version 5.6.2 (installed from apt)

13[IKE] received cert request for "<CA's CN>"
13[IKE] received end entity cert "CN=<B's CN>"
13[CFG] looking for peer configs matching <New A's IP>[A]...<B's ip>[B]
13[CFG] selected peer config 'host-host'
13[IKE] no trusted RSA public key found for 'B'
13[IKE] peer supports MOBIKE
13[ENC] generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]
13[NET] sending packet: from <New A's IP>[4500] to <B's IP>[4500] (80 bytes)

When I try to connect from the new A to B, It crashes as above

Here are more details

Here is my swanctl.conf on B 

    connections {
        home {
            remote_addrs = <A's ip> 

        local {
                auth = pubkey
                id = "B"
                certs = B.crt #It's the cert on my yubikey that i extracted and put onto /etc/swanctl/x509
            }
            remote {
                auth = pubkey
                id = "A"
        }
            children {
                host-host {
                    start_action = trap
                }
            }
        }
    }

    secrets {
    tokenyubikey {
        pin = <my pin>
        slot = 0
        handle = 1 # From what i understood, it's here that my crt is
        module = opensc 
    }
    }

Here is the result of my pkcs11-tool -M command, showing that RSA256 is supported (at least, from what I understand)

Supported mechanisms:
  SHA-1, digest
  SHA256, digest
  SHA384, digest
  SHA512, digest
  MD5, digest
  RIPEMD160, digest
  GOSTR3411, digest
  ECDSA, keySize={256,384}, hw, sign, other flags=0x1800000
  ECDH1-COFACTOR-DERIVE, keySize={256,384}, hw, derive, other flags=0x1800000
  ECDH1-DERIVE, keySize={256,384}, hw, derive, other flags=0x1800000
  RSA-X-509, keySize={1024,3072}, hw, decrypt, sign, verify
  RSA-PKCS, keySize={1024,3072}, hw, decrypt, sign, verify
  SHA1-RSA-PKCS, keySize={1024,3072}, sign, verify
  SHA256-RSA-PKCS, keySize={1024,3072}, sign, verify
  SHA384-RSA-PKCS, keySize={1024,3072}, sign, verify
  SHA512-RSA-PKCS, keySize={1024,3072}, sign, verify
  MD5-RSA-PKCS, keySize={1024,3072}, sign, verify
  RIPEMD160-RSA-PKCS, keySize={1024,3072}, sign, verify

and here the result of my pkcs11-tool -O 

Using slot 0 with a present token (0x0)
Public Key Object; RSA 1024 bits
  label:      PIV AUTH pubkey
  ID:         01
  Usage:      encrypt, verify, wrap
Certificate Object; type = X.509 cert
  label:      Certificate for PIV Authentication
  ID:         01
Data object 2496313968
  label:          'Card Capability Container'
  application:    'Card Capability Container'
  app_id:         2.16.840.1.101.3.7.1.219.0
  flags:          <empty>
Data object 2496314064
  label:          'Card Holder Unique Identifier'
  application:    'Card Holder Unique Identifier'
  app_id:         2.16.840.1.101.3.7.2.48.0
  flags:          <empty>
Data object 2496314160
  label:          'Unsigned Card Holder Unique Identifier'
  application:    'Unsigned Card Holder Unique Identifier'
  app_id:         2.16.840.1.101.3.7.2.48.2
  flags:          <empty>
Data object 2496314256
  label:          'X.509 Certificate for PIV Authentication'
  application:    'X.509 Certificate for PIV Authentication'
  app_id:         2.16.840.1.101.3.7.2.1.1
  flags:          <empty>
Data object 2496314640
  label:          'X.509 Certificate for Digital Signature'
  application:    'X.509 Certificate for Digital Signature'
  app_id:         2.16.840.1.101.3.7.2.1.0
  flags:          <empty>
Data object 2496314736
  label:          'X.509 Certificate for Key Management'
  application:    'X.509 Certificate for Key Management'
  app_id:         2.16.840.1.101.3.7.2.1.2
  flags:          <empty>
Data object 2496314832
  label:          'X.509 Certificate for Card Authentication'
  application:    'X.509 Certificate for Card Authentication'
  app_id:         2.16.840.1.101.3.7.2.5.0
  flags:          <empty>
Data object 2496314928
  label:          'Security Object'
  application:    'Security Object'
  app_id:         2.16.840.1.101.3.7.2.144.0
  flags:          <empty>
Data object 2496315024
  label:          'Discovery Object'
  application:    'Discovery Object'
  app_id:         2.16.840.1.101.3.7.2.96.80
  flags:          <empty>

Here is what is in my /etc/strongswan.d/charon/pkcs11.conf

pkcs11 {
    load = yes
    modules {
    opensc {
        path = /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
    }
    }
}

I generated a CSR on my Yubikey using yubikey-manager and then signed as follow :

ipsec pki --issue --in b.csr --type pkcs10 --cacert <CA's crt> --dn "<CA's DN>CN=B" --san B --outform pem > b.crt

and then imported the resulting CRT onto Yubikey using yubikey-manager

I'm on Ubuntu 18.04 Swanctl is on version 5.8.1

Edit : Here is the result of pkcs11-tool --test --login

Using slot 0 with a present token (0x0)
Logging in to "PIV Card Holder pin (PIV_II)".
Please enter User PIN: 
C_SeedRandom() and C_GenerateRandom():
  seeding (C_SeedRandom) not supported
  seems to be OK
Digests:
  all 4 digest functions seem to work
  MD5: OK
  SHA-1: OK
  RIPEMD160: OK
Signatures (currently only for RSA)
  testing key 0 (PIV AUTH key) 
  all 4 signature functions seem to work
  testing signature mechanisms:
    RSA-X-509: OK
    RSA-PKCS: OK
    SHA1-RSA-PKCS: OK
    MD5-RSA-PKCS: OK
    RIPEMD160-RSA-PKCS: OK
    SHA256-RSA-PKCS: OK
  testing key 1 (1024 bits, label=SIGN key) with 1 signature mechanism
Logging in to "PIV Card Holder pin (PIV_II)".
Please enter context specific PIN: 
    RSA-X-509: OK
  testing key 2 (1024 bits, label=KEY MAN key) with 1 signature mechanism -- can't be used to sign/verify, skipping
Verify (currently only for RSA)
  testing key 0 (PIV AUTH key)
    RSA-X-509: OK
    RSA-PKCS: OK
    SHA1-RSA-PKCS: OK
    MD5-RSA-PKCS: OK
    RIPEMD160-RSA-PKCS: OK
  testing key 1 (SIGN key) with 1 mechanism
Logging in to "PIV Card Holder pin (PIV_II)".
Please enter context specific PIN: 
    RSA-X-509: OK
  testing key 2 (KEY MAN key) with 1 mechanism -- can't be used to sign/verify, skipping
Unwrap: not implemented
Decryption (currently only for RSA)
  testing key 0 (PIV AUTH key) 
    RSA-X-509: OK
    RSA-PKCS: OK
  testing key 1 (SIGN key) 
    RSA-X-509: Logging in to "PIV Card Holder pin (PIV_II)".
Please enter context specific PIN: 
OK
    RSA-PKCS: Logging in to "PIV Card Holder pin (PIV_II)".
Please enter context specific PIN: 
OK
  testing key 2 (KEY MAN key) 
    RSA-X-509: OK
    RSA-PKCS: OK
No errors
Nobozoa
  • 11
  • 5
  • First, the error is actually only `DATA_INVALID` (a bug I [fixed recently](https://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=45c8399d783876543e59b815d61d449eb9ee67ef#patch3)). However, that's strange as that error indicates that the data to be signed is somehow invalid. Maybe the token expects the data already hashed (i.e. exactly 32 bytes long), which would be incorrect, though (and depending on the negotiated PRF, the data could actually be 32 bytes long). I also wonder why there are so many signature attempts (you could try increasing the log levels). – ecdsa Nov 15 '19 at 14:11
  • Also, does it work if you use `pkcs11-tool --test --login ...`? – ecdsa Nov 15 '19 at 14:17
  • Hi and thanks for your answer. Here is the result of my pkcs11-tool --test --login command. There seems to be a problem with my crt (first slot contains a p12 certificate that has been created from the crt in second slot) (as i can't put it here, it's in my question) – Nobozoa Nov 15 '19 at 15:17
  • I changed logs for logs from loglevel 4 (maximum). It shows that it tries diverse RSA mechanism (and thats why there are multiple attempts) – Nobozoa Nov 15 '19 at 15:53
  • Hm, that many? Anyway, you evidently need to fix the data on your token or use the other key. – ecdsa Nov 18 '19 at 09:01
  • I did some changes (notably generating a new CSR directly from the key) and I directly edited my question, if you can help me ! – Nobozoa Nov 19 '19 at 14:09
  • Is a certificate for that identity (`B`) loaded from the token when the daemon starts? If that doesn't happen automatically, you could try loading it manually via a `cert` section (in `local`). – ecdsa Nov 19 '19 at 14:20
  • So i added certs = B.crt and i put B.crt onto /etc/swanctl/x509 directory. I got new logs now, i'll add it to my question – Nobozoa Nov 19 '19 at 16:05
  • Are you sure the handle/CKA_ID is correct? (You configured `1` but that might not be right one.) – ecdsa Nov 19 '19 at 16:56
  • Hi again. I did it again to be sure. I removed my crt and extracted a new one from my key to be sure. I removed every other crt from my key and i printed you the result of my pkcs11-tool -O to be sure. I updated my question as I have now another problem when trying to connect from A to B or from B to A (even when switching A). Anyway, thanks for putting so much efforts to help me ! I really appreciate that ! – Nobozoa Nov 20 '19 at 08:54
  • I may have a supposition. When I try with hosts with swanctl 5.6.2 I don't get those crashs, so it may be a problem with swanctl 5.8.2 (or with it's install as i built it from manual downlaod and used configure/Makefile) Then, I got this "no trusted RSA public key found". I signed my crt with the same CA as used for connection, but is CN is just "CN=B" when others crt and CA's crt have CN like "C=US, O=blabla, CN='My CN'". Even if I signed with the CA's crt, can this bad CN be the root of my problem ? And should I precise a SAN that look like my CA's one ? I'm a bit lost here – Nobozoa Nov 20 '19 at 09:09
  • Ok so after regenerating crt with a better CN now it works... Thanks for your help ! Anyway the bug on StrongSwan 5.8.2 seems odd, should I create a ticket at strongswan bug report for that ? Or is it because I failed at installing it beforehand ? – Nobozoa Nov 20 '19 at 09:59
  • It looks like you have a plugin (connmark) from an older installation that conflicts with the newer binaries. – ecdsa Nov 20 '19 at 16:25
  • That's odd, as I did not install StrongSwan before, but i'll look at it when I'll have more time ! – Nobozoa Nov 21 '19 at 07:53

1 Answers1

0

I finally made it works, thanks to ecdsa.

For people like me that are wondering how to make a host-host connection with StrongSwan using yubikey (Yubikey 5C in my case), my conf was working.

My problem was due to a bad install (some collisions between different StrongSwan versions that I installed)

Don't forget to put the crt onto the x509 directory on /etc/swanctl/x509 and it should normally works wonderfully !

Nobozoa
  • 11
  • 5