Certificate requests need to be adhered to so whatever one GW requests, needs to be fulfilled by the other gateway. If not the auth will be failed.
Cert Requests are created by which Trusted Root certs are installed and what is configured on the vendors gateway.
In Check Point Cert Requests can be configured (to send to your Peer) to be specific and is done in the interoperable device > IPSec VPN Matching Criteria.
e.g. if you want the peer to send a cert verified from a certain Verisign root cert. That Root cert needs to be installed on your CP and it's subordinates. Then configure matching criteria to the Verisign subordinate root cert.
If this is left blank the GW's cert request packet will hold all your Trusted Root certificates.
The peer will try to match one and send the cert. If there is no match, the rfc states it needs to send one. If it has a default cert (in CP that is the CP Internal cert) and it will send that.
*If the peer has your GW Root Cert install as trusted the cert will be verified.
*quick note. Each gateway can request a different cert on one VPN connection i.e. you can request Verisign they can request CP internal cert. As long as both have the correct root cert to verify the cert. And the correct cert installed to send.
If the peer can be configured to modify its requests, it will need to be a cert installed in your GW VPN config. They will need to also trust it to verify. Other Vendors can install a cert without having to have the root cert installed first - make sure they confirm they have your root cert installed.
If a peer cannot change their requests, then you need to install the root cert into your GW and create a VPN cert in the GW VPN config. Sonicwalls are notorious for this and if the administrator is not sure on how to find out the cert request, you will have to debug the vpn on the CP.
CRL/OCSP URL needs to be accessible from a CP GW otherwise the cert will not be valid. You can turn it off in root/sub cert. OCSP is the default now for CP, if that fails it should revert to https, but for R81.x this revert feature has only been fixed in recent JHF's. If you have an internal OSCSP server you need to make sure DNS routes rules and NATs capture and allow the traffic. You would see the issue in the vpnd.elg - something to do with cannot reach OCSP to verify etc.
So if the peer sends a cert request that does not match a cert installed on your GW VPN config it should send your default cert. But I have seen the GW send other certs. Looking in GuiDBedit I was trying to find the cert it would send - e.g. if it was the order in the database or if there was a priority number. I have not found this yet so it is still mystery on which cert it does choose. All but one VPN I have seen it send the CP internal.
I did harass TAC for approx 6 months about this but we never got to the resolution.
Viewing your vpn debugs with ikeview you will see the cert request packets and the certs sent packets for each GW. That will give you a good picture of what is happening if you compare requests to sent.
In your case your peers request has not been satisfied and they have failed the auth.
Could be certs expired either end (installed VPN certs or Trusted etc will no longer be requested or sent) or they have changed their cert requests.
