IPSec VPN accepts any peer certificate when specific certificate given

[tanr]

Hi All,

Setting up IPSec VPN (IKEv2) between two 5.4.1 FortiGates.  Works fine with PSK (after working around GUI bug that saves wrong IP if you use named addresses for the VPN).

When I changed over to using certificates I found the tunnels went up just fine, but the peer certificate wasn't getting verified as I would have expected.  Meaning, I could (and did) list a non-existent peer certificate name of GARBAGE_T with or without cn and subject set, and the tunnel would still go up with no complaints.  Not exactly secure.

Both devices have their peer certificates signed by my local CA root vpn ca certificate.

Both devices have imported the root vpn ca cert.

Both devices have the private version of their own cert (signed by the root vpn ca cert).

Both devices have the public version of the other devices cert (signed by the root vpn ca cert).

The phase1 settings on both sides specify that they authenticate with a signature and list their own certificate by name.

The phase1 settings on both sides specify IKEv2 and that they accept only a peer certificate, with the peer certificate name referring (I believe) not to the certificate, but to the name of the peer that refers to the cert (config user peer).  As mentioned above, I can change the user peer here to be a dummy peer referring to a non-existent certificate and the tunnel still goes up.  Scary.

Any ideas on what's going on here?  I'm really hoping this is some simple mistake on my part.

[tanr]

Just ran through the same tests with 5.4.4.  Same results.

I still see that, with IPSec authentication, using IKEv2, when authenticating by certificate the CN and subject specified *that the peer should match to be valid* are ignored completely.  Thus I can't require the peer to have a specific certificate, CN, or subject, even though the dialog implies these will be required.

Note that the authentication does fail if the CA certificate referenced in the Peer Options, Peer Certificate, PKI object (which holds the CN and subject that are supposed to be verified) is different than the CA that signed the cert provided by the peer.  My current workaround to use multiple CA certs which have each signed a non-CA cert to be used for the auth sort of works around this, albeit in a painfully convoluted way.

Now that I'm on a current version of FortiOS I can create a ticket to report this as a bug.

Unless someone else has already reported this?  Please let me know if you've already reported this (and can give us a bug number) so we don't duplicate tickets.

[bommi]

I created an ticket but didnt got an response yet.

But it can't be bad if you do the same ;)

[tanr]

Let's give it a couple days.  Please let us know what you hear in response to your ticket.  If you don't get anywhere with it I can create a new ticket.

[tanr]

@bommi,

Did you get any response to your ticket?  

If not I'll open another ticket, as I've got a simple case to reproduce the problem but will be re-configuring the IPSec VPN rsn.

[tanr]

Okay, I've created a support ticket regarding this.

BTW, I did some further testing by setting the PKI (user peer) mandatory-ca-verify disable. With this set and the subject and cn set to garbage, or to any other certs, the IPSec VPN still authenticates the connection if the PKI's ca is correct -- not good. To repeat this: It is verifying *ONLY* off the ca, ignoring the subject, ignoring the cn, and ignoring the fact that mandatory-ca-verify field is set to disable.

[tanr]

While waiting for support to research this I did some quick tests with

    set subject "CN = MY_CERT_CN" Setting it to a CN for a remote cert (public key) that exists on the FGT but is not the correct cert still connected with no errors. I flushed the vpn (diag vpn ike gateway flush) but still got the same results. I also tried it with the user peer cn set to nothing or set to the incorrect cert's CN (one that wasn't signed by the ca listed). Still connected with no errors. AFAIK the vpn auth should have failed in both cases.

Maybe I'm not flushing/resetting the vpn correctly, so my tests aren't valid?  

I've been running "diag vpn ike gateway flush".  

Should I instead be running the full vpn reset as below?

    diag vpn tunnel flush     diag vpn tunnel reset

[oheigl]

Have you checked it with the latest version 5.4.5? Is this issue still present there? Thanks!