156-315.80 · Question #507
What is required for a certificate-based VPN tunnel between two gateways with separate management systems?
The correct answer is A. Mutually Trusted Certificate Authorities. https://community.checkpoint.com/t5/Security-Gateways/HowTo-Set-Up-Certificate-Based-VPNs- with-Check-Point-Appliances/td-p/73299
Question
What is required for a certificate-based VPN tunnel between two gateways with separate management systems?
Options
- AMutually Trusted Certificate Authorities
- BShared User Certificates
- CShared Secret Passwords
- DUnique Passwords
How the community answered
(24 responses)- A83% (20)
- B4% (1)
- C4% (1)
- D8% (2)
Explanation
https://community.checkpoint.com/t5/Security-Gateways/HowTo-Set-Up-Certificate-Based-VPNs- with-Check-Point-Appliances/td-p/73299
Topics
Community Discussion
6
Imani T.Feb 13, 2026Answer is A, Mutually Trusted Certificate Authorities, and this one makes sense once you think about what certificates are actually doing in a VPN handshake. Each gateway presents a certificate signed by its own CA, and the remote gateway has to be able to verify that signature, which means it needs to trust the CA that issued it. When both gateways live under the same Check Point management domain they already share that trust automatically through the Internal CA, but with separate management systems you have to explicitly exchange and trust each other's CA certificates. The other options are distractors pointing at pre-shared key concepts or user-level auth, neither of which applies to certificate-based gateway-to-gateway tunnels.
Bao N.Feb 10, 2026A is right, though "mutually trusted CAs" is what trips people up versus shared secrets on D.
Brenda K.Feb 16, 2026Saw this one on my actual exam and almost flagged it, but the wording "separate management systems" is your give-away, it screams cross-domain trust and the only thing that bridges two independent PKI environments is Mutually Trusted Certificate Authorities (A), so mark it and move on, this is a 20-second question. I had a study partner who second-guessed himself into D thinking passwords were simpler to set up, wasted three minutes on it, and still got it wrong, do not be that person.
Grace U.Mar 2, 2026Each gateway has to trust the other's CA, that's the whole handshake. I remember staring at that one for a solid thirty seconds, ruled out the password options right away since we're talking certs, then realized shared user certs still don't solve the trust problem between two separate management domains, so A clicked and I moved on. Glad I trusted my gut there.
Brenda K.Mar 4, 2026Solid read on A, though clock it for maybe fifteen seconds next time because the distractor about shared user certs is thin and you can bank that saved time on the BGP or OSPF redistribution questions later in the section.
Anastasia B.Mar 13, 2026When two gateways belong to separate management domains, each has its own Internal Certificate Authority and neither trusts the other out of the box, so IKE phase 1 with certificates will fail at the authentication step because the receiving gateway cannot validate the peer's certificate chain. Shared secrets and passwords are pre-shared key mechanisms entirely, they have nothing to do with a certificate-based tunnel, and you would not share a certificate that is tied to one identity with another entity. What you need is for each management server to export its CA certificate and import it as a trusted CA on the other side, so both gateways can independently verify the certificate presented by the remote peer during IKE negotiation. For anyone working through this on a lab, did you go through the process of exporting the CA from SmartConsole on one side and importing it under Trusted CAs on the other, or did you try a different approach like using a third-party CA that both domains already trust?