cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1256
Views
3
Helpful
25
Replies

FTD IKE/IPSec VPN site to site certificate authentication error

soufiansaheb
Level 1
Level 1

hello all ,

recently i tried to configure VPN site to site with certificate authentication type, i got the certificate signed by a third party autority , and when i did the debugs i got this log :

CRYPTO_PKI: bitValue of KEY_USAGE = a0PKI[7]: CRYPTO_PKI:check_key_usage: Checking KU for case VPN peer certs.

PKI[7]: CRYPTO_PKI:check_key_usage: KU bit digitalSignature is ON.

PKI[7]: ExtendedKeyUsage OID = serverAuth NOT acceptable for usage type IPSEC VPN Peer

PKI[4]: check_key_usage: No acceptable ExtendedKeyUsage OIDs found

PKI[7]: check_key_usage: IGNORING IPSec Key Usage check failure

PKI[12]: pki_ossl_do_callback, pki_ossl_validate.c:164

PKI[9]: Async unlocked for session 0x9a679795

PKI[12]: CERT_VerifyData, vpn3k_cert_api.c:603

PKI[9]: CERT API thread sleeps!

i saw some documentation that recommend to apply the ignore-ipsec-keyusage  , even the support suggest to apply this command on the trustpoint and that what i did :

sh run cry ca trustpoint VPN

crypto ca trustpoint VPN

keypair VPN_BA_AGB

ignore-ipsec-keyusage <---

crl configure

 

i also checked the option : ignore ipsec key usage on the enroulement in key tab ,

and this is an other recommendation of support :

The recommendation is to get the right EKU/OID on the certificate in order for the firewall to be able to use it for IPSec VPN certificate authentication

but the CA authority confirm to me that they do that with other vendors and it works fine and they can not change th EKU cause this is not allowed ,

is there any way to force FTD to escape the EKU check ?

 

25 Replies 25

you use FMC to mgmt FTD?\

under FMC cert. you can select ignore the keyusage

Screenshot (200).png

MHM

thanks for the replay ,

i alredy did select the ignore the key usage :

soufiansaheb_0-1710848806476.png

 

and even i used Flexconfig to ignore the ipsec keyusage as follow :

crypto ca trustpoint VPN
keypair VPN_BA_AGB
ignore-ipsec-keyusage
crl configure

i hope there is another way to ignore this check 

> show crypto ca trustpoints

can you check if command we config via flexconfig is successfully add to FTD  

thanks for the replay :

sho run crypto ca trustpoint VPN
crypto ca trustpoint VPN
keypair VPN_BA_AGB
ignore-ipsec-keyusage
crl configure

sho crypto ca trustpoints VPN

Trustpoint VPN:
Subject Name:
cn=xxxxxxxxxxxxxx
o=xxxxxxxxxxxxxxxxxxxxxxxxx
c=XX
Serial Number: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Certificate configured.

 

This is the only and absolutely correct way to ignore EKU check on received certificates. And from the debug it is evident that the command "ignore-ipsec-keyusage" works as expected (below in bold):

PKI[7]: CRYPTO_PKI:check_key_usage: KU bit digitalSignature is ON.
PKI[7]: ExtendedKeyUsage OID = serverAuth NOT acceptable for usage type IPSEC VPN Peer
PKI[4]: check_key_usage: No acceptable ExtendedKeyUsage OIDs found
PKI[7]: check_key_usage: IGNORING IPSec Key Usage check failure

Alternatively you can use CA which can generate certs with proper KU and EKU set. So far as I remember, the KU should contain bit Digital Signature and EKU should contain id-kp-ipsecEndSystem (1.3.6.1.5.5.7.3.5) or id-kp-ipsecTunnel (1.3.6.1.5.5.7.3.6) or id-kp-clientAuth (1.3.6.1.5.5.7.3.2) or id-kp-ipsecUser (1.3.6.1.5.5.7.3.7). The serverAuth EKU is good when ASA/FTD responds to client end systems. For L2L VPN this EKU indeed looks a bit strange, that is why it is not accepted by default for L2L.

