Strange problem with Strongswan/RockyLinux: Signature validation failed, looking for another

Nightowl82 · Sat Feb 10, 2024 11:28 am

hello everyone,

Duplicate of this thread in the strongswan-community forum on github:
https://github.com/strongswan/strongswa ... sions/2093

I am struggling with a to me absurd problem with strongswan on one of our RockyLinux Laptops. We have a working setup with a Mikrotik VPN gateway, wit LetsEncrypt-ceriticates, and EAP authentication. All clients windows, mac, ios, android and Linux (Debian and Fedora), are able to connect to the VPN gateway. And the RockyLinux laptop in question are able to connect to a similar Gateway running pfsense also with letsencrypt certificates.

I have tried the prebuilt package from EPEL-repository (5.9.10-1.el9), and I have tried to recompile the latest version from source (Linux strongSwan U5.9.13/K5.14.0-362.13.1.el9_3.x86_64), and both gives me the same error.

This is the output from a working client connecting from a Ferdora-laptop with strongswan (5.9.11), this is running via NetworkManager and charon-nm, but we get the same result using ipsec.conf / ipsec.secrets via the CLI:

feb. 09 12:57:08 [FEDORA-LAPTOP] charon-nm[361273]: 11[CFG] checking certificate status of "[CN=CERTIFICATE COMMON NAME]"
feb. 09 12:57:08 [FEDORA-LAPTOP] charon-nm[361273]: 11[CFG]   requesting ocsp status from 'http://r3.o.lencr.org' ...
feb. 09 12:57:08 [FEDORA-LAPTOP] charon-nm[361273]: 11[CFG]   ocsp response correctly signed by "C=US, O=Let's Encrypt, CN=R3"
feb. 09 12:57:08 [FEDORA-LAPTOP] charon-nm[361273]: 11[CFG]   ocsp response is valid: until Feb 16 00:03:58 2024
feb. 09 12:57:08 [FEDORA-LAPTOP] charon-nm[361273]: 11[CFG] certificate status is good
feb. 09 12:57:08 [FEDORA-LAPTOP] charon-nm[361273]: 11[CFG] checking certificate status of "C=US, O=Let's Encrypt, CN=R3"
feb. 09 12:57:08 [FEDORA-LAPTOP] charon-nm[361273]: 11[CFG]   fetching crl from 'http://x1.c.lencr.org/' ...
feb. 09 12:57:08 [FEDORA-LAPTOP] charon-nm[361273]: 11[CFG]   using trusted certificate "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
feb. 09 12:57:08 [FEDORA-LAPTOP] charon-nm[361273]: 11[CFG]   crl correctly signed by "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
feb. 09 12:57:08 [FEDORA-LAPTOP] charon-nm[361273]: 11[CFG]   crl is valid: until Mar 12 00:59:59 2024
feb. 09 12:57:08 [FEDORA-LAPTOP] charon-nm[361273]: 11[CFG] certificate status is good
feb. 09 12:57:08 [FEDORA-LAPTOP] charon-nm[361273]: 11[IKE] authentication of '[CN=CERTIFICATE COMMON NAME]' with RSA signature successful
feb. 09 12:57:08 [FEDORA-LAPTOP] charon-nm[361273]: 11[IKE] server requested EAP_IDENTITY (id 0x00), sending 'EAP-USER@DOMAIN'
feb. 09 12:57:08 [FEDORA-LAPTOP] charon-nm[361273]: 11[ENC] generating IKE_AUTH request 2 [ EAP/RES/ID ]
feb. 09 12:57:08 [FEDORA-LAPTOP] charon-nm[361273]: 11[NET] sending packet: from XXX.XXX.XXX.XXX[57179] to XXX.XXX.XXX.XXX[4500] (112 bytes)
feb. 09 12:57:08 [FEDORA-LAPTOP] charon-nm[361273]: 12[NET] received packet: from YYY.YYY.YYY.YYY[4500] to YYY.YYY.YYY.YYY[57179] (144 bytes)

And here is the output from the RockyLinux laptop that are failing to connect with the mikrotik Gateway:

Feb 10 09:43:20 [ROCKY-LAPTOP] charon[740492]: 14[IKE]  received end entity cert "[CN=CERTIFICATE COMMON NAME]""
Feb 10 09:43:20 [ROCKY-LAPTOP] charon[740492]: 14[CFG]   using certificate "[CN=CERTIFICATE COMMON NAME]"
Feb 10 09:43:20 [ROCKY-LAPTOP] charon[740492]: 14[CFG]   using untrusted intermediate certificate "C=US, O=Let's Encrypt, CN=R3"
Feb 10 09:43:20 [ROCKY-LAPTOP] charon[740492]: 14[CFG]   using trusted ca certificate "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
Feb 10 09:43:20 [ROCKY-LAPTOP] charon[740492]: 14[CFG] certificate policy 2.23.140.1.2.1 for '[CN=CERTIFICATE COMMON NAME]' not allowed by trustchain, ignored
Feb 10 09:43:20 [ROCKY-LAPTOP] charon[740492]: 14[CFG]   reached self-signed root ca with a path length of 1
Feb 10 09:43:20 [ROCKY-LAPTOP] charon[740492]: 14[CFG] checking certificate status of "[CN=CERTIFICATE COMMON NAME]"
Feb 10 09:43:20 [ROCKY-LAPTOP] charon[740492]: 14[CFG]   ocsp response is valid: until Feb 15 00:58:58 2024
Feb 10 09:43:20 [ROCKY-LAPTOP] charon[740492]: 14[CFG]   using cached ocsp response
Feb 10 09:43:20 [ROCKY-LAPTOP] charon[740492]: 14[CFG] certificate status is good
Feb 10 09:43:20 [ROCKY-LAPTOP] charon[740492]: 14[CFG] checking certificate status of "C=US, O=Let's Encrypt, CN=R3"
Feb 10 09:43:20 [ROCKY-LAPTOP] charon[740492]: 14[CFG]   using trusted certificate "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
Feb 10 09:43:20 [ROCKY-LAPTOP] charon[740492]: 14[CFG]   crl correctly signed by "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
Feb 10 09:43:20 [ROCKY-LAPTOP] charon[740492]: 14[CFG]   crl is valid: until Mar 12 00:59:59 2024
Feb 10 09:43:20 [ROCKY-LAPTOP] charon[740492]: 14[CFG]   using cached crl
Feb 10 09:43:20 [ROCKY-LAPTOP] charon[740492]: 14[CFG] certificate status is good
Feb 10 09:43:20 [ROCKY-LAPTOP] charon[740492]: 14[IKE] signature validation failed, looking for another key
Feb 10 09:43:20 [ROCKY-LAPTOP] charon[740492]: 14[ENC] generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]

And here is the output when the Rocky Linux laptop successfully connects to the pfsense-gateway:

Feb 10 09:58:34 [ROCKY-LAPTOP] charon[787301]: 13[IKE] received end entity cert "[CN=CERTIFICATE COMMON NAME]"
Feb 10 09:58:34 [ROCKY-LAPTOP] charon[787301]: 13[IKE] received issuer cert "C=US, O=Let's Encrypt, CN=R3"
Feb 10 09:58:34 [ROCKY-LAPTOP] charon[787301]: 13[CFG]   using certificate "[CN=CERTIFICATE COMMON NAME]"
Feb 10 09:58:34 [ROCKY-LAPTOP] charon[787301]: 13[CFG]   using untrusted intermediate certificate "C=US, O=Let's Encrypt, CN=R3"
Feb 10 09:58:34 [ROCKY-LAPTOP] charon[787301]: 13[CFG]   using trusted ca certificate "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
Feb 10 09:58:34 [ROCKY-LAPTOP] charon[787301]: 13[CFG] certificate policy 2.23.140.1.2.1 for 'CN=242.62-97-222.bkkb.no' not allowed by trustchain, ignored
Feb 10 09:58:34 [ROCKY-LAPTOP] charon[787301]: 13[CFG]   reached self-signed root ca with a path length of 1
Feb 10 09:58:34 [ROCKY-LAPTOP] charon[787301]: 13[CFG] checking certificate status of "[CN=CERTIFICATE COMMON NAME]"
Feb 10 09:58:34 [ROCKY-LAPTOP] charon[787301]: 13[CFG]   requesting ocsp status from 'http://r3.o.lencr.org' ...
Feb 10 09:58:34 [ROCKY-LAPTOP] charon[787301]: 13[CFG]   ocsp response correctly signed by "C=US, O=Let's Encrypt, CN=R3"
Feb 10 09:58:34 [ROCKY-LAPTOP] charon[787301]: 13[CFG]   ocsp response is valid: until Feb 17 09:57:58 2024
Feb 10 09:58:34 [ROCKY-LAPTOP] charon[787301]: 13[CFG] certificate status is good
Feb 10 09:58:34 [ROCKY-LAPTOP] charon[787301]: 13[CFG] checking certificate status of "C=US, O=Let's Encrypt, CN=R3"
Feb 10 09:58:34 [ROCKY-LAPTOP] charon[787301]: 13[CFG]   fetching crl from 'http://x1.c.lencr.org/' ...
Feb 10 09:58:34 [ROCKY-LAPTOP] charon[787301]: 13[CFG]   using trusted certificate "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
Feb 10 09:58:34 [ROCKY-LAPTOP] charon[787301]: 13[CFG]   crl correctly signed by "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
Feb 10 09:58:34 [ROCKY-LAPTOP] charon[787301]: 13[CFG]   crl is valid: until Mar 12 00:59:59 2024
Feb 10 09:58:34 [ROCKY-LAPTOP] charon[787301]: 13[CFG] certificate status is good
Feb 10 09:58:34 [ROCKY-LAPTOP] charon[787301]: 13[IKE] authentication of '[HOSTNAME (SAN:DNS-name]' with RSA_EMSA_PKCS1_SHA2_384 successful

