Hi jakrupa

raarons · ‎08-21-2015

Hi all

I am setting up a remote access VPN from Windows clients to ASA version 9.3(3) using native IKEv2 on the client, and machine authentication only. Everything seems to work fine as far as the ASA is concerned, but immedaitely after the VPN negotiates on the ASA, the Windows client drops the connection with "Error 13826: Failed to verify signature".

The ASA logs are good, and in the few seconds between the VPN going up and the Windows client dropping it, I see:

vpn# show vpn-sessiondb ra-ikev2

Session Type: Generic Remote-Access IKEv2 IPsec

Username : cn=VPN7.xxxx.yyyy.com
Index : 184
Assigned IP : 192.168.101.1 Public IP : 192.168.4.7
Protocol : IKEv2 IPsec
License : AnyConnect Premium
Encryption : IKEv2: (1)3DES IPsec: (1)AES256
Hashing : IKEv2: (1)SHA256 IPsec: (1)SHA1
Bytes Tx : 0 Bytes Rx : 0
Group Policy : GroupPolicy_MIAB-Certificate
Tunnel Group : MIAB-Certificate
Login Time : 12:44:36 GMT/BDT Fri Aug 21 2015
Duration : 0h:00m:42s
Inactivity : 0h:00m:00s
VLAN Mapping : N/A VLAN : none
Audt Sess ID : c0a80302000b800055d70f24
Security Grp : none

The debugs also look good on the ASA:

Aug 21 2015 12:44:36: %ASA-7-713906: IKE Receiver: Packet received on 192.168.4.10:500 from 192.168.4.7:500
Aug 21 2015 12:44:36: %ASA-5-750002: Local:192.168.4.10:500 Remote:192.168.4.7:500 Username:Unknown IKEv2 Received a IKE_INIT_SA request
Aug 21 2015 12:44:36: %ASA-6-302015: Built inbound UDP connection 61819 for outside:192.168.4.7/4500 (192.168.4.7/4500) to identity:192.168.4.10/4500 (192.168.4.10/4500)
Aug 21 2015 12:44:36: %ASA-7-713906: IKE Receiver: Packet received on 192.168.4.10:4500 from 192.168.4.7:4500
Aug 21 2015 12:44:36: %ASA-7-717036: Looking for a tunnel group match based on certificate maps for peer certificate with serial number: 7000000014F1CDD4A040271D08000000000014, subject name: cn=VPN7.xxx.yyy.com, issuer_name: cn=AAA,dc=xxx,dc=yyy,dc=com.
Aug 21 2015 12:44:36: %ASA-7-717038: Tunnel group match found. Tunnel Group: MIAB-Certificate, Peer certificate: serial number: 7000000014F1CDD4A040271D08000000000014, subject name: cn=VPN7.xxx.yyy.com, issuer_name: cn=AAA,dc=xxx,dc=yyy,dc=com.
Aug 21 2015 12:44:36: %ASA-7-717025: Validating certificate chain containing 1 certificate(s).
Aug 21 2015 12:44:36: %ASA-7-717029: Identified client certificate within certificate chain. serial number: 7000000014F1CDD4A040271D08000000000014, subject name: cn=VPN7.xxx.yyy.com.
Aug 21 2015 12:44:36: %ASA-7-717030: Found a suitable trustpoint yyy.com to validate certificate.
Aug 21 2015 12:44:36: %ASA-6-717022: Certificate was successfully validated. serial number: 7000000014F1CDD4A040271D08000000000014, subject name: cn=VPN7.xxx.yyy.com.
Aug 21 2015 12:44:36: %ASA-6-717028: Certificate chain was successfully validated with warning, revocation status was not checked.
Aug 21 2015 12:44:36: %ASA-7-113028: Extraction of username from VPN client certificate has been requested. [Request 35]
Aug 21 2015 12:44:36: %ASA-7-113028: Extraction of username from VPN client certificate has started. [Request 35]
Aug 21 2015 12:44:36: %ASA-7-113028: Extraction of username from VPN client certificate has finished successfully. [Request 35]
Aug 21 2015 12:44:36: %ASA-7-113028: Extraction of username from VPN client certificate has been requested. [Request 36]
Aug 21 2015 12:44:36: %ASA-7-113028: Extraction of username from VPN client certificate has completed. [Request 35]
Aug 21 2015 12:44:36: %ASA-7-113028: Extraction of username from VPN client certificate has started. [Request 36]
Aug 21 2015 12:44:36: %ASA-7-113028: Extraction of username from VPN client certificate has finished successfully. [Request 36]
Aug 21 2015 12:44:36: %ASA-7-113028: Extraction of username from VPN client certificate has completed. [Request 36]
Aug 21 2015 12:44:36: %ASA-6-113009: AAA retrieved default group policy (GroupPolicy_MIAB-Certificate) for user = cn=VPN7.xxx.yyy.com
Aug 21 2015 12:44:36: %ASA-7-734003: DAP: User cn=VPN7.xxx.yyy.com, Addr 192.168.4.7: Session Attribute aaa.cisco.grouppolicy = GroupPolicy_MIAB-Certificate
Aug 21 2015 12:44:36: %ASA-7-734003: DAP: User cn=VPN7.xxx.yyy.com, Addr 192.168.4.7: Session Attribute aaa.cisco.username = cn=VPN7.xxx.yyy.com
Aug 21 2015 12:44:36: %ASA-7-734003: DAP: User cn=VPN7.xxx.yyy.com, Addr 192.168.4.7: Session Attribute aaa.cisco.username1 = cn=VPN7.xxx.yyy.com
Aug 21 2015 12:44:36: %ASA-7-734003: DAP: User cn=VPN7.xxx.yyy.com, Addr 192.168.4.7: Session Attribute aaa.cisco.username2 =
Aug 21 2015 12:44:36: %ASA-7-734003: DAP: User cn=VPN7.xxx.yyy.com, Addr 192.168.4.7: Session Attribute aaa.cisco.tunnelgroup = MIAB-Certificate
Aug 21 2015 12:44:36: %ASA-6-734001: DAP: User cn=VPN7.xxx.yyy.com, Addr 192.168.4.7, Connection IPSec-IKEv2-Generic-RA: The following DAP records were selected for this connection: DfltAccessPolicy
Aug 21 2015 12:44:36: %ASA-7-737001: IPAA: Received message 'UTL_IP_[IKE_]ADDR_REQ'
Aug 21 2015 12:44:36: %ASA-6-737005: IPAA: DHCP configured, request succeeded for tunnel-group 'MIAB-Certificate'
Aug 21 2015 12:44:36: %ASA-7-737001: IPAA: Received message 'UTL_IP_DHCP_ADDR'
Aug 21 2015 12:44:36: %ASA-4-751014: Local:192.168.4.10:4500 Remote:192.168.4.7:4500 Username:cn=VPN7.xxx.yyy.com IKEv2 Warning Configuration Payload request for attribute 0x5ba0 could not be processed. Error: Unknown/Unsupported Attribute
Aug 21 2015 12:44:36: %ASA-4-751014: Local:192.168.4.10:4500 Remote:192.168.4.7:4500 Username:cn=VPN7.xxx.yyy.com IKEv2 Warning Configuration Payload request for attribute 0x5ba1 could not be processed. Error: Unknown/Unsupported Attribute
Aug 21 2015 12:44:36: %ASA-4-750012: Local:192.168.4.10:4500 Remote:192.168.4.7:4500 Username:cn=cn=VPN7.xxx.yyy.com IKEv2 Selected IKEv2 encryption algorithm (3DES) is not strong enough to secure proposed IPsec encryption algorithm (AES-CBC-256).
Aug 21 2015 12:44:36: %ASA-5-750006: Local:192.168.4.10:4500 Remote:192.168.4.7:4500 cn=VPN7.xxx.yyy.com IKEv2 SA UP. Reason: New Connection Established
Aug 21 2015 12:44:36: %ASA-7-746012: user-identity: Add IP-User mapping 192.168.101.1 - LOCAL\cn=VPN7.xxx.yyy.com Succeeded - VPN user
Aug 21 2015 12:44:36: %ASA-5-751025: Local:192.168.4.10:4500 Remote:192.168.4.7:4500 Username:cn=VPN7.xxx.yyy.com IKEv2 Group:GroupPolicy_MIAB-Certificate IPv4 Address=192.168.101.1 IPv6 address=:: assigned to session
Aug 21 2015 12:44:36: %ASA-6-751026: Local:192.168.4.10:4500 Remote:192.168.4.7:4500 Username:cn=VPN7.xxx.yyy.com IKEv2 Client OS: Client:
Aug 21 2015 12:44:36: %ASA-6-602303: IPSEC: An outbound remote access SA (SPI= 0x21B42283) between 192.168.4.10 and 192.168.4.7 (user= cn=VPN7.internal.miabdemo has been created.
Aug 21 2015 12:44:36: %ASA-7-609001: Built local-host outside:192.168.101.1
Aug 21 2015 12:44:36: %ASA-6-602303: IPSEC: An inbound remote access SA (SPI= 0x4AA20552) between 192.168.4.10 and 192.168.4.7 (user= cn=VPN7.internal.miabdemo. has been created.

Has anyone seen this before, and if so, does anyone know the cause? Googling for this doesn't return anything useful, but there are similar error codes listed here that point to EKU issues. The ASA certificate contains the Server Authentication EKU, but not the IPSec Intermediate EKU (I'm waiting for a new certificate with it), but the link above suggests only the Server Authentication EKU should be sufficient. The ASA certificate is issued by a trusted root on the client, and has a SAN that is the FQDN of the ASA.

Any help gratefully received.

Damian.Roche · ‎08-21-2015

I was, literally, about to post this issue in the next hour or so.

I have the same issue as well, I'm using the ASAv 941 image and using a windows 7 native VPN ikev2.

I have this set up in a lab and am using my own CA. I've tried with the same EKU as you described:

ASA = digital signature, key encipherment and Server Authentication

Client = digital signature, key enciperment and Client Authentication

I might try using the IPSec intermediate EKU tomorrow and let you know the results.

It's strange because the ASA looks like it's happy with everything, it even shows information in both "show crypto ikev2 sa" and "show crypto ipsec sa". Its just the windows side that is the issue with the error message "Error 13826: Failed to verify signature".

Furthermore, I'm hoping to move onto getting this working with Windows Phone 8.1 and it's native VPN client. I was hoping that I could get a Windows 7 machine working as a bench mark.

Any help would be much appreciated. I don't mind sharing config if anyone wants to look as it's only set up in a lab environment. Let me know if you want it.

raarons · ‎08-24-2015

Hi Damian

That might be worthwhile. My setup is itself a proof of concept, and I'm only using Windows 7 as a slightly more accessible client before I move onto mobile devices (in my case Android and Apple). I'm happy to share configs with you, but like you, the ASA seems perfectly happy with what is happening, but the Windows client seems to come to a different conclusion very late in the day, after the ASA has allowed the client full access.

Did you get anywhere with adding the EKU to the certificate? I'm still waiting for mine to arrive, but if it arrives before yours, I'll let you know if that helped at all.

regards

Rob

Damian.Roche · ‎08-25-2015

Hi Rob,

Bad news, I just tried another certificate with IPSec Intermediate EKU and I still get the error "Failed to verify Signature". I actually gave it the following to cover all bases:

Server Authentication (1.3.6.1.5.5.7.3.1)
IP security end system (1.3.6.1.5.5.7.3.5)
IP security tunnel termination (1.3.6.1.5.5.7.3.6)
IP security user (1.3.6.1.5.5.7.3.7)
IP security IKE intermediate (1.3.6.1.5.5.8.2.2)

But still no good.

The thing that is still confusing me is that the ASA shows the certificate check as being valid and sets up the VPN. It's the client end that's having the trouble.

5|Aug 25 2015|09:33:03|750002|||||Local:192.168.0.250:500 Remote:192.168.0.14:500 Username:Unknown IKEv2 Received a IKE_INIT_SA request
6|Aug 25 2015|09:32:58|602303|||||IPSEC: An inbound remote access SA (SPI= 0xFC3E6EE2) between 192.168.0.250 and 192.168.0.14 (user= L010885) has been created.
6|Aug 25 2015|09:32:58|602303|||||IPSEC: An outbound remote access SA (SPI= 0x244EEC55) between 192.168.0.250 and 192.168.0.14 (user= L010885) has been created.
6|Aug 25 2015|09:32:58|751026|||||Local:192.168.0.250:4500 Remote:192.168.0.14:4500 Username:L010885 IKEv2 Client OS: Client:
5|Aug 25 2015|09:32:58|751025|||||Local:192.168.0.250:4500 Remote:192.168.0.14:4500 Username:L010885 IKEv2 Group:DfltGrpPolicy IPv4 Address=10.1.1.1 IPv6 address=:: assigned to session
5|Aug 25 2015|09:32:58|750006|||||Local:192.168.0.250:4500 Remote:192.168.0.14:4500 Username:L010885 IKEv2 SA UP. Reason: New Connection Established
6|Aug 25 2015|09:32:58|737006|||||IPAA: Local pool request succeeded for tunnel-group 'DefaultRAGroup'
4|Aug 25 2015|09:32:58|751014|||||Local:192.168.0.250:4500 Remote:192.168.0.14:4500 Username:L010885 IKEv2 Warning Configuration Payload request for attribute 0x5ba1 could not be processed. Error: Unknown/Unsupported Attribute
4|Aug 25 2015|09:32:58|751014|||||Local:192.168.0.250:4500 Remote:192.168.0.14:4500 Username:L010885 IKEv2 Warning Configuration Payload request for attribute 0x5ba0 could not be processed. Error: Unknown/Unsupported Attribute
6|Aug 25 2015|09:32:58|737026|||||IPAA: Client assigned 10.1.1.1 from local pool
5|Aug 25 2015|09:32:58|737003|||||IPAA: DHCP configured, no viable servers found for tunnel-group 'DefaultRAGroup'
6|Aug 25 2015|09:32:58|734001|||||DAP: User L010885, Addr 192.168.0.14, Connection IPSec-IKEv2-Generic-RA: The following DAP records were selected for this connection: DfltAccessPolicy
6|Aug 25 2015|09:32:58|113009|||||AAA retrieved default group policy (DfltGrpPolicy) for user = L010885
6|Aug 25 2015|09:32:58|717028|||||Certificate chain was successfully validated with warning, revocation status was not checked.
6|Aug 25 2015|09:32:58|717022|||||Certificate was successfully validated. serial number: 08, subject name: cn=L010885.
5|Aug 25 2015|09:32:58|750002|||||Local:192.168.0.250:500 Remote:192.168.0.14:500 Username:Unknown IKEv2 Received a IKE_INIT_SA request

Anybody got any ideas?

raarons · ‎09-01-2015

Like you, I also updated my certificate on the ASA with a new one that includes the IPSec IKE Intermediate EKU, but with not improvement.

We then tried the same ASA configuration against an Android client running StrongSwan (since that is one of our target client devices) and, just like a Windows native client, the ASA is very happy with the negotiation, but the StrongSwan client isn't. It drops out after logging

Sep 1 10:45:16 strongswan-client charon: 05[CFG] using certificate "unstructuredName=vpn, CN=vpn.miabdemo.co.uk"
Sep 1 10:45:16 strongswan-client charon: 05[CFG] certificate "unstructuredName=vpn, CN=vpn.miabdemo.co.uk" key: 2048 bit RSA
Sep 1 10:45:16 strongswan-client charon: 05[CFG] using trusted ca certificate "DC=uk, DC=co, DC=miabdemo, DC=internal, CN=MIAB-PKI-CA"
Sep 1 10:45:16 strongswan-client charon: 05[CFG] certificate "DC=uk, DC=co, DC=miabdemo, DC=internal, CN=MIAB-PKI-CA" key: 2048 bit RSA
Sep 1 10:45:16 strongswan-client charon: 05[CFG] reached self-signed root ca with a path length of 0
Sep 1 10:45:16 strongswan-client charon: 05[IKE] signature validation failed, looking for another key

Any ideas, anyone?

raarons · ‎09-01-2015

and more...

If I install AnyConnect on the Windows client, and set up an AnyConnect profile that maps t to the same group policy as the IKEv2 Connection Profile does, AnyConnect is completely happy with the configuration and allows the Windows client to establish a connection.

What is the AnyConnect client doing that is different from the Windows native IKEv2 client?

Marvin Rhoads · ‎08-21-2015

I know the ASA FQDN is a SAN but is the primary name on the certificate by any chance a wildcard?

I haven't tied with IPsec IKEv2 VPN but I know that for 802.1x and ISE, the native Windows supplicant will not work with a wildcard primary name certificate.

raarons · ‎08-22-2015

No - the certificate's CN is exactly the same FQDN as the SAN

daboochmeister · ‎09-02-2015

What are the signature and signature hash algorithms used in your VPN server cert, any intermediate CA certs, and your root CA cert?

Have not been in your exact situation, but the error seems to indicate one of two things:

1) The client tried to validate the VPN server certificate's signature (or possibly the signature of one of the CA chain certs, up to and including the root cert), and got a different value than expected after hashing.