If your tunnel is not established, it is due to something else and not due to wrong EKU.

HTH

 

Indeed it can cert. Is accept 

IKEv2-PROTO-4: (2793): Verification of peer's authenctication data PASSED

Check the acl of vpn in both side' the acl dont match any crypto map seq

MHM

what i don't understand is when i change to pre shared key the VPN works fine 

this is the the out put of debug crypto ca 14 :

CRYPTO_PKI: bitValue of KEY_USAGE = a0PKI[7]: CRYPTO_PKI:check_key_usage: Checking KU for case VPN peer certs.
PKI[7]: CRYPTO_PKI:check_key_usage: KU bit digitalSignature is ON.
PKI[7]: ExtendedKeyUsage OID = serverAuth NOT acceptable for usage type IPSEC VPN Peer
PKI[4]: check_key_usage: No acceptable ExtendedKeyUsage OIDs found
PKI[7]: check_key_usage: IGNORING IPSec Key Usage check failure
PKI[12]: pki_ossl_do_callback, pki_ossl_validate.c:164
PKI[9]: Async unlocked for session 0x3e3190cd
PKI[12]: CERT_VerifyData, vpn3k_cert_api.c:603
PKI[9]: CERT API thread sleeps!
PKI[13]: CERT_GetPeerCertValidityEndTime, vpn3k_cert_api.c:3489
PKI[12]: asn1_to_unix_time, crypto_pki.c:1720
PKI[14]: CERT_GetPrintableX500DN, vpn3k_cert_api.c:3267
PKI[13]: CERT_SignData, vpn3k_cert_api.c:361
PKI[14]: map_status, vpn3k_cert_api.c:2512
PKI[14]: CERT_GetPrintableX500DN, vpn3k_cert_api.c:3267
PKI[14]: CERT_GetPrintableX500DN, vpn3k_cert_api.c:3267
PKI[13]: CERT_Close, vpn3k_cert_api.c:291
PKI[8]: Close session 0x47861677 synchronously
PKI[13]: pki_ossl_free_valctx, pki_ossl_validate.c:251
PKI[14]: CERT_GetPrintableX500DN, vpn3k_cert_api.c:3267
PKI[14]: CERT_GetPrintableX500DN, vpn3k_cert_api.c:3267
PKI[14]: CERT_GetPrintableX500DN, vpn3k_cert_api.c:3267
PKI[14]: CERT_GetPrintableX500DN, vpn3k_cert_api.c:3267

 

and this for debug crypto ikev2 protocol 255 in attachement 

 

 

Peer doesn't respond to CREATE_CHILD_SA request. You need to collect logs/debugs from both sides at once, otherwise it's difficult to say something, because debugs depend on initiator/responder roles.

 

thanks for the replay , @tvotna 

unfortunatley i don't have control on the peer side , i'll ask them to give me some logs if it is possible 

(1986):  TSi(1986):   Next payload: TSr, reserved: 0x0, length: 24
(1986):     Num of TSs: 1, reserved 0x0, reserved 0x0
(1986):     TS type: TS_IPV4_ADDR_RANGE, proto id: 0, length: 16
(1986):     start port: 0, end port: 65535
(1986):     start addr: 10.199.199.89, end addr: 10.199.199.89
(1986):  TSr(1986):   Next payload: NONE, reserved: 0x0, length: 24
(1986):     Num of TSs: 1, reserved 0x0, reserved 0x0
(1986):     TS type: TS_IPV4_ADDR_RANGE, proto id: 0, length: 16
(1986):     start port: 0, end port: 65535
(1986):     start addr: remote LAN IP, end addr: remote LAN IP

this is VPN proxy selector IP, for which crypto map Seq this ACL belong ?

MHM 

soufiansaheb