Bug #849
Failure during TLS authentication if CA and end-entity certificate share the same subject DN
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
- ipsec.conf - strongSwan IPsec configuration file
- 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
Associated revisions
History
#1 Updated by Jan Bonczek almost 6 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 almost 6 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 almost 6 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 almost 6 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 almost 6 years ago
- File notWorking.tar.gz notWorking.tar.gz added
- File working.tar.gz working.tar.gz added
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 almost 6 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 almost 6 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 almost 6 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 almost 6 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.
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.