I have tried all kinds of config options without any success, and I have tried tips from similar treads I have found through different searches. And the exact same config are working on other strongswan-instances running on fedora / debian.

My gut feeling is that somethings goes wrong with the verification of the certificate. It fails before the EAP-authentication even is tried. But i really cannot understand why it succeeds with the pfsense gateway and not with the mikrotik gateway.

Any tips, or suggestions, to make sense of this?

vingjfg · Sat Feb 10, 2024 1:48 pm

Can you check the IKE p1 proposal on the MT? From the last excerpt, it works with SHA-2 384.

Nightowl82 · Sat Feb 10, 2024 7:18 pm

Current config on MT:

#Phase 1:
/ip ipsec profile add enc-algorithm=aes-256,aes-128,3des hash-algorithm=sha256 name=ikev2-proposal
#Phase 2:
/ip ipsec proposal add auth-algorithms=sha256,sha1 name=ikev2-proposal pfs-group=none

I also attach screenshots from both pfsense and MT.

vingjfg · Sat Feb 10, 2024 7:35 pm

If I read this correctly, your ikev2 p1 has only sha1 defined. Can you add sha256?

Nightowl82 · Sat Feb 10, 2024 8:05 pm

I believe both sha1 and sha256 is active? I have tried to disable sha1 as well and only use sha256. Same problem.

Is it clear to you from the logs exactly what is going wrong here? Is it somehow connected to verifying the ceritificate? Would it be meaningfull to try with the same config, using PSK instead? Just as an experiement? Or is is a better way to pinpoint the exact failure?

vingjfg · Sat Feb 10, 2024 8:32 pm

My mistake, I missed the sha256 in the config. Your pfsense has pfs in phase 1, the MT config says none. Can you try setting one?

Nope, nothing obvious I see.

Nightowl82 · Sat Feb 10, 2024 9:31 pm

It looks like "none" means auto. At least when Iook in winbox. I tried a few diffrent ones, but it didn’t change anything. (edit: i confused myself, i tried to specify PFR-algoritms, I don’t believe pfsense is configured with PFS either)

I did a quick search, and by a coincidence, I found something interesting here:

https://wiki.strongswan.org/projects/st ... onnsection

left|rightauth = <auth method>

Authentication method to use locally (left) or require from the remote (right) side. Acceptable values are pubkey for public key encryption (RSA/ECDSA), psk for pre-shared key authentication, eap to [require the] use of the Extensible Authentication Protocol, and xauth for IKEv1 eXtended Authentication.

To require a trustchain public key strength for the remote side, specify the key type followed by the minimum strength in bits (for example ecdsa-384 or rsa-2048-ecdsa-256).

To limit the acceptable set of hashing algorithms for trustchain validation, append hash algorithms to pubkey or a key strength definition (for example pubkey-sha256-sha512, rsa-2048-sha256-sha384-sha512, or rsa-2048-sha256-ecdsa-256-sha256-sha384).

Since 5.3.0 and unless disabled in strongswan.conf, or explicit IKEv2 signature constraints are configured (see below), such key types and hash algorithms are also applied as constraints against IKEv2 signature authentication schemes used by the remote side.

Since 5.3.0 and if both peers support RFC 7427 ("Signature Authentication in IKEv2") specific hash algorithms to be used during IKEv2 authentication may be configured. The syntax is the same as above, but with ike: prefix (before 5.4.0 without that prefix). For example, with ike:pubkey-sha384-sha256 a public key signature scheme with either SHA-384 or SHA-256 would get used for authentication, in that order and depending on the hash algorithms supported by the peer.

If no specific hash algorithms are configured, the default is to prefer an algorithm that matches or exceeds the strength of the signature key. If no constraints with ike: prefix are configured any signature scheme constraint (without ike: prefix) will also apply to IKEv2 authentication, unless this is disabled in strongswan.conf (this is also the behavior before 5.4.0, which introduced the ike: prefix).

Since 5.6.1 RSASSA-PSS signatures are supported. To use or require them configure rsa/pss instead of rsa as in e.g. ike:rsa/pss-sha256. If pubkey or rsa constraints are configured RSASSA-PSS signatures will only be used/accepted if enabled in strongswan.conf.

If you look at the log from strongswan on the fedora-machine that successfully connects to MT:

feb. 09 12:57:08 [FEDORA-LAPTOP] charon-nm[361273]: 11[IKE] authentication of '[CN=CERTIFICATE COMMON NAME]' with RSA signature successful

