[strongSwan] Fwd: "No trusted RSA public key found for [..]" again

bluesky787 at posteo.de bluesky787 at posteo.de
Mon Sep 16 09:28:06 CEST 2019


Hello dear devs and community,

I am reaching out for you because I have done much research and still 
couldn’t find the issue, although this issue seems common to you - I 
found many threads in your mailing list.
I am using strongswan U5.5.1 on a Debian VM hosted on a Qubes system. 
Strongswan should act as a roadwarrior ikev2 client and can’t connect to 
the server because it’s refusing the server certificate with error “No 
trusted RSA public key found for ‘CN=LANCOM VPN’”. I am in control over 
the VPN server (a LANCOM router), the certificates and the VPN client. 
The server has no DNS name, but a static IP address.

I have checked all the recommended settings in the FAQ 
(https://wiki.strongswan.org/projects/strongswan/wiki/FAQ). These are:

- "The client transmits its certificate to the remote peer (Configure 
logging as shown on the HelpRequests page and search for "cert" without 
")"
    --> Check. The Log shows the cert by its CN.

- "The remote peer trusts the root CA that issued the client's 
certificate or the client's certificate is locally available and loaded 
(check with ipsec listcerts
    or swanctl --list-certs)"
    --> Check. I have created 3 certificates for testing purposes. The 
root cert is saved to \etc\ipsec.d\cacerts, the client cert under \certs 
is signed by the 	CA. For testing, I also imported the public server 
cert. Here's the output of --listcacerts and --listcerts:

List of X.509 CA Certificates

   subject:  	"O=LANCOM SYSTEMS, CN=LANCOM CA"
   issuer:   	"O=LANCOM SYSTEMS, CN=LANCOM CA"
   validity:  	not before Sep 11 02:00:00 2019, ok
              	not after  Sep 11 01:59:59 2029, ok (expires in 3650 days)
   serial:    	64:2b:c5:89:87:b1:7f:70
   altNames:  	XXX.XXX.XXX.XXX
   flags:     	CA CRLSign self-signed
   subjkeyId: 32:5f:ba:9b:cd:29:5d:b6:a0:87:94:c9:d8:3a:e0:7d:70:6a:b8:7d
   pubkey:    	RSA 4096 bits
   keyid:     eb:53:0e:57:20:c0:73:80:41:03:e8:ca:02:97:7c:1a:15:53:b6:34
   subjkey:   32:5f:ba:9b:cd:29:5d:b6:a0:87:94:c9:d8:3a:e0:7d:70:6a:b8:7d

List of X.509 End Entity Certificates

(Cert used by strongSwan Client)
   subject:  	"O=LANCOM SYSTEMS, CN=VPN USER"
   issuer:   	"O=LANCOM SYSTEMS, CN=LANCOM CA"
   validity:  	not before Sep 11 02:00:00 2019, ok
              	not after  Sep 11 01:59:59 2020, ok (expires in 363 days)
   serial:    	7c:06:26:a6:b6:59:55:3c
   flags:     	clientAuth
   authkeyId: 32:5f:ba:9b:cd:29:5d:b6:a0:87:94:c9:d8:3a:e0:7d:70:6a:b8:7d
   subjkeyId: 6c:d9:e9:62:c0:24:7a:a8:dc:db:a9:d8:92:c9:f1:5a:7c:5d:68:bb
   pubkey:    	RSA 4096 bits, has private key
   keyid:     7b:f7:25:55:a7:e4:de:87:26:76:f4:4b:23:a5:67:b9:0b:4e:dc:d0
   subjkey:   6c:d9:e9:62:c0:24:7a:a8:dc:db:a9:d8:92:c9:f1:5a:7c:5d:68:bb

(Cert used by VPN Server)
   subject:  	"O=LANCOM SYSTEMS, CN=XXX.XXX.XXX.XXX" <-- is real IP 
address, because it's mandatory for Windows 10 IKEv2 client.
   issuer:   	"O=LANCOM SYSTEMS, CN=LANCOM CA"
   validity:  	not before Sep 11 02:00:00 2019, ok
              	not after  Sep 11 01:59:59 2020, ok (expires in 363 days)
   serial:    	5b:24:46:95:a4:d8:b5:6c
   altNames:  	XXX.XXX.XXX.XXX
   flags:     	serverAuth ikeIntermediate
   authkeyId: 32:5f:ba:9b:cd:29:5d:b6:a0:87:94:c9:d8:3a:e0:7d:70:6a:b8:7d
   subjkeyId: f2:d6:fa:d5:41:c2:28:70:d1:e8:a8:d1:e5:3a:11:88:ad:11:c8:13
   pubkey:    	RSA 4096 bits
   keyid:     a2:d3:36:72:08:f7:b4:3d:4f:2b:08:6e:bf:19:b5:31:21:71:6b:06
   subjkey:   f2:d6:fa:d5:41:c2:28:70:d1:e8:a8:d1:e5:3a:11:88:ad:11:c8:13

- The remote peer's certificate is valid
    --> Check. See cert data upon.

- The remote peer's transmitted ID is either in one of its certificate's 
SAN fields with the correct type (type IP if it's an IP, type FQDN if 
it's a FQDN) or it is its certificate's whole DN (distinguished name)
    --> Check. I tried both using a VPN Server cert with 
"IP:XXX.XXX.XXX.XXX" in its SAN field (where XXX was the real IP 
address) and blank value in SAN field. In case it's blank, the CN of the 
cert should be used for authentication according to this blog: 
https://tiebing.blogspot.com/2016/03/no-trusted-rsa-public-key-found.html

What really confuses me is the CN in the error message: "No trusted RSA 
public key found for ‘CN=LANCOM VPN’", because no certificate uses this 
CN, nor any of the config files (see below) or the VPN server config. 
Where does this value come from?
I tried multiple logging levels. None of them shows a message between 
"received end entity cert "O=LANCOM SYSTEMS, CN= XXX.XXX.XXX.XXX"" and 
"no trusted RSA public key found for 'CN=LANCOM VPN'", so there's no 
clue.

Do you have any ideas? I welcome any help.

Regards,
Bluesky787

-------------------------------------------------------
Config files:

Ipsec.conf:

conn vpn-ikev2
         auto=start
         ike=aes256-sha256-sha512-modp4096!
         esp=aes256-sha256-sha512-modp4096!
         right= XXX.XXX.XXX.XXX
         rightid="O=LANCOM SYSTEMS,CN= XXX.XXX.XXX.XXX"
         rightsubnet=0.0.0.0/0
         rightauth=pubkey
         rightca= XXX.XXX.XXX.XXX #<-- I tried both ip address and 
filepath here - no change in error output
         rightcert=/etc/ipsec.d/certs/LANCOM_VPN_5.crt
         leftid="O=LANCOM SYSTEMS,CN=VPN USER"
         leftsourceip=%config
         leftauth=pubkey
         leftca="O=LANCOM SYSTEMS,CN=LANCOM CA"
         leftcert=/etc/ipsec.d/certs/VPN_User_5.crt

ipsec.secrets:

  : RSA /etc/ipsec.d/private/VPN_User_5.pem

strongswan.conf: No changes, despite some logging.

Here is the log (public static IP address Xed out):

user at Debian-9-StrongSwan-VPN:~$ sudo ipsec up vpn-ikev2 initiating 
IKE_SA vpn-ikev2[2] to XXX.XXX.XXX.XXX generating IKE_SA_INIT request 0 
[ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) 
N(REDIR_SUP) ] sending packet: from 10.137.0.9[500] to XXX.XXX.XXX.XXX 
[500] (736 bytes) received packet: from XXX.XXX.XXX.XXX [500] to 
10.137.0.9[500] (759 bytes) parsed IKE_SA_INIT response 0 [ SA KE No 
N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) N(FRAG_SUP) CERTREQ V ] received 
unknown vendor ID: 
81:75:2e:b5:91:4d:73:5c:df:cd:c8:58:c3:a8:ed:7c:1c:66:d1:42
local host is behind NAT, sending keep alives received 1 cert requests 
for an unknown ca sending cert request for "O=LANCOM SYSTEMS, CN=LANCOM 
CA"
authentication of 'O=LANCOM SYSTEMS, CN=VPN USER' (myself) with 
RSA_EMSA_PKCS1_SHA2_384 successful sending end entity cert "O=LANCOM 
SYSTEMS, CN=VPN USER"
establishing CHILD_SA vpn-ikev2
generating IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr 
AUTH CPRQ(ADDR DNS) SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(EAP_ONLY) 
] splitting IKE message with length of 2304 bytes into 2 fragments 
generating IKE_AUTH request 1 [ EF(1/2) ] generating IKE_AUTH request 1 
[ EF(2/2) ] sending packet: from 10.137.0.9[4500] to XXX.XXX.XXX.XXX 
[4500] (1236 bytes) sending packet: from 10.137.0.9[4500] to 
XXX.XXX.XXX.XXX [4500] (1156 bytes) received packet: from 
XXX.XXX.XXX.XXX [4500] to 10.137.0.9[4500] (1044 bytes) parsed IKE_AUTH 
response 1 [ EF(2/2) ] received fragment #2 of 2, waiting for complete 
IKE message received packet: from XXX.XXX.XXX.XXX [4500] to 
10.137.0.9[4500] (1236 bytes) parsed IKE_AUTH response 1 [ EF(1/2) ] 
received fragment #1 of 2, reassembling fragmented IKE message parsed 
IKE_AUTH response 1 [ IDr CERT AUTH CPRP(DNS DNS ADDR) TSi TSr 
N(INIT_CONTACT) SA ] received end entity cert "O=LANCOM SYSTEMS, CN= 
XXX.XXX.XXX.XXX"
no trusted RSA public key found for 'CN=LANCOM VPN'
generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ] sending packet: 
from 10.137.0.9[4500] to XXX.XXX.XXX.XXX [4500] (96 bytes) establishing 
connection 'vpn-ikev2' failed


More information about the Users mailing list