Hi Arne, > Did a lot of searching to no avail. > I'm on OpenSSL 1.0.1e 11 Feb 2013 if that helps.
That's not really relevant as strongSwan has its own TLS stack (only libcrypto is used from OpenSSL, e.g. ECDH here). > May 2 15:11:50 09[TLS] <winCert|1> processing TLS Handshake record (64 bytes) > May 2 15:11:50 09[TLS] <winCert|1> TLS record MAC verification failed This indicates the message couldn't be verified correctly. Since the TLS message is sent in an authenticated IKEv2 messages we can be sure it didn't get corrupted on the network. So it was either already sent corrupted or the two peers don't use the same keys or algorithms. In the other email you sent the error now is: > May 3 14:01:20 05[TLS] processing TLS Handshake record (64 bytes) > May 3 14:01:20 05[TLS] TLS record too short to verify MAC This is strange as the cipher suite is the same in both cases (TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) and the record is the same length too. The only reason it could be too short when verifying the integrity is if the decryption produced a result that caused the removal of too much data as padding. Which again would indicate the two peers don't use the same keys/algorithms. It's difficult to tell what exactly the problem is without detailed debugging. You could try to use different cipher suites (see [1] for the configuration options). It might also be an issue with Windows 10 Mobile because with Windows 7 (TLS 1.0, x86) and with Windows 10 EDU (TLS 1.2, x64) I don't have any problems using EAP-TLS with this exact same cipher suite. Regards, Tobias [1] https://wiki.strongswan.org/projects/strongswan/wiki/Eaptls _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