2) The signature alogrithm, or the signature hash algorithm used in one of the VPN server cert, intermediate or root certs is not supported by the client.

I have seen the latter happen when e.g. RSASSA-PSS is used for the the signature algorithm - newer versions of Microsoft-based CAs sometimes default to that signature algorithm, but support for it is a bit spotty in some places.

You can verify whether the former is happening using "openssl verify -purpose sslserver ..." command - you'll have to build a CA chain file, etc. Just search on that command, you'll find lots of examples.

raarons · ‎09-02-2015

The signature and hash used on all the certificates involved are sha1RSA and sha1 respectively.

All I get from the openssl command, even with verbose option requested is:

$ openssl verify -verbose -purpose sslserver -CAfile CA.cer ASA-Identity.cer
xxx.yyyyyyyy.co.uk.cer: OK

Is that what you would have expected? Is there more detail that can be got?

While I am not in any way a PKI guru, I would be surprised if this was the problem, since the WebVPN configuration on the same ASA uses the same certificate on its external interface, and no browser I have tried has had any problem with it, other than Chrome warning that the signature is based on a deprecated SHA-1 algorithm.

daboochmeister · ‎09-02-2015

Yeah, openssl verify is very terse, no way i've found to get more, but the "OK" means that the signatures are all fine (at least when openssl is checking them).