vs. rocky-linux that fails at the same connection:

Feb 10 09:43:20 [ROCKY-LAPTOP] charon[740492]: 14[IKE] signature validation failed, looking for another key
Feb 10 09:43:20 [ROCKY-LAPTOP] charon[740492]: 14[ENC] generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]

vs. rocky-linux that succedes to connect to Pfsense:

Feb 10 09:58:34 [ROCKY-LAPTOP] charon[787301]: 13[IKE] authentication of '[HOSTNAME (SAN:DNS-name]' with RSA_EMSA_PKCS1_SHA2_384 successful

Maybe playing with the acceptable key-requirements/hashing algoritms could be worth trying.

Nightowl82 · Sat Feb 10, 2024 10:05 pm

Tried setting different constraints in ipsec.conf , and I tried to disable signature authentication in strongswan.conf

    signature_authentication = no
    signature_authentication_constraints = no

And I tried specifying Phase 2, PFS-groups. (I believe I had p1 and p2 confused in my first config code/post)

The same failure!

Nightowl82 · Sat Feb 10, 2024 10:16 pm

It looks like the two certificates from letsencrypt actually have different key size:

Screenshot from 2024-02-10 21-13-28.png

2048 (MT) vs 4096 (pfsense)

Nightowl82 · Sat Feb 10, 2024 10:40 pm

Some other discussions regarding similar poblems:

https://wiki.strongswan.org/issues/3343

https://users.strongswan.narkive.com/RD ... s-to-linux

https://wiki.strongswan.org/issues/3059

vingjfg · Sun Feb 11, 2024 9:39 am

It looks like the two certificates from letsencrypt actually have different key size:

Screenshot from 2024-02-10 21-13-28.png
2048 (MT) vs 4096 (pfsense)

I don't know - in the logs with the failure, the certificate status is found as "good", which would indicate that the certificate is accepted just fine. Same for the CRL though the one that doesn't work reports using the cached CRL, but that apart, that seems to be okay.

Feb 10 09:43:20 [ROCKY-LAPTOP] charon[740492]: 14[IKE]  received end entity cert "[CN=CERTIFICATE COMMON NAME]""
Feb 10 09:43:20 [ROCKY-LAPTOP] charon[740492]: 14[CFG]   using certificate "[CN=CERTIFICATE COMMON NAME]"
Feb 10 09:43:20 [ROCKY-LAPTOP] charon[740492]: 14[CFG]   using untrusted intermediate certificate "C=US, O=Let's Encrypt, CN=R3"
Feb 10 09:43:20 [ROCKY-LAPTOP] charon[740492]: 14[CFG]   using trusted ca certificate "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
Feb 10 09:43:20 [ROCKY-LAPTOP] charon[740492]: 14[CFG] certificate policy 2.23.140.1.2.1 for '[CN=CERTIFICATE COMMON NAME]' not allowed by trustchain, ignored
Feb 10 09:43:20 [ROCKY-LAPTOP] charon[740492]: 14[CFG]   reached self-signed root ca with a path length of 1
Feb 10 09:43:20 [ROCKY-LAPTOP] charon[740492]: 14[CFG] checking certificate status of "[CN=CERTIFICATE COMMON NAME]"
Feb 10 09:43:20 [ROCKY-LAPTOP] charon[740492]: 14[CFG]   ocsp response is valid: until Feb 15 00:58:58 2024
Feb 10 09:43:20 [ROCKY-LAPTOP] charon[740492]: 14[CFG]   using cached ocsp response
Feb 10 09:43:20 [ROCKY-LAPTOP] charon[740492]: 14[CFG] certificate status is good

https://users.strongswan.narkive.com/RD ... s-to-linux reports using SHA2-384, can you set that in the profile and see if it makes a difference?

I will look into creating a test setup for this, may come in the next days though.

Nightowl82 · Sun Feb 11, 2024 11:53 am

I would really appreciate any help, effort or insights in getting to bottom of this, we need working Ipsec, especially due to outgoing network-restrictions in one involved organization, where IPsec is the only allowed VPN-protocol. And if it won't work on RockyLinux, that would be a problem for all RedHAT Enterprise installations as well.

All Windows, mac and iOS clients, and are connecting flawlessly. (both over IPv4 and IPv6)

We have seen a problem with one Android (Motorola moto 5G) client using the native VPN client introduced in Android 11 (running Android 13 with LineageOS). But there we have no debug, and we can use alternatives like Wireguard, so solving that one is not that imminent. At the same time Samsung-phones with Android are connecting flawlessly via the native clients. But the andorid-strangeness could be related to the problem we are discussing here.

Here are alle active IPsec-settings on the MT:

# Phase 1
/ip ipsec profile add enc-algorithm=aes-256,aes-128,3des hash-algorithm=sha256 name=ikev2-proposal
# Phase 2
/ip ipsec proposal add auth-algorithms=sha256,sha1 name=ikev2-proposal pfs-group=none

/ip ipsec policy group add name=ikev2-group
/ip ipsec peer add exchange-mode=ike2 name=peer-ikev2 passive=yes profile=ikev2-proposal
/ip ipsec mode-config add address-pool=ipv4-pool_ikev2 address-prefix-length=32 name=ikev2-config_v4 split-include=0.0.0.0/0

# Notice the certificate config, we are "chaining" the intermediate Ca-certificate so that we we don't need to install it on our clients. (I have tried without chaining the intermediate certificates as well, with the same problem)

/ip ipsec identity add auth-method=eap-radius certificate=letsencrypt-autogen_2024-02-05T11:19:41Z,lets-encrypt-r3 generate-policy=port-strict mode-config=ikev2-config_v4 peer=peer-ikev2 policy-template-group=ikev2-group
/ip ipsec policy add dst-address=172.18.43.128/25 group=ikev2-group proposal=ikev2-proposal src-address=0.0.0.0/0 template=yes

# This line is disabled. We are looking at ways to enable IPv6 for Roadwarrior-clients over ipsec on MT as well, but that is a different project/inquiry.
/ip ipsec policy add disabled=yes dst-address=fdd0:172:18:43:1::/80 group=ikev2-group proposal=ikev2-proposal template=yes

Is there any better way to debug the problem? Wireshark for instance?

I have tried setting SHA2-384, both on the MT-side and force it in the client's strongswan config, resulting in the same error.
I did a new test now, setting HASH and PRF algoritms with SHA256 or SHA384 (+enable all encryption algorithms and DH-groups), but still the same result: "signature validation failed, looking for another key"

/ip ipsec profile add dh-group=ecp256,ecp384,ecp521,modp8192,modp6144,modp4096,modp3072,modp2048,modp1536,modp1024,modp768 enc-algorithm=aes-256,aes-192,aes-128,3des,des hash-algorithm=sha256 name=ikev2-proposal prf-algorithm=sha256
/ip ipsec profile add dh-group=ecp256,ecp384,ecp521,modp8192,modp6144,modp4096,modp3072,modp2048,modp1536,modp1024,modp768 enc-algorithm=aes-256,aes-192,aes-128,3des,des hash-algorithm=sha384 name=ikev2-proposal prf-algorithm=sha384

Seen from winbox:

Screenshot from 2024-02-11 10-44-57.png

Screenshot from 2024-02-11 10-44-09.png

Nightowl82 · Sun Feb 11, 2024 12:10 pm

Some further notes about the strongswan client:

I had to choose disable-gpm (GNU GPM / https://en.wikipedia.org/wiki/GNU_Multi ... ic_Library) and enable openssl to be able to compile the strongswan source-code. I am not certain why it wasn't able to find the gmp-library, and I don't know the build options used in the precompile package, but this could be related to the problem.

I also compiled with --enable-curl.

The final configure-command was:
./configure --disable-gmp --enable-openssl --enable-curl

Our basic ipsec.conf (we have tried to switch a lot of options here as well, as explained in the post abobe)

conn [FQDN of the VPN-gateway]
    auto=start
    right=[FQDN of the VPN-gateway]
    rightid=[FQDN  of the VPN-gateway / CERTIFICATE COMMON NAME / or %any]
    rightsubnet=0.0.0.0/0,::/0
    rightauth=pubkey
    leftsourceip=%config4,%config6
    leftid=[ EAP IDENTITY ]
    leftauth=eap-mschapv2
    eap_identity=[ EAP IDENTITY ]

Nightowl82 · Sun Feb 11, 2024 12:27 pm

Did some digging into the hypothesisn about disabling the GMP, and found the issue, so I was now able to do a new compilation using GMP and without OpenSSL.

But still the same result:

Feb 11 11:23:38 [ROCKY-LAPTOP] charon [1023801]: 13[CFG] checking certificate status of "C=US, O=Let's Encrypt, CN=R3"
Feb 11 11:23:38 [ROCKY-LAPTOP]  charon[1023801]: 13[CFG]   using trusted certificate "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
Feb 11 11:23:38 [ROCKY-LAPTOP]  charon[1023801]: 13[CFG]   crl correctly signed by "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
Feb 11 11:23:38 [ROCKY-LAPTOP]  charon[1023801]: 13[CFG]   crl is valid: until Mar 12 00:59:59 2024
Feb 11 11:23:38 [ROCKY-LAPTOP]  charon[1023801]: 13[CFG]   using cached crl
Feb 11 11:23:38 [ROCKY-LAPTOP]  charon[1023801]: 13[CFG] certificate status is good
Feb 11 11:23:38 [ROCKY-LAPTOP]  charon[1023801]: 13[IKE] signature validation failed, looking for another key
Feb 11 11:23:38 [ROCKY-LAPTOP]  charon[1023801]: 13[ENC] generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]

