Certificate based Site to Site VPN (IKEv2)

Showing results for 
Show  only  | Search instead for 
Did you mean: 

Certificate based Site to Site VPN (IKEv2)

L1 Bithead

Hello Folks, I am trying to build a site to site vpn between a Palo Alto firewall running 8.1.7 and a Checkpoint firewall. Settings are configured to use IKEv2 only with certificate based authentication.


While the logs below are from lab setup, but the actual client problem are the same. PA and Checkpoint firewall certificates are signed by the same CA, so that the Root CA and present on both firewall to build the chain.


When i am trying to establish the VPN tunnel with Checkpoint being the Initiator, I see below logs on the monitor tab.

'IKEv2 certificate authentication failed. Invalid SIG.'

IKEv2 IKE SA negotiation is failed as responder.


Running a debug on ike and viewing the ikemgr log, I see below errors on PA firewal.

2019-05-08 13:56:34.969 +0530 [DEBG]: building cert chain:
2019-05-08 13:56:34.969 +0530 [DEBG]: /CN=cplab.winlocal.com ->
2019-05-08 13:56:34.969 +0530 [DEBG]: /DC=local/DC=lab/CN=lab-WIN-LAB-AD-CA [root]
2019-05-08 13:56:34.969 +0530 debug: pan_ike_cert_check_chain(pan_mp_cert.c:2125): verify result: 1 [0:/CN=cplab.winlocal.com]
2019-05-08 13:56:34.970 +0530 [PERR]: RSA_verify failed: 140737127241472:error:04091064:rsa routines:INT_RSA_VERIFY:algorithm mismatch:rsa_sign.c:269:
2019-05-08 13:56:34.970 +0530 [PERR]: Invalid SIG.


When I make PA firewall as initiator, the VPN works without any issues. Tried looking around knowledge base, didn't find anything. Have anyone come across similar scenarios?


Accepted Solutions

I got a similar message (RSA_verify failed: 140539036088064:error:04097068:rsa routines:RSA_private_encrypt:bad signature:fips_rsa_sign.c:423:

2022-09-26 12:46:03.112 +0000 [PERR]: Invalid SIG.) after we upgraded from PANOS 9.1.12 to 9.1.13.  We get this error when trying to establish connections between Palo Alto and Cisco devices.  IKEv1 works and using IKEv2 with pre-shared keys works. We even tried updating to PANOS  9.1.14 and 10.1.7.  Using IKEv1 is not a solution due to STIG requirements.  If anyone else has run into this and has a solution I'd like to know.

View solution in original post


L1 Bithead



We've a VPN that was correctly running with certificate until we upgraded to 8.1.10; after this upgrade we have this problem too.

L1 Bithead

We have the exact same issue after upgrading to 8.1.10.

Is there already a solution or a known bug id or anything?

Just wanted to add to this discussion in the hopes that it may help others. Recently upgraded my central PA cluster from 8.1.6 to 8.1.10.  We have about a dozen remote sites with PA devices still on 8.1.6 (planned to phase their PANOS upgrades in throughout the year).  They connect back to the central PA cluster.  They all use Site to Site IPSec VPNs, with IKEv2 protocol,  certificated based authentication, with certificates using RSA SHA256 as the hashing algorithm w/ cert key as RSA 2048 (I make note of both here because I get them mixed up in my head) .  This setup has been working as far back as 7.1.x days. 


A few days go after upgrading our central PA cluster from 8.1.6 to 8.1.10, all of the site to site tunnels to my remote devices went down.  Contacted PAN TAC and was told that using IKEv2, and certificated based VPN authentication with certificates using RSA SHA256 was no longer a "supported behavior" in 8.1.10. Their suggestion was to 1. roll back OS on central PA cluster, 2. change to IKEv2 with pre-shared keys, 3. change to IKEv1 using our current cert auth config, or 4. re-generate and re-import all our VPN certificates using RSA SHA128.  I didn't like any of those options, but I decided to try switching to IKEv1 as it seemed like the easiest change.  This solved all our issues, and the VPN tunnels came back. The downside was I had to go onsite to several of the remote locations to make the change, since they were cut off. As a side note, I've now switched those remote locations to "IKEv2 preferred" setting under IKE Gateway.  That will allow them to try to fall-back to IKEv1 if the peer is not supporting IKEv2 (assuming IKEv1 is configured and profiles are matching on both central and remote sides).  I believe having this enabled before would have saved me from making trips to the remote locations to manually switch them to IKEv1.  I still would have had to change the central PA cluster to IKEv1, but that is always reachable via OoB Mgmt.


The last communication I got back from PAN TAC was that their previous statement was incorrect, and certificates using RSA SHA256 should be supported in 8.1.10.  They asked me to test upgrading one of the remote PAs from 8.1.6 to 8.1.10 to match the central PA cluster.  I did, and then set my IKE gateways on each device back to using IKEv2.  To my surprise everything worked again using IKEv2 with both PAs running 8.1.10. I've never had an issue with our PA remotes running a few versions behind our central PA cluster. 


In summary, its my opinion that something must have changed with 8.1.10 in regard to IKE and cert based VPN auth. What ever changed seems to now require both sides to be running 8.1.10 (if you have a PA to PA site to site VPN), when using IKEv2, with cert based Auth on certs using RSA SHA256 (I can only speak to certs using RSA SHA256, SHA1 may not be affected).

Appreciate the feedback and tests made. Let me replicate the behavior again in my lab environment with 8.1.10 and a Checkpoint firewall which was our original problem and write back the results here.

Hope this would fix our problem too.

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!