SHA1, while soon to be deprecated, should be fine for now, i would think. I think there's a way to disallow it now on Windows clients, but you would be getting certificate errors in IE when accessing the SSL VPN portal if that were the case.

I'm surprised you have no SChannel errors in your Windows event log (either System or Security logs, probably). Nothing at all?

raarons · ‎09-03-2015

No - nothing at all as far as I can see. The only relevant logs I can find are attached. I have enabled some additional audit event logging options under group policies, but they add nothing of any value (e.g. IPSec main mode failure, IPSec quick mode failure, etc.).

jakrupa · ‎09-06-2016

It's a compatibility issue between ASA and 3rd party clients. It occurs when PRF SHA2 (SHA256 or SHA512) is being used along with certificate authentication.

As a workaround you should configure PRF SHA1 under IKEv2 policy on the ASA.

The bug CSCvb21927 has been filed for investigation. At this moment it is not clear whether Cisco or 3rd party is not compliant with the standard.

raarons · ‎09-12-2016

Hi jakrupa

Thanks for the heads-up on this. If we are also seeing it with 9.6(2) as well, is there any known version of ASA code that does work with a native IPSec client and PRF SHA2?

next.kraftwerke · ‎01-15-2018

Hi at all,

had anyone seen something new? I'm on 9.8.1 with Strongswan Clients and Certificate Auth with SHA2 and everything is fine, when i Upgrade to 9.8.2 i have the same Issue as described in CSCvb21927

Has anyone tested 9.9.x with this Issue? Since 9.7.1 has an 200-Days-Bug we should Upgrade to an newer Version without the Bug.

@jakrupa: I had an TAC Case open with this Problerm but it was a very long journey to this Result. Maybe there is another Problem too.

Windows native IKEv2 client on ASA gets "Error 13826: Failed to verify signature"