Hi Tobias, So its an issue with the cipher in the certificate vs. the cipher used to decrypt?
Do I configure the ciphers in strongswan.conf or ipsec.conf (via ike, esp)? I wonder if switching to eap-mschapv2 would be more easy... (would like to get it running before I'm behind the great red firewall next week) I use following certificats and the corresponding config: Looking at the certificates in windows: *** CA certificate: *** Signature algorithm: sha1RSA Signature hash algorithm: sha1 Issuer: CN = pointcode ca, O = pointcode, C = CN Subject: CN = pointcode ca, O = pointcode, C = CN Public key: RSA (2048 bytes) Basic Constraints: Subject Type=CA, Path Length Constraint=None Key Usage: Certificate Signing, Off-line CRL Signing, CRL Signing (06) Thumbprint algorithm: sha1 Subject Key Identifier: 83 a4 70 f7 88 fd 53 70 ac 4b 32 35 23 af 33 e7 03 3a c7 ed Both "Basic Constraints" and "Key Usage" have a yellow exclamation mark. Not sure, if this is relevant... *** Server certificate: *** Signature algorithm: sha1RSA Signature hash algorithm: sha1 Issuer: CN = pointcode ca, O = pointcode, C = CN Subject: CN = vpn.pointcode.de, O = pointcode, C = CN Public key: RSA (2048 bytes) Basic Constraints: Subject Type=CA, Path Length Constraint=None Key Usage: Certificate Signing, Off-line CRL Signing, CRL Signing (06) Thumbprint algorithm: sha1 Authority Key Identifier: KeyID=83 a4 70 f7 88 fd 53 70 ac 4b 32 35 23 af 33 e7 03 3a c7 ed Subject Alternative Name: DNS Name=vpn.pointcode.de Enhanced Key Usage: Server Authentication (1.3.6.1.5.5.7.3.1) The Authority Key Identifier is the Subject KeyID of the CA cert *** Client certificate (inside .p12): *** Signature algorithm: sha1RSA Signature hash algorithm: sha1 Issuer: CN = pointcode ca, O = pointcode, C = CN Subject: CN = [email protected], O = pointcode, C = CN Public key: RSA (2048 bytes) Basic Constraints: Subject Type=CA, Path Length Constraint=None Key Usage: Certificate Signing, Off-line CRL Signing, CRL Signing (06) Thumbprint algorithm: sha1 Authority Key Identifier: KeyID=83 a4 70 f7 88 fd 53 70 ac 4b 32 35 23 af 33 e7 03 3a c7 ed Subject Alternative Name: RFC822 [email protected] Enhanced Key Usage: Client Authentication (1.3.6.1.5.5.7.3.2) The Authority Key Identifier is the Subject KeyID of the CA cert *** strongswan.conf *** plugins { eap-tls { fragment_size = 512 } } libtls { suites = TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 } ** ipsec.conf *** conn %default keyexchange=ikev2 dpdaction=clear #ike=aes256-sha1-modp1024! #esp=aes256-sha1! ike=aes128-sha1-modp1024,aes128-sha1-modp2048,aes256-sha1-modp1024,aes128-sha256-ecp256,aes256-sha384-ecp384 esp=aes128-sha1,aes256-sha1,aes128gcm128-ecp256,aes256gcm128-ecp384 thanks, Arne ---------------------------------------- > To: [email protected]; [email protected] > From: [email protected] > Date: Tue, 3 May 2016 17:52:10 +0200 > Subject: Re: [strongSwan] Win7 and Window10Mobile: IKE authentication > credentials are unacceptable > > 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 _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
