05-08-2019 01:35 AM
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?
09-26-2022 06:29 AM
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.
09-03-2019 01:57 AM
Hello,
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.
09-13-2019 12:44 AM
We have the exact same issue after upgrading to 8.1.10.
Is there already a solution or a known bug id or anything?
11-19-2019 10:57 AM
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).
11-19-2019 07:50 PM
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.
12-06-2019 10:14 AM
What a pain in the neck this upgrade is going to be. I tried going from 8.1.6 to 9.0.5 on one firewall while the other remains at 8.1.6 and my SHA256 IPsec tunnel would not reconnect. I had to switch to PSK. Now that I know what the problem is, I'll be switching back to SHA256 certificate after upgrading all of my firewall routers. It shouldn't matter what version these firewalls are. Obviously a bug introduced after 8.1.6 that impacted SHA256 certficate-based VPNs.
08-06-2020 06:50 AM
Please upgrade to 10.0.1 if possible I have encountered an issue with certificates and IKE that should be resolved in that version
08-06-2020 07:21 AM
Jmora, thanks for the reply. TBH I forgot about this thread. I should have followed up. When 8.1.13 became generally recommended, we upgraded our remote PA220s to that version, leaving our central PA5220s on 8.1.10 as we couldn't get an upgrade window for them at that time. Upgrading just the PA220s to 8.1.13 fixed the issue. Although I have no official TAC confirmation or bug ID, based on my experience it appears the issues was fixed sometime between 8.1.10 and 8.1.13. I'd assume it will not be a concern for anyone using 8.1.13 and newer.
Thanks
01-25-2021 01:51 AM - edited 01-25-2021 04:43 AM
I've tested Site to Site VPN IKEv2 Certificate based authentication between Strongswan and Palo Alto.
I managed to get it work with Palo Alto version 8.1.0,8.1.17,8.1.18 and 9.1.7
However it failed on Palo Alto version 8.1.10,8.1.11,8.1.12,8.1.13,8.1.14,8.1.15,8.1.16
The error message is
RSA_verify failed: 140737128797952:error:04091064:rsa routines:INT_RSA_VERIFY:algorithm mismatch:rsa_sign.c:269:
Success logs
Strongswan log
Status of IKE charon daemon (strongSwan 5.6.2, Linux 5.4.0-1035-aws, x86_64):
uptime: 101 seconds, since Jan 25 08:22:43 2021
malloc: sbrk 1740800, mmap 0, used 724336, free 1016464
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 3
loaded plugins: charon aesni aes rc2 sha2 sha1 md4 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netlink resolve socket-default connmark stroke updown eap-mschapv2 xauth-generic counters
Listening IP addresses:
172.31.31.254
172.17.0.1
Connections:
palo-alto: %any...18.138.107.2 IKEv2, dpddelay=300s
palo-alto: local: [CN=fw.myfave.com] uses public key authentication
palo-alto: cert: "CN=fw.myfave.com"
palo-alto: remote: [CN=CN=Palo-Alto] uses public key authentication
palo-alto: cert: "CN=CN=Palo-Alto"
palo-alto: child: 10.168.12.0/26 === 10.10.10.0/24 TUNNEL, dpdaction=clear
Routed Connections:
palo-alto{1}: ROUTED, TUNNEL, reqid 1
palo-alto{1}: 10.168.12.0/26 === 10.10.10.0/24
Security Associations (1 up, 0 connecting):
palo-alto[1]: ESTABLISHED 94 seconds ago, 172.31.31.254[CN=fw.myfave.com]...18.138.107.2[CN=CN=Palo-Alto]
palo-alto[1]: IKEv2 SPIs: be95a854c9de3f3a_i* ab0a765721ab6d73_r, public key reauthentication in 42 minutes
palo-alto[1]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_384
palo-alto{2}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: cd46364e_i f6b29a1f_o
palo-alto{2}: AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 13 minutes
palo-alto{2}: 10.168.12.0/26 === 10.10.10.0/24
Palo Alto logs
2021-01-25 00:22:51.260 -0800 [PNTF]: { 1: }: ====> IKEv2 IKE SA NEGOTIATION STARTED AS RESPONDER, non-rekey; gateway fave <====
====> Initiated SA: 192.168.21.44[500]-3.0.180.248[500] SPI:be95a854c9de3f3a:ab0a765721ab6d73 SN:3 <====
2021-01-25 00:22:51.260 -0800 [PWRN]: { 1: }: 192.168.21.44[500] - 3.0.180.248[500]:0x8e2bd0 ignoring unauthenticated notify payload (NAT_DETECTION_SOURCE_IP)
2021-01-25 00:22:51.260 -0800 [PWRN]: { 1: }: 192.168.21.44[500] - 3.0.180.248[500]:0x8e2bd0 ignoring unauthenticated notify payload (NAT_DETECTION_DESTINATION_IP)
2021-01-25 00:22:51.260 -0800 [PWRN]: { 1: }: 192.168.21.44[500] - 3.0.180.248[500]:0x8e2bd0 ignoring unauthenticated notify payload (16430)
2021-01-25 00:22:51.260 -0800 [PWRN]: { 1: }: 192.168.21.44[500] - 3.0.180.248[500]:0x8e2bd0 ignoring unauthenticated notify payload (16431)
2021-01-25 00:22:51.260 -0800 [PWRN]: { 1: }: 192.168.21.44[500] - 3.0.180.248[500]:0x8e2bd0 ignoring unauthenticated notify payload (16406)
2021-01-25 00:22:51.261 -0800 [INFO]: { 1: }: build IKEv2 CR payload[0]: 'CN=Root_CA_VPN'
2021-01-25 00:22:51.261 -0800 [INFO]: { 1: }: build IKEv2 CR payload[1]: 'CN=Sectigo RSA Domain Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB'
2021-01-25 00:22:51.283 -0800 [INFO]: { 1: }: cert received: subject=CN=fw.myfave.com, issuer=CN=Sectigo RSA Domain Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB[ee
?]
2021-01-25 00:22:51.283 -0800 [INFO]: { 1: }: CR hash (2) ignored, no match found.
2021-01-25 00:22:51.283 -0800 [INFO]: { 1: }: 192.168.21.44[500] - 3.0.180.248[500]:0x7fffe0000da0 authentication result: success
2021-01-25 00:22:51.283 -0800 [PWRN]: { 1: }: 16384 is not a child notify type
2021-01-25 00:22:51.283 -0800 [INFO]: { 1: }: received Notify payload protocol 0 type INITIAL_CONTACT
2021-01-25 00:22:51.283 -0800 [PWRN]: { 1: }: 16417 is not a child notify type
2021-01-25 00:22:51.283 -0800 [INFO]: { 1: }: received Notify payload protocol 0 type EAP_ONLY_AUTHENTICATION
2021-01-25 00:22:51.283 -0800 [PWRN]: { 1: }: 16420 is not a child notify type
2021-01-25 00:22:51.283 -0800 [INFO]: { 1: }: received Notify payload protocol 0 type 16420
2021-01-25 00:22:51.283 -0800 [PNTF]: { 1: }: ====> IKEv2 CHILD SA NEGOTIATION STARTED AS RESPONDER, non-rekey; gateway fave <====
====> Initiated SA: 192.168.21.44[500]-3.0.180.248[500] message id:0x00000001 parent SN:3 <====
2021-01-25 00:22:51.283 -0800 [WARN]: { 1: 1}: selector fave src is ambiguous, using the first one of the expanded addresses
2021-01-25 00:22:51.283 -0800 [WARN]: { 1: 1}: selector fave dst is ambiguous, using the first one of the expanded addresses
2021-01-25 00:22:51.283 -0800 [INFO]: { 1: 1}: SADB_UPDATE proto=255 3.0.180.248[500]=>192.168.21.44[500] ESP tunl spi 0xF6B29A1F auth=SHA256 enc=AES256/32 lifetime soft 2971/0 hard 3600/0
2021-01-25 00:22:51.283 -0800 [INFO]: { 1: 1}: SADB_ADD proto=255 192.168.21.44[500]=>3.0.180.248[500] ESP tunl spi 0xCD46364E auth=SHA256 enc=AES256/32 lifetime soft 2990/0 hard 3600/0
2021-01-25 00:22:51.283 -0800 [PNTF]: { 1: 1}: ====> IPSEC KEY INSTALLATION SUCCEEDED; tunnel fave <====
====> Installed SA: 192.168.21.44[500]-3.0.180.248[500] SPI:0xF6B29A1F/0xCD46364E lifetime 3600 Sec lifesize unlimited <====
2021-01-25 00:22:51.283 -0800 [PNTF]: { 1: 1}: ====> IKEv2 CHILD SA NEGOTIATION SUCCEEDED AS RESPONDER, non-rekey; tunnel fave <====
====> Established SA: 192.168.21.44[500]-3.0.180.248[500] message id:0x00000001, SPI:0xF6B29A1F/0xCD46364E parent SN:3 <====
2021-01-25 00:22:51.283 -0800 [PNTF]: { 1: }: ====> IKEv2 IKE SA NEGOTIATION SUCCEEDED AS RESPONDER, non-rekey; gateway fave <====
====> Established SA: 192.168.21.44[500]-3.0.180.248[500] SPI:be95a854c9de3f3a:ab0a765721ab6d73 SN:3 lifetime 28800 Sec <====
Failed logs
Strongswan log
initiating IKE_SA palo-alto[1] to 18.138.107.2
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
sending packet: from 172.31.31.254[500] to 18.138.107.2[500] (1894 bytes)
retransmit 1 of request with message ID 0
sending packet: from 172.31.31.254[500] to 18.138.107.2[500] (1894 bytes)
received packet: from 18.138.107.2[500] to 172.31.31.254[500] (269 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No CERTREQ N(HTTP_CERT_LOOK) ]
received cert request for "C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo RSA Domain Validation Secure Server CA"
received 1 cert requests for an unknown ca
sending cert request for "C=CH, O=strongswan, CN=Root CA"
sending cert request for "C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo RSA Domain Validation Secure Server CA"
authentication of 'CN=fw.myfave.com' (myself) with RSA signature successful
sending end entity cert "CN=fw.myfave.com"
establishing CHILD_SA palo-alto{2}
generating IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr AUTH N(IPCOMP_SUP) SA TSi TSr N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
sending packet: from 172.31.31.254[500] to 18.138.107.2[500] (2368 bytes)
received packet: from 18.138.107.2[500] to 172.31.31.254[500] (1280 bytes)
parsed IKE_AUTH response 1 [ IDr CERT N(INIT_CONTACT) AUTH N(ESP_TFC_PAD_N) SA TSi TSr ]
received end entity cert "CN=CN=Palo-Alto"
no issuer certificate found for "CN=CN=Palo-Alto"
issuer is "CN=Root_CA_VPN"
using trusted certificate "CN=CN=Palo-Alto"
signature validation failed, looking for another key
generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
sending packet: from 172.31.31.254[500] to 18.138.107.2[500] (80 bytes)
establishing connection 'palo-alto' failed
Palo Alto logs
2021-01-25 00:52:01.760 -0800 [PNTF]: { 1: }: ====> IKEv2 IKE SA NEGOTIATION STARTED AS RESPONDER, non-rekey; gateway fave <====
====> Initiated SA: 192.168.21.44[500]-3.0.180.248[500] SPI:196afe660f063f23:0c939463ff93c6e9 SN:1 <====
2021-01-25 00:52:01.760 -0800 [PWRN]: { 1: }: 192.168.21.44[500] - 3.0.180.248[500]:0x8e3520 ignoring unauthenticated notify payload (NAT_DETECTION_SOURCE_IP)
2021-01-25 00:52:01.760 -0800 [PWRN]: { 1: }: 192.168.21.44[500] - 3.0.180.248[500]:0x8e3520 ignoring unauthenticated notify payload (NAT_DETECTION_DESTINATION_IP)
2021-01-25 00:52:01.760 -0800 [PWRN]: { 1: }: 192.168.21.44[500] - 3.0.180.248[500]:0x8e3520 ignoring unauthenticated notify payload (16430)
2021-01-25 00:52:01.760 -0800 [PWRN]: { 1: }: 192.168.21.44[500] - 3.0.180.248[500]:0x8e3520 ignoring unauthenticated notify payload (16431)
2021-01-25 00:52:01.760 -0800 [PWRN]: { 1: }: 192.168.21.44[500] - 3.0.180.248[500]:0x8e3520 ignoring unauthenticated notify payload (16406)
2021-01-25 00:52:01.761 -0800 [INFO]: { 1: }: build IKEv2 CR payload[0]: 'CN=Root_CA_VPN'
2021-01-25 00:52:01.761 -0800 [INFO]: { 1: }: build IKEv2 CR payload[1]: 'CN=Sectigo RSA Domain Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB'
2021-01-25 00:52:01.777 -0800 [INFO]: { 1: }: cert received: subject=CN=fw.myfave.com, issuer=CN=Sectigo RSA Domain Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB[ee
?]
2021-01-25 00:52:01.777 -0800 [INFO]: { 1: }: CR hash (2) ignored, no match found.
2021-01-25 00:52:01.777 -0800 [PERR]: RSA_verify failed: 140737128797952:error:04091064:rsa routines:INT_RSA_VERIFY:algorithm mismatch:rsa_sign.c:269:
2021-01-25 00:52:01.777 -0800 [WARN]: { 1: }: 192.168.21.44[500] - 3.0.180.248[500]:(nil) RSA_verify switch hash_alg SHA256 to SHA1
2021-01-25 00:52:01.778 -0800 [INFO]: { 1: }: 192.168.21.44[500] - 3.0.180.248[500]:0x7fffd800b6f0 authentication result: success
2021-01-25 00:52:01.778 -0800 [PWRN]: { 1: }: 16384 is not a child notify type
2021-01-25 00:52:01.778 -0800 [INFO]: { 1: }: received Notify payload protocol 0 type INITIAL_CONTACT
2021-01-25 00:52:01.778 -0800 [PWRN]: { 1: }: 16417 is not a child notify type
2021-01-25 00:52:01.778 -0800 [INFO]: { 1: }: received Notify payload protocol 0 type EAP_ONLY_AUTHENTICATION
2021-01-25 00:52:01.778 -0800 [PWRN]: { 1: }: 16420 is not a child notify type
2021-01-25 00:52:01.778 -0800 [INFO]: { 1: }: received Notify payload protocol 0 type 16420
2021-01-25 00:52:01.778 -0800 [PNTF]: { 1: }: ====> IKEv2 CHILD SA NEGOTIATION STARTED AS RESPONDER, non-rekey; gateway fave <====
====> Initiated SA: 192.168.21.44[500]-3.0.180.248[500] message id:0x00000001 parent SN:1 <====
2021-01-25 00:52:01.778 -0800 [WARN]: { 1: 1}: selector fave src is ambiguous, using the first one of the expanded addresses
2021-01-25 00:52:01.778 -0800 [WARN]: { 1: 1}: selector fave dst is ambiguous, using the first one of the expanded addresses
2021-01-25 00:52:01.778 -0800 [INFO]: { 1: 1}: SADB_UPDATE proto=255 3.0.180.248[500]=>192.168.21.44[500] ESP tunl spi 0xEBA22C90 auth=SHA256 enc=AES256/32 lifetime soft 3075/0 hard 3600/0
2021-01-25 00:52:01.778 -0800 [INFO]: { 1: 1}: SADB_ADD proto=255 192.168.21.44[500]=>3.0.180.248[500] ESP tunl spi 0xC688599B auth=SHA256 enc=AES256/32 lifetime soft 2888/0 hard 3600/0
2021-01-25 00:52:01.778 -0800 [PNTF]: { 1: 1}: ====> IPSEC KEY INSTALLATION SUCCEEDED; tunnel fave <====
====> Installed SA: 192.168.21.44[500]-3.0.180.248[500] SPI:0xEBA22C90/0xC688599B lifetime 3600 Sec lifesize unlimited <====
2021-01-25 00:52:01.778 -0800 [PNTF]: { 1: 1}: ====> IKEv2 CHILD SA NEGOTIATION SUCCEEDED AS RESPONDER, non-rekey; tunnel fave <====
====> Established SA: 192.168.21.44[500]-3.0.180.248[500] message id:0x00000001, SPI:0xEBA22C90/0xC688599B parent SN:1 <====
2021-01-25 00:52:01.778 -0800 [PNTF]: { 1: }: ====> IKEv2 IKE SA NEGOTIATION SUCCEEDED AS RESPONDER, non-rekey; gateway fave <====
====> Established SA: 192.168.21.44[500]-3.0.180.248[500] SPI:196afe660f063f23:0c939463ff93c6e9 SN:1 lifetime 28800 Sec <====
2021-01-25 00:52:01.783 -0800 [PERR]: { 1: }: received Notify payload protocol 0 type AUTHENTICATION_FAILED
2021-01-25 00:52:01.783 -0800 [INFO]: { 1: }: 192.168.21.44[500] - 3.0.180.248[500]:(nil) closing IKEv2 SA fave:1, code 18
2021-01-25 00:52:01.783 -0800 [PNTF]: { 1: }: ====> IKEv2 IKE SA NEGOTIATION FAILED AS RESPONDER, non-rekey; gateway fave <====
====> Failed SA: 192.168.21.44[500]-3.0.180.248[500] SPI:196afe660f063f23:0c939463ff93c6e9 SN 1 <====
2021-01-25 00:52:01.783 -0800 [PNTF]: { 1: 1}: ====> IPSEC KEY DELETED; tunnel fave <====
====> Deleted SA: 192.168.21.44[500]-3.0.180.248[500] SPI:0xEBA22C90/0xC688599B <====
2021-01-25 00:52:01.783 -0800 [INFO]: { 1: 1}: SADB_DELETE proto=255 src=3.0.180.248[0] dst=192.168.21.44[0] ESP spi=0xEBA22C90
09-26-2022 06:29 AM
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.
11-22-2022 08:32 PM
Hello All, How can you make PA as initiator as the only setting we have is to make responder i.e "enable Passive mode"
12-05-2022 10:26 PM
Hello All, I am also facing the same issue after upgrading the firewall to 10.1.6-h6. Please share solution/suggestion if anyone has
06-11-2023 07:05 PM
Hello,
Using the ECDSA algorithm with IKE2, instead of the RSA, will solve this issue. ECDSA seems be just as "secure" and the PA firewall can generate ECDSA MUCH faster than an RSA. ECDSA actually has some advantage over RSA, anyway.
We experienced the exact error, even in PANOS 10.1.10 (still!): "RSA_verify failed: 1099179176208:error:04091064:rsa routines:INT_RSA_VERIFY:algorithm mismatch:rsa_sign.c:269:"...despite trying various RSA certificates, even those generated outside the PA Firewall, in likes Mikrotik certificate generator or likes of OpenSSL. There were no PA KB's or any workaround that we could find...based on the data at hand, this most definitely looks like a bug in IMO.
ECDSA worked like a charm!
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!