Nightowl82 · Sun Feb 11, 2024 5:40 pm

A new test with a clean debian VM, first test with bookwom, then upgrading to latest testing which include the newest strongswan.

root@strongswan-test:~# uname -a
Linux strongswan-test 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linux

Packages in addition to the basic system (with gnome-UI):

root@strongswan-test:~# apt install strongswan network-manager-strongswan libcharon-extra-plugins libcharon-extauth-plugins

Strongswan 5.9.8:

root@strongswan-test:~# ipsec --version
Linux strongSwan U5.9.8/K6.1.0-18-amd64
University of Applied Sciences Rapperswil, Switzerland
root@strongswan-test:~#

Configuring through network-manager:

Screenshot from 2024-02-11 15-45-48.png

Everything behaves beautiful:

Feb 11 14:35:29 strongswan-test charon-nm[2216]: 05[IKE] received end entity cert "CN=[ Certificate Common Name ]"
Feb 11 14:35:29 strongswan-test charon-nm[2216]: 05[IKE] received issuer cert "C=US, O=Let's Encrypt, CN=R3"
Feb 11 14:35:29 strongswan-test charon-nm[2216]: 05[CFG]   using certificate "CN=[ Certificate Common Name ]"
Feb 11 14:35:29 strongswan-test charon-nm[2216]: 05[CFG]   using untrusted intermediate certificate "C=US, O=Let's Encrypt, CN=R3"
Feb 11 14:35:29 strongswan-test charon-nm[2216]: 05[CFG]   using trusted ca certificate "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
Feb 11 14:35:29 strongswan-test charon-nm[2216]: 05[CFG] certificate policy 2.23.140.1.2.1 for 'CN=[ Certificate Common Name ]' not allowed by trustchain, ignored
Feb 11 14:35:29 strongswan-test charon-nm[2216]: 05[CFG]   reached self-signed root ca with a path length of 1
Feb 11 14:35:29 strongswan-test charon-nm[2216]: 05[CFG] checking certificate status of "CN=[ Certificate Common Name ]"
Feb 11 14:35:29 strongswan-test charon-nm[2216]: 05[CFG]   requesting ocsp status from 'http://r3.o.lencr.org' ...
Feb 11 14:35:29 strongswan-test charon-nm[2216]: 05[CFG]   ocsp response correctly signed by "C=US, O=Let's Encrypt, CN=R3"
Feb 11 14:35:29 strongswan-test charon-nm[2216]: 05[CFG]   ocsp response is valid: until Feb 17 17:20:58 2024
Feb 11 14:35:29 strongswan-test charon-nm[2216]: 05[CFG] certificate status is good
Feb 11 14:35:29 strongswan-test charon-nm[2216]: 05[CFG] checking certificate status of "C=US, O=Let's Encrypt, CN=R3"
Feb 11 14:35:29 strongswan-test charon-nm[2216]: 05[CFG] ocsp response verification failed, no signer certificate 'C=US, O=Let's Encrypt, CN=R3' found
Feb 11 14:35:29 strongswan-test charon-nm[2216]: 05[CFG]   fetching crl from 'http://x1.c.lencorg/' ...
Feb 11 14:35:29 strongswan-test charon-nm[2216]: 05[CFG]   using trusted certificate "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
Feb 11 14:35:29 strongswan-test charon-nm[2216]: 05[CFG]   crl correctly signed by "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
Feb 11 14:35:29 strongswan-test charon-nm[2216]: 05[CFG]   crl is valid: until Mar 11 23:59:59 2024
Feb 11 14:35:29 strongswan-test charon-nm[2216]: 05[CFG] certificate status is good
Feb 11 14:35:29 strongswan-test charon-nm[2216]: 05[IKE] authentication of 'CN=[ Certificate Common Name ]' with RSA signature successful
Feb 11 14:35:29 strongswan-test charon-nm[2216]: 05[IKE] server requested EAP_IDENTITY (id 0x00), sending '[ EAP USER ]'
Feb 11 14:35:29 strongswan-test charon-nm[2216]: 05[ENC] generating IKE_AUTH request 2 [ EAP/RES/ID ]
Feb 11 14:35:29 strongswan-test charon-nm[2216]: 05[NET] sending packet: from [ Client IPv6-address ][38255] to [ MT VPN GW IPv6-address ][4500] (96 bytes)
Feb 11 14:35:29 strongswan-test charon-nm[2216]: 14[NET] received packet: from [ MT VPN GW IPv6-address ][4500] to [ Client IPv6-address ][38255] (336 bytes)
Feb 11 14:35:29 strongswan-test charon-nm[2216]: 14[ENC] parsed IKE_AUTH response 2 [ EAP/REQ/MSCHAPV2 ]
Feb 11 14:35:29 strongswan-test charon-nm[2216]: 14[IKE] server requested EAP_MSCHAPV2 authentication (id 0x01)
Feb 11 14:35:29 strongswan-test charon-nm[2216]: 14[ENC] generating IKE_AUTH request 3 [ EAP/RES/MSCHAPV2 ]
Feb 11 14:35:29 strongswan-test charon-nm[2216]: 14[NET] sending packet: from [ Client IPv6-address ][38255] to [ MT VPN GW IPv6-address ][4500] (144 bytes)
Feb 11 14:35:29 strongswan-test charon-nm[2216]: 13[NET] received packet: from [ MT VPN GW IPv6-address ][4500] to [ Client IPv6-address ][38255] (224 bytes)
Feb 11 14:35:29 strongswan-test charon-nm[2216]: 13[ENC] parsed IKE_AUTH response 3 [ EAP/REQ/MSCHAPV2 ]
Feb 11 14:35:29 strongswan-test charon-nm[2216]: 13[IKE] EAP-MS-CHAPv2 succeeded: '(null)'

After upgrading to the latest testing:

root@strongswan-test:~# uname -a
Linux strongswan-test 6.6.13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.6.13-1 (2024-01-20) x86_64 GNU/Linux

Newest version of strongswan:

root@strongswan-test:~# ipsec --version
Linux strongSwan U5.9.13/K6.6.13-amd64
University of Applied Sciences Rapperswil, Switzerland
root@strongswan-test:~#

Still working beautiful (including more log):

Feb 11 15:26:21 strongswan-test charon-nm[2452]: 09[IKE] received issuer cert "C=US, O=Let's Encrypt, CN=R3"
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 09[CFG]   using certificate "CN=[ Certificate Common Name ]"
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 09[CFG]   using untrusted intermediate certificate "C=US, O=Let's Encrypt, CN=R3"
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 09[CFG]   using trusted ca certificate "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 09[CFG] certificate policy 2.23.140.1.2.1 for 'CN=[ Certificate Common Name ]' not allowed by trustchain, ignored
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 09[CFG]   reached self-signed root ca with a path length of 1
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 09[CFG] checking certificate status of "CN=[ Certificate Common Name ]"
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 09[CFG]   requesting ocsp status from 'http://r3.o.lencr.org' ...
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 09[CFG]   ocsp response correctly signed by "C=US, O=Let's Encrypt, CN=R3"
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 09[CFG]   ocsp response is valid: until Feb 17 17:20:58 2024
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 09[CFG] certificate status is good
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 09[CFG] checking certificate status of "C=US, O=Let's Encrypt, CN=R3"
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 09[CFG]   fetching crl from 'http://x1.c.lencr.org/' ...
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 09[CFG]   using trusted certificate "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 09[CFG]   crl correctly signed by "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 09[CFG]   crl is valid: until Mar 11 23:59:59 2024
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 09[CFG] certificate status is good
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 09[IKE] authentication of 'CN=[ Certificate Common Name ]' with RSA signature successful
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 09[IKE] server requested EAP_IDENTITY (id 0x00), sending '[ EAP USER ]'
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 09[ENC] generating IKE_AUTH request 2 [ EAP/RES/ID ]
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 09[NET] sending packet: from [ Client IPv6-address ][60077] to [ MT VPN GW IPv6-address ][4500] (96 bytes)
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 05[NET] received packet: from [ MT VPN GW IPv6-address ][4500] to [ Client IPv6-address ][60077] (112 bytes)
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 05[ENC] parsed IKE_AUTH response 2 [ EAP/REQ/MSCHAPV2 ]
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 05[IKE] server requested EAP_MSCHAPV2 authentication (id 0x01)
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 05[ENC] generating IKE_AUTH request 3 [ EAP/RES/MSCHAPV2 ]
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 05[NET] sending packet: from [ Client IPv6-address ][60077] to [ MT VPN GW IPv6-address ][4500] (144 bytes)
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 12[NET] received packet: from [ MT VPN GW IPv6-address ][4500] to [ Client IPv6-address ][60077] (224 bytes)
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 12[ENC] parsed IKE_AUTH response 3 [ EAP/REQ/MSCHAPV2 ]
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 12[IKE] EAP-MS-CHAPv2 succeeded: '(null)'
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 12[ENC] generating IKE_AUTH request 4 [ EAP/RES/MSCHAPV2 ]
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 12[NET] sending packet: from [ Client IPv6-address ][60077] to [ MT VPN GW IPv6-address ][4500] (80 bytes)
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 04[NET] received packet: from [ MT VPN GW IPv6-address ][4500] to [ Client IPv6-address ][60077] (240 bytes)
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 04[ENC] parsed IKE_AUTH response 4 [ EAP/SUCC ]
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 04[IKE] EAP method EAP_MSCHAPV2 succeeded, MSK established
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 04[IKE] authentication of '[ EAP USER ]' (myself) with EAP
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 04[ENC] generating IKE_AUTH request 5 [ AUTH ]
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 04[NET] sending packet: from [ Client IPv6-address ][60077] to [ MT VPN GW IPv6-address ][4500] (112 bytes)
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 13[NET] received packet: from [ MT VPN GW IPv6-address ][4500] to [ Client IPv6-address ][60077] (1220 bytes)
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 13[ENC] parsed IKE_AUTH response 5 [ EF(1/3) ]
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 13[ENC] received fragment #1 of 3, waiting for complete IKE message
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 02[NET] received packet: from [ MT VPN GW IPv6-address ][4500] to [ Client IPv6-address ][60077] (1124 bytes)
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 02[ENC] parsed IKE_AUTH response 5 [ EF(2/3) ]
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 02[ENC] received fragment #2 of 3, waiting for complete IKE message
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 07[NET] received packet: from [ MT VPN GW IPv6-address ][4500] to [ Client IPv6-address ][60077] (1300 bytes)
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 07[ENC] parsed IKE_AUTH response 5 [ EF(3/3) ]
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 07[ENC] received fragment #3 of 3, reassembled fragmented IKE message (3088 bytes)
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 07[ENC] parsed IKE_AUTH response 5 [ IDr AUTH CERT CERT N(INIT_CONTACT) CPRP(ADDR MASK SUBNET DNS DNS) TSi TSr SA ]
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 07[IKE] authentication of 'CN=[ Certificate Common Name ]' with EAP successful
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 07[CFG] handling INTERNAL_IP4_NETMASK attribute failed
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 07[CFG] handling INTERNAL_IP4_SUBNET attribute failed
Feb 11 15:26:21 strongswan-test charon-nm[2452]: 07[IKE] installing new virtual IP 172.18.43.253

Maybe I will test a clean Rocky Linux VM as well, just to check if there is something wrong with the Rocky Laptop in question!

Or if it is connected to the distribution.

Nightowl82 · Mon Feb 12, 2024 12:16 pm

We have a solution thanks to Thobias Burner on the strongswan github-forum:

https://github.com/strongswan/strongswa ... sions/2093

The MikroTik box seems to not support RFC7427-style signature authentication:

feb. 09 12:57:08 [FEDORA-LAPTOP] charon-nm[361273]: 11[IKE] authentication of '[CN=CERTIFICATE COMMON NAME]' with RSA signature successful

This means it creates that signature with SHA-1.

That in turn might be disabled on your Rocky Linux box. If SHA-1 is provided via OpenSSL, you could adjust the system-wide policy to allow RSA signatures with SHA-1 in OpenSSL via sudo update-crypto-policies --set DEFAULT:SHA1 (this basically sets rh-allow-sha1-signatures = yes in openssl.cnf, so this could theoretically also be set for strongSwan only if you get it to load its own openssl.cnf e.g. via OPENSSL_CONF).

Just did a quick test from my rocky-laptop:

Feb 12 11:05:13  [ROCKY-LAPTOP] charon[1181230]: 14[IKE] authentication of '[CN=CERTIFICATE COMMON NAME]' with RSA signature successful

Now I can finally put this to rest!

Strange problem with Strongswan/RockyLinux: Signature validation failed, looking for another [SOLVED]

Strange problem with Strongswan/RockyLinux: Signature validation failed, looking for another [SOLVED]

Re: Strange problem with Strongswan/RockyLinux: Signature validation failed, looking for another

Re: Strange problem with Strongswan/RockyLinux: Signature validation failed, looking for another

Re: Strange problem with Strongswan/RockyLinux: Signature validation failed, looking for another

Re: Strange problem with Strongswan/RockyLinux: Signature validation failed, looking for another

Re: Strange problem with Strongswan/RockyLinux: Signature validation failed, looking for another

Re: Strange problem with Strongswan/RockyLinux: Signature validation failed, looking for another

Re: Strange problem with Strongswan/RockyLinux: Signature validation failed, looking for another

Re: Strange problem with Strongswan/RockyLinux: Signature validation failed, looking for another

Re: Strange problem with Strongswan/RockyLinux: Signature validation failed, looking for another

Re: Strange problem with Strongswan/RockyLinux: Signature validation failed, looking for another

Re: Strange problem with Strongswan/RockyLinux: Signature validation failed, looking for another

Re: Strange problem with Strongswan/RockyLinux: Signature validation failed, looking for another

Re: Strange problem with Strongswan/RockyLinux: Signature validation failed, looking for another

Re: Strange problem with Strongswan/RockyLinux: Signature validation failed, looking for another

Re: Strange problem with Strongswan/RockyLinux: Signature validation failed, looking for another