Project

General

Profile

Bug #849

Failure during TLS authentication if CA and end-entity certificate share the same subject DN

Added by Jan Bonczek over 7 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Tobias Brunner
Category:
configuration
Target version:
5.3.0
Start date:
16.02.2015
Due date:
Estimated time:
Affected version:
5.2.2
Resolution:
Fixed

Description

Hi

I trying connect my WP 8.1 to strongswan 5.1.2. My config works good with Android 4.x but I don't no, why WP 8.1 couldn't connect.

My ipsec.conf

  1. ipsec.conf - strongSwan IPsec configuration file
  1. basic configuration
config setup
        #strictcrlpolicy=yes
         #uniqueids = never
conn %default
        keyexchange=ikev2
        ike=aes256-sha1-modp1024!
        esp=aes256-sha1!
        dpdaction=clear
        dpddelay=300s
        rekey=no
conn ikev2
        left=%defaultroute
        leftsubnet=10.1.0.0/24
        leftauth=pubkey
    leftid=192.168.0.108
        leftcert=serverCert.pem
    rightsourceip=10.20.0.0/24
    #rightsubnet=0.0.0.0/0
        right=%any
    #rightcert=clientCert.pem
    #rightauth=pubkey
    #rightid=client
    #rightauth2=eap-mschapv2
        #rightsendcert=never
        #eap_identity=%any
        auto=add

ipsec.secrets

: RSA serverKey.pem
 : EAP "123456"  #<your_password> in my case: 123456

var/log/syslog 

Feb 16 14:41:13 honza-U36JC charon: 14[NET] received packet: from 192.168.0.100[500] to 192.168.0.108[500] (616 bytes)
 Feb 16 14:41:13 honza-U36JC charon: 14[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) V V V V ]
 Feb 16 14:41:13 honza-U36JC charon: 14[ENC] received unknown vendor ID: 1e:2b:51:69:05:99:1c:7d:7c:96:fc:bf:b5:87:e4:61:00:00:00:09
 Feb 16 14:41:13 honza-U36JC charon: 14[ENC] received unknown vendor ID: fb:1d:e3:cd:f3:41:b7:ea:16:b7:e5:be:08:55:f1:20
 Feb 16 14:41:13 honza-U36JC charon: 14[ENC] received unknown vendor ID: 26:24:4d:38:ed:db:61:b3:17:2a:36:e3:d0:cf:b8:19
 Feb 16 14:41:13 honza-U36JC charon: 14[ENC] received unknown vendor ID: 01:52:8b:bb:c0:06:96:12:18:49:ab:9a:1c:5b:2a:51:00:00:00:02
 Feb 16 14:41:13 honza-U36JC charon: 14[IKE] 192.168.0.100 is initiating an IKE_SA
 Feb 16 14:41:13 honza-U36JC charon: 14[IKE] sending cert request for "C=CH, O=strongSwan, CN=192.168.0.108" 
 Feb 16 14:41:13 honza-U36JC charon: 14[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ]
 Feb 16 14:41:13 honza-U36JC charon: 14[NET] sending packet: from 192.168.0.108[500] to 192.168.0.100[500] (337 bytes)
 Feb 16 14:41:13 honza-U36JC charon: 13[NET] received packet: from 192.168.0.100[4500] to 192.168.0.108[4500] (652 bytes)
 Feb 16 14:41:13 honza-U36JC charon: 13[ENC] parsed IKE_AUTH request 1 [ IDi CERTREQ N(MOBIKE_SUP) CPRQ(ADDR DNS NBNS SRV ADDR6 DNS6 SRV6) SA TSi TSr ]
 Feb 16 14:41:13 honza-U36JC charon: 13[IKE] received cert request for "C=CH, O=strongSwan, CN=192.168.0.108" 
 Feb 16 14:41:13 honza-U36JC charon: 13[IKE] received 15 cert requests for an unknown ca
 Feb 16 14:41:13 honza-U36JC charon: 13[CFG] looking for peer configs matching 192.168.0.108[%any]...192.168.0.100[192.168.0.100]
 Feb 16 14:41:13 honza-U36JC charon: 13[CFG] selected peer config 'ikev2'
 Feb 16 14:41:13 honza-U36JC charon: 13[IKE] peer requested EAP, config inacceptable
 Feb 16 14:41:13 honza-U36JC charon: 13[CFG] no alternative config found
 Feb 16 14:41:13 honza-U36JC charon: 13[IKE] peer supports MOBIKE
 Feb 16 14:41:13 honza-U36JC charon: 13[ENC] generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]
 Feb 16 14:41:13 honza-U36JC charon: 13[NET] sending packet: from 192.168.0.108[4500] to 192.168.0.100[4500] (76 bytes)

Problem is probably here "peer requested EAP, config inacceptable" but I don't no how this repair.

Certificates was generated as follow

ipsec pki --pub --in serverKey.pem | ipsec pki --issue --cacert caCert.pem --cakey caKey.pem --san 192.168.0.108 --dn "C=CH, O=strongSwan, CN=192.168.0.108" --flag servAuth --outform pem > serverCert.pem
ipsec pki --pub --in clientKey.pem | ipsec pki --issue --cacert caCert.pem --cakey caKey.pem --san client --dn "C=CH, O=strongSwan, CN=client" --flag clientAuth --outform pem > clientCert.pem
openssl pkcs12 -export -inkey clientKey.pem -in clientCert.pem -name "client" -certfile caCert.pem -caname "strongSwan" -out cliP12test.p12

Thanks for help

notWorking.tar.gz (8 KB) notWorking.tar.gz Jan Bonczek, 19.02.2015 23:16
working.tar.gz (8.17 KB) working.tar.gz Jan Bonczek, 19.02.2015 23:17

Associated revisions

Revision 18597950 (diff)
Added by Tobias Brunner over 7 years ago

tls-peer: Make sure to use the right trusted public key for peer

In case a CA certificate uses the same subject DN as the server the
previous code could end up trying to verify the server's signature with
the CA certificate's public key. By comparing the certificate with the
one sent by the peer we make sure to use the right one.

Fixes #849.

History

#1 Updated by Jan Bonczek over 7 years ago

My previous solution is probably bad for WP 8.1. I try this solution with eap-tls https://wiki.strongswan.org/projects/strongswan/wiki/Win7UserMultipleConfig and that probably works good.

But i have to add

eap_identity=%identity

to client join.

When I tried without eap_identity=%identity connecting fault with this error

no trusted certificate found for '192.168.0.100' to verify TLS peer
 Feb 16 15:52:13 honza-U36JC charon: 12[TLS] sending fatal TLS alert 'certificate unknown'

Is this solution correct? What is the reason this error?

Thanks for the answer

#2 Updated by Tobias Brunner over 7 years ago

  • Category set to configuration
  • Status changed from New to Feedback

As described on our wiki Windows 7 and newer support two certificate authentication schemes. But it's possible that on WP only user certificates can be used (maybe due to security concerns if regular phone users can install machine certificates), so yes the EAP-TLS configuration is probably the way to go.

I've added eap_identity=%identity to Win7UserMultipleConfig, thanks for the hint. Without it the certificate is searched based on the IKEv2 identity, which in this case equals the client's IP address. During the EAP-Identity exchange the client will send the certificate's subject DN to the server so it is then able to find the right certificate.

#3 Updated by Jan Bonczek over 7 years ago

Thanks for response.

EAP-TLS works good with WP. Now I trying use the same config to connect Android with Android StrongSwan app that support EAP-TLS to. I try it with the same certificate ( certtificate that are use for win) and Android couldn't connect.

/var/log/syslog

Feb 18 22:14:40 honza-U36JC charon: 13[NET] received packet: from 192.168.0.103[33719] to 192.168.0.108[500] (996 bytes)
Feb 18 22:14:40 honza-U36JC charon: 13[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N((16430)) ]
Feb 18 22:14:40 honza-U36JC charon: 13[IKE] 192.168.0.103 is initiating an IKE_SA
Feb 18 22:14:40 honza-U36JC charon: 13[IKE] remote host is behind NAT
Feb 18 22:14:40 honza-U36JC charon: 13[IKE] DH group MODP_2048 inacceptable, requesting MODP_1024
Feb 18 22:14:40 honza-U36JC charon: 13[ENC] generating IKE_SA_INIT response 0 [ N(INVAL_KE) ]
Feb 18 22:14:40 honza-U36JC charon: 13[NET] sending packet: from 192.168.0.108[500] to 192.168.0.103[33719] (38 bytes)
Feb 18 22:14:40 honza-U36JC charon: 14[NET] received packet: from 192.168.0.103[33719] to 192.168.0.108[500] (868 bytes)
Feb 18 22:14:40 honza-U36JC charon: 14[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N((16430)) ]
Feb 18 22:14:40 honza-U36JC charon: 14[IKE] 192.168.0.103 is initiating an IKE_SA
Feb 18 22:14:40 honza-U36JC charon: 14[IKE] remote host is behind NAT
Feb 18 22:14:40 honza-U36JC charon: 14[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(MULT_AUTH) ]
Feb 18 22:14:40 honza-U36JC charon: 14[NET] sending packet: from 192.168.0.108[500] to 192.168.0.103[33719] (312 bytes)
Feb 18 22:14:40 honza-U36JC charon: 15[NET] received packet: from 192.168.0.103[54718] to 192.168.0.108[4500] (572 bytes)
Feb 18 22:14:40 honza-U36JC charon: 15[ENC] parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) CERTREQ CPRQ(ADDR ADDR6 DNS DNS6) N(ESP_TFC_PAD_N) SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) N(EAP_ONLY) ]
Feb 18 22:14:40 honza-U36JC charon: 15[IKE] received cert request for "C=CH, O=strongSwan, CN=192.168.0.108" 
Feb 18 22:14:40 honza-U36JC charon: 15[CFG] looking for peer configs matching 192.168.0.108[%any]...192.168.0.103[C=CH, O=strongSwan, CN=client]
Feb 18 22:14:40 honza-U36JC charon: 15[CFG] selected peer config 'winCert'
Feb 18 22:14:40 honza-U36JC charon: 15[IKE] initiating EAP_IDENTITY method (id 0x00)
Feb 18 22:14:40 honza-U36JC charon: 15[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Feb 18 22:14:40 honza-U36JC charon: 15[IKE] peer supports MOBIKE
Feb 18 22:14:40 honza-U36JC charon: 15[IKE] authentication of '192.168.0.108' (myself) with RSA signature successful
Feb 18 22:14:40 honza-U36JC charon: 15[IKE] sending end entity cert "C=CH, O=strongSwan, CN=192.168.0.108" 
Feb 18 22:14:40 honza-U36JC charon: 15[ENC] generating IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ]
Feb 18 22:14:40 honza-U36JC charon: 15[NET] sending packet: from 192.168.0.108[4500] to 192.168.0.103[54718] (1196 bytes)
Feb 18 22:14:40 honza-U36JC charon: 06[NET] received packet: from 192.168.0.103[54718] to 192.168.0.108[4500] (124 bytes)
Feb 18 22:14:40 honza-U36JC charon: 06[ENC] parsed IKE_AUTH request 2 [ EAP/RES/ID ]
Feb 18 22:14:40 honza-U36JC charon: 06[IKE] received EAP identity 'C=CH, O=strongSwan, CN=client'
Feb 18 22:14:40 honza-U36JC charon: 06[IKE] initiating EAP_TLS method (id 0x93)
Feb 18 22:14:40 honza-U36JC charon: 06[ENC] generating IKE_AUTH response 2 [ EAP/REQ/TLS ]
Feb 18 22:14:40 honza-U36JC charon: 06[NET] sending packet: from 192.168.0.108[4500] to 192.168.0.103[54718] (76 bytes)
Feb 18 22:14:40 honza-U36JC charon: 07[NET] received packet: from 192.168.0.103[54718] to 192.168.0.108[4500] (252 bytes)
Feb 18 22:14:40 honza-U36JC charon: 07[ENC] parsed IKE_AUTH request 3 [ EAP/RES/TLS ]
Feb 18 22:14:40 honza-U36JC charon: 07[TLS] negotiated TLS 1.2 using suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
Feb 18 22:14:40 honza-U36JC charon: 07[TLS] sending TLS server certificate 'C=CH, O=strongSwan, CN=192.168.0.108'
Feb 18 22:14:40 honza-U36JC charon: 07[TLS] sending TLS cert request for 'C=CH, O=strongSwan, CN=192.168.0.108'
Feb 18 22:14:40 honza-U36JC charon: 07[ENC] generating IKE_AUTH response 3 [ EAP/REQ/TLS ]
Feb 18 22:14:40 honza-U36JC charon: 07[NET] sending packet: from 192.168.0.108[4500] to 192.168.0.103[54718] (588 bytes)
Feb 18 22:14:40 honza-U36JC charon: 08[NET] received packet: from 192.168.0.103[54718] to 192.168.0.108[4500] (76 bytes)
Feb 18 22:14:40 honza-U36JC charon: 08[ENC] parsed IKE_AUTH request 4 [ EAP/RES/TLS ]
Feb 18 22:14:40 honza-U36JC charon: 08[ENC] generating IKE_AUTH response 4 [ EAP/REQ/TLS ]
Feb 18 22:14:40 honza-U36JC charon: 08[NET] sending packet: from 192.168.0.108[4500] to 192.168.0.103[54718] (588 bytes)
Feb 18 22:14:40 honza-U36JC charon: 16[NET] received packet: from 192.168.0.103[54718] to 192.168.0.108[4500] (76 bytes)
Feb 18 22:14:40 honza-U36JC charon: 16[ENC] parsed IKE_AUTH request 5 [ EAP/RES/TLS ]
Feb 18 22:14:40 honza-U36JC charon: 16[ENC] generating IKE_AUTH response 5 [ EAP/REQ/TLS ]
Feb 18 22:14:40 honza-U36JC charon: 16[NET] sending packet: from 192.168.0.108[4500] to 192.168.0.103[54718] (412 bytes)
Feb 18 22:14:40 honza-U36JC charon: 09[NET] received packet: from 192.168.0.103[54718] to 192.168.0.108[4500] (92 bytes)
Feb 18 22:14:40 honza-U36JC charon: 09[ENC] parsed IKE_AUTH request 6 [ EAP/RES/TLS ]
Feb 18 22:14:40 honza-U36JC charon: 09[TLS] received fatal TLS alert 'bad certificate'
Feb 18 22:14:40 honza-U36JC charon: 09[IKE] EAP method EAP_TLS failed for peer C=CH, O=strongSwan, CN=client
Feb 18 22:14:40 honza-U36JC charon: 09[ENC] generating IKE_AUTH response 6 [ EAP/FAIL ]
Feb 18 22:14:40 honza-U36JC charon: 09[NET] sending packet: from 192.168.0.108[4500] to 192.168.0.103[54718] (76 bytes)@

Android log

Feb 18 22:23:53 00[DMN] Starting IKE charon daemon (strongSwan 5.2.1dr1, Linux 3.0.31-889555, armv7l)
Feb 18 22:23:53 00[KNL] kernel-netlink plugin might require CAP_NET_ADMIN capability
Feb 18 22:23:53 00[LIB] loaded plugins: androidbridge charon android-log openssl fips-prf random nonce pubkey pkcs1 pkcs8 pem xcbc hmac socket-default kernel-netlink eap-identity eap-mschapv2 eap-md5 eap-gtc eap-tls
Feb 18 22:23:53 00[LIB] unable to load 9 plugin features (9 due to unmet dependencies)
Feb 18 22:23:53 00[JOB] spawning 16 worker threads
Feb 18 22:23:53 02[CFG] loaded user certificate 'C=CH, O=strongSwan, CN=client' and private key
Feb 18 22:23:53 02[CFG] loaded CA certificate 'C=CH, O=strongSwan, CN=192.168.0.108'
Feb 18 22:23:53 02[IKE] initiating IKE_SA android[15] to 192.168.0.108
Feb 18 22:23:54 02[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
Feb 18 22:23:54 02[NET] sending packet: from 192.168.0.103[43278] to 192.168.0.108[500] (996 bytes)
Feb 18 22:23:54 12[NET] received packet: from 192.168.0.108[500] to 192.168.0.103[43278] (440 bytes)
Feb 18 22:23:54 12[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(MULT_AUTH) ]
Feb 18 22:23:54 12[IKE] faking NAT situation to enforce UDP encapsulation
Feb 18 22:23:54 12[IKE] sending cert request for "C=CH, O=strongSwan, CN=192.168.0.108" 
Feb 18 22:23:54 12[IKE] establishing CHILD_SA android
Feb 18 22:23:54 12[ENC] generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) CERTREQ CPRQ(ADDR ADDR6 DNS DNS6) N(ESP_TFC_PAD_N) SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) N(EAP_ONLY) ]
Feb 18 22:23:54 12[NET] sending packet: from 192.168.0.103[34279] to 192.168.0.108[4500] (572 bytes)
Feb 18 22:23:54 13[NET] received packet: from 192.168.0.108[4500] to 192.168.0.103[34279] (1196 bytes)
Feb 18 22:23:54 13[ENC] parsed IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ]
Feb 18 22:23:54 13[IKE] received end entity cert "C=CH, O=strongSwan, CN=192.168.0.108" 
Feb 18 22:23:54 13[CFG]   using certificate "C=CH, O=strongSwan, CN=192.168.0.108" 
Feb 18 22:23:54 13[CFG]   using trusted ca certificate "C=CH, O=strongSwan, CN=192.168.0.108" 
Feb 18 22:23:54 13[CFG]   reached self-signed root ca with a path length of 0
Feb 18 22:23:54 13[IKE] authentication of '192.168.0.108' with RSA signature successful
Feb 18 22:23:54 13[IKE] server requested EAP_IDENTITY (id 0x00), sending 'C=CH, O=strongSwan, CN=client'
Feb 18 22:23:54 13[ENC] generating IKE_AUTH request 2 [ EAP/RES/ID ]
Feb 18 22:23:54 13[NET] sending packet: from 192.168.0.103[34279] to 192.168.0.108[4500] (124 bytes)
Feb 18 22:23:54 08[NET] received packet: from 192.168.0.108[4500] to 192.168.0.103[34279] (76 bytes)
Feb 18 22:23:54 08[ENC] parsed IKE_AUTH response 2 [ EAP/REQ/TLS ]
Feb 18 22:23:54 08[IKE] server requested EAP_TLS authentication (id 0x7B)
Feb 18 22:23:54 08[ENC] generating IKE_AUTH request 3 [ EAP/RES/TLS ]
Feb 18 22:23:54 08[NET] sending packet: from 192.168.0.103[34279] to 192.168.0.108[4500] (252 bytes)
Feb 18 22:23:54 06[NET] received packet: from 192.168.0.108[4500] to 192.168.0.103[34279] (588 bytes)
Feb 18 22:23:54 06[ENC] parsed IKE_AUTH response 3 [ EAP/REQ/TLS ]
Feb 18 22:23:54 06[ENC] generating IKE_AUTH request 4 [ EAP/RES/TLS ]
Feb 18 22:23:54 06[NET] sending packet: from 192.168.0.103[34279] to 192.168.0.108[4500] (76 bytes)
Feb 18 22:23:54 03[NET] received packet: from 192.168.0.108[4500] to 192.168.0.103[34279] (588 bytes)
Feb 18 22:23:54 03[ENC] parsed IKE_AUTH response 4 [ EAP/REQ/TLS ]
Feb 18 22:23:54 03[ENC] generating IKE_AUTH request 5 [ EAP/RES/TLS ]
Feb 18 22:23:54 03[NET] sending packet: from 192.168.0.103[34279] to 192.168.0.108[4500] (76 bytes)
Feb 18 22:23:54 01[NET] received packet: from 192.168.0.108[4500] to 192.168.0.103[34279] (412 bytes)
Feb 18 22:23:54 01[ENC] parsed IKE_AUTH response 5 [ EAP/REQ/TLS ]
Feb 18 22:23:54 01[TLS] negotiated TLS 1.2 using suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
Feb 18 22:23:54 01[TLS] received TLS server certificate 'C=CH, O=strongSwan, CN=192.168.0.108'
Feb 18 22:23:54 01[CFG]   using trusted certificate "C=CH, O=strongSwan, CN=192.168.0.108" 
Feb 18 22:23:54 01[TLS] verifying DH parameters failed
Feb 18 22:23:54 01[TLS] sending fatal TLS alert 'bad certificate'
Feb 18 22:23:54 01[ENC] generating IKE_AUTH request 6 [ EAP/RES/TLS ]
Feb 18 22:23:54 01[NET] sending packet: from 192.168.0.103[34279] to 192.168.0.108[4500] (92 bytes)
Feb 18 22:23:54 10[NET] received packet: from 192.168.0.108[4500] to 192.168.0.103[34279] (76 bytes)
Feb 18 22:23:54 10[ENC] parsed IKE_AUTH response 6 [ EAP/FAIL ]
Feb 18 22:23:54 10[IKE] received EAP_FAILURE, EAP authentication failed
Feb 18 22:23:54 10[ENC] generating INFORMATIONAL request 7 [ N(AUTH_FAILED) ]
Feb 18 22:23:54 10[NET] sending packet: from 192.168.0.103[34279] to 192.168.0.108[4500] (76 bytes)

ipsec.conf

 config setup
        #strictcrlpolicy=yes
         #uniqueids = never

 conn %default
        keyexchange=ikev2
        dpdaction=clear
        ike=aes256-sha1-modp1024!
        esp=aes256-sha1!
        dpddelay=300s
        rekey=no

 conn winCert
         leftcert=serverCert.pem
         leftauth=pubkey
         leftsubnet=10.1.0.0/24
         right=%any
         leftid=192.168.0.108
         rightauth=eap-tls
         eap_identity=%identity
         rightsendcert=never
         rightsourceip=10.20.0.0/244
         keyexchange=ikev2
         auto=add

I don't no what is the cause "bad certificate".

In log:

 Feb 18 22:23:54 01[TLS] received TLS server certificate 'C=CH, O=strongSwan, CN=192.168.0.108'
 Feb 18 22:23:54 01[CFG]   using trusted certificate "C=CH, O=strongSwan, CN=192.168.0.108" 
 Feb 18 22:23:54 01[TLS] verifying DH parameters failed
 Feb 18 22:23:54 01[TLS] sending fatal TLS alert 'bad certificate'

But DH paramets is the same for both.

And another thing, when I add user/pass auth to this ipsec.conf, then only method which is first in ipsec.conf works. Client try connect via conn eaptls but when it failed he does not continue to another conn.

Thanks for your help

 conn userPass
        left=%defaultroute
        leftsubnet=10.1.0.0/24
        leftauth=pubkey
        leftid=192.168.0.108
        leftcert=serverCert.pem
        rightsourceip=10.20.0.0/24
        right=%any
        rightauth=eap-mschapv2
        rightsendcert=never
        eap_identity=%any
        auto=add

#4 Updated by Tobias Brunner over 7 years ago

I don't no what is the cause "bad certificate".

In log:

...
Feb 18 22:23:54 01[TLS] verifying DH parameters failed
...

This message is logged if the signature verification failed during TLS. It's hard to tell why this fails, could be a bug. Would you mind sending me the certificates and keys you used here so I could try to reproduce and debug it?

And another thing, when I add user/pass auth to this ipsec.conf, then only method which is first in ipsec.conf works. Client try connect via conn eaptls but when it failed he does not continue to another conn.

The two connections only differ in the selected EAP method. So they are both eligible and the first one in ipsec.conf will be used. If the client then doesn't like the EAP method it will return an EAP-Nak. But that will not trigger a complete configuration change on the server. To support multiple EAP methods you have to use the eap-dynamic plugin and set rightauth=eap-dynamic. This plugin will initiate one EAP method (the order can be set in strongswan.conf, otherwise the first registered method will be used) and if the client does not like it and returns an EAP-Nak it will switch to a method supported by the client.

#5 Updated by Jan Bonczek over 7 years ago

Yes of course a can send my certificate.

ipsec.conf is same as above.

ipsec.secrets only this:

: RSA serverKey.pem
 : EAP "123456" 
 And in the strongswan.conf:
charon {
    load_modular = yes
    dns1 = 8.8.8.8
    dns2 = 8.8.4.4
    plugins {
 eap-tls {
      fragment_size = 512
    }
        include strongswan.d/charon/*.conf
    }
 }

Today I trying repair my error and started with created new certificate. I changed only CA cert. In previous CA was CN=192.168.0.108. In new CA cert I used CN=strongSwan root CA" instead. I am not aware another change, but to my surprise now it's works with Android OS.

I put certificated as file here.

And thanks for rightauth=eap-dynamic. I will try it.

#6 Updated by Tobias Brunner over 7 years ago

Today I trying repair my error and started with created new certificate. I changed only CA cert. In previous CA was CN=192.168.0.108. In new CA cert I used CN=strongSwan root CA" instead.

I see. Because you used the same subject DN for the CA certificate and the server certificate the TLS implementation apparently used the CA certificate's public key instead of the server certificate's to verify the signature, which naturally failed.

The lookup here (source:src/libtls/tls_peer.c#L319) uses the subject DN of the server certificate to find a public key and verify the trust chain. The enumerator there will yield every trusted public key with the associated identity, unfortunately, we stop at the first one, which could be the CA certificate if both use the same subject DN. For IKE, on the other hand, we do the signature verification in a loop (source:src/libcharon/sa/ikev2/authenticators/pubkey_authenticator.c#L194) and try all the keys we find.

I guess we could do something similar for TLS too. Alternatively, we could get the public key from the certificate and from that the KEY_ID, which we then use in the lookup to make sure we find the right key (I've implemented something to that effect in the tls-pubkey-selection branch of our repository).

#7 Updated by Jan Bonczek over 7 years ago

Thank you for clarification where was the problem when CA had same CN like gateway cert.

Can I ask why Android client connect to vpn gateway if eap_identity=%any isn't use but WP client can't. For example if is use user/pass auth with MSCHAPv2

no EAP key found for hosts '%any' - '%any'
 EAP-MS-CHAPv2 verification failed, retry (1)

#8 Updated by Tobias Brunner over 7 years ago

Can I ask why Android client connect to vpn gateway if eap_identity=%any isn't use but WP client can't. For example if is use user/pass auth with MSCHAPv2

If no EAP-Identity exchange is done the IKE identity will be used also during EAP to identify the client. The Android app uses the same identity for IKE and EAP (user name or subject DN of the client's certificate), but Windows does not (it usually uses the client's IP address as IKE identity). So without the EAP-Identity exchange the server is not able to verify the certificate against the client's identity (error here: #849-1) or find the client's password.

#9 Updated by Tobias Brunner over 7 years ago

  • Tracker changed from Issue to Bug
  • Subject changed from Strongswan and Windows Phone 8.1 with certificate auth to Failure during TLS authentication if CA and end-entity certificate share the same subject DN
  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Target version set to 5.3.0
  • Resolution set to Fixed

I pushed a fix for the TLS certificate issue (CA certificate and server certificate with the same subject DN) to our master branch.

Also available in: Atom PDF