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.

[emnoc]

What's you peer type set as "any" or this peer

show full vpn ipsec phase1-interface | grep peer

You can run  the following for better diagnostic and reset the tunnel from the far end

diag debug dis

diag debug reset

diag debug enable

diag debug vpn ike log filter name yourphase1-interface-byname

diag vpn ike gateway flush

oops stick a  to turn on ike debug

diagnose debug app ike -1

[tanr]

Hi emnoc,

The show full gives peertype as peer for the phase1-interface, which the online help says means "accepts this peer certificate."

The cleanest version of the logs I was able to generate are below.  From my (poor) understanding of the logs, it certainly looks like it is authenticating the (non-existent) GARBAGE_T cert referenced in my test peer.  I cut off the logs once it started building phase2.

PROMPT # di de app ike -1

PROMPT # di vpn ike log filter name p1-sp-to-ho

PROMPT # di de enable

PROMPT # di vpn ike gateway flush

ike 0:p1-sp-to-ho: deleting

ike 0:p1-sp-to-ho: flushing

ike 0:p1-sp-to-ho: deleting IPsec SA with SPI eafXX353

ike 0:p1-sp-to-ho:p2-sec-to-ho-cams: deleted IPsec SA with SPI eafXX553, SA count: 0

ike 0:p1-sp-to-ho: sending SNMP tunnel DOWN trap for p2-sec-to-ho-cams

ike 0:p1-sp-to-ho:p2-sec-to-ho-cams: sending SNMP tunnel DOWN trap

ike 0:p1-sp-to-ho: flushed

ike 0:p1-sp-to-ho:285:132: send informational

ike 0:p1-sp-to-ho:285: enc 000XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX0107

ike 0:p1-sp-to-ho:285: out 11BBEF79XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

ike 0:p1-sp-to-ho:285: sent IKE msg (INFORMATIONAL): SP.SP.IP.IP:500->HO.HO.IP.IP:500, len=80, id=11bbXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX58:00000002

ike 0:p1-sp-to-ho: deleted

ike 0:p1-sp-to-ho: set oper down

ike 0:p1-sp-to-ho: schedule auto-negotiate

ike 0:p1-sp-to-ho: carrier down

PROMPT # ike 0: comes HO.HO.IP.IP:500->SP.SP.IP.IP:500,ifindex=5....

ike 0: IKEv2 exchange=INFORMATIONAL_RESPONSE id=11bbefbbbbbafb7/5418922bbbbb458:00000002 len=80

ike 0: in 11BBEF79XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

ike 0:p1-sp-to-ho: auto-negotiate connection

ike 0:p1-sp-to-ho: created connection: 0x50877e0 5 SP.SP.IP.IP->HO.HO.IP.IP:500.

ike 0:p1-sp-to-ho:p2-sec-to-ho-cams: chosen to populate IKE_SA traffic-selectors

ike 0:p1-sp-to-ho: no suitable IKE_SA, queuing CHILD_SA request and initiating IKE_SA negotiation

ike 0:p1-sp-to-ho:286: out F9F295BXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

ike 0:p1-sp-to-ho:286: sent IKE msg (SA_INIT): SP.SP.IP.IP:500->HO.HO.IP.IP:500, len=416, id=f9XXXXXXXXXXX8c/0000000000000000

ike 0: comes HO.HO.IP.IP:500->SP.SP.IP.IP:500,ifindex=5....

ike 0: IKEv2 exchange=SA_INIT_RESPONSE id=f9f295be2d3dd98c/8a0b87d1ab66f5f0 len=441

ike 0: in F9F295BE2XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

ike 0:p1-sp-to-ho:286: initiator received SA_INIT response

ike 0:p1-sp-to-ho:286: received notify type NAT_DETECTION_SOURCE_IP

ike 0:p1-sp-to-ho:286: processing NAT-D payload

ike 0:p1-sp-to-ho:286: NAT not detected

ike 0:p1-sp-to-ho:286: process NAT-D

ike 0:p1-sp-to-ho:286: received notify type NAT_DETECTION_DESTINATION_IP

ike 0:p1-sp-to-ho:286: processing NAT-D payload

ike 0:p1-sp-to-ho:286: NAT not detected

ike 0:p1-sp-to-ho:286: process NAT-D

ike 0:p1-sp-to-ho:286: incoming proposal:

ike 0:p1-sp-to-ho:286: proposal id = 1:

ike 0:p1-sp-to-ho:286:   protocol = IKEv2:

ike 0:p1-sp-to-ho:286:      encapsulation = IKEv2/none

ike 0:p1-sp-to-ho:286:         type=ENCR, val=AES_CBC (key_len = 256)

ike 0:p1-sp-to-ho:286:         type=INTEGR, val=AUTH_HMAC_SHA2_256_128

ike 0:p1-sp-to-ho:286:         type=PRF, val=PRF_HMAC_SHA2_256

ike 0:p1-sp-to-ho:286:         type=DH_GROUP, val=MODP2048.

ike 0:p1-sp-to-ho:286: matched proposal id 1

ike 0:p1-sp-to-ho:286: proposal id = 1:

ike 0:p1-sp-to-ho:286:   protocol = IKEv2:

ike 0:p1-sp-to-ho:286:      encapsulation = IKEv2/none

ike 0:p1-sp-to-ho:286:         type=ENCR, val=AES_CBC (key_len = 256)

ike 0:p1-sp-to-ho:286:         type=INTEGR, val=AUTH_HMAC_SHA2_256_128

ike 0:p1-sp-to-ho:286:         type=PRF, vaVVVVVVl=PRF_HMAC_SHA2_256

ike 0:p1-sp-to-ho:286:         type=DH_GROUP, val=MODP2048.

ike 0:p1-sp-to-ho:286: lifetime=86400

ike 0:p1-sp-to-ho:286: IKE SA f9VVVVVV3dd98c/8a0b87VVVVVVf5f0 SK_ei 32:F58D9VVVVVVVVVVVVVVVVVVVVVVVVVV

ike 0:p1-sp-to-ho:286: IKE SA f9VVVVVV2d3dd98c/8a0b87d1aVVVVVV SK_er 32:4091VVVVVVVVVVVVVVVVVVVVVVVVVV

ike 0:p1-sp-to-ho:286: IKE SA f9VVVVVV2d3dd98c/8a0b87d1aVVVVVV SK_ai 32:28725VVVVVVVVVVVVVVVVVVVVVVVVV

ike 0:p1-sp-to-ho:286: IKE SA f9VVVVVV2d3dd98c/8a0b87d1aVVVVVV SK_ar 32:5CCC2VVVVVVVVVVVVVVVVVVVVVVVVV

ike 0:p1-sp-to-ho:286: initiator preparing AUTH msg

ike 0:p1-sp-to-ho:286: local cert, subject='WXXXX_VPN1_SP', issuer='WXXXX_VPN_RT1'

ike 0:p1-sp-to-ho:286: local CA cert, subject='WXXXX_VPN_RT1', issuer='WXXXX_VPN_RT1'

ike 0:p1-sp-to-ho:286: sending INITIAL-CONTACT

ike 0:p1-sp-to-ho:286: sending CERTREQ payload

ike 0:p1-sp-to-ho:286: enc 2500008D09000000308182310B30090603550406130255533XXXXXXXXXXXXXXXXXXXxxxxxxxxxxxxxxxxxxxxxx

ike 0:p1-sp-to-ho:286: out F9F295BE2D3DD98C8A0B87D1AB66F5F02E202308000000010XXXXXXXXXXXXXXXXXXXxxxxxxxxxxxxxxxxxxxxx

ike 0:p1-sp-to-ho:286: sent IKE msg (AUTH): SP.SP.IP.IP:500->HO.HO.IP.IP:500, len=2992, id=f9f295bbbbbbd98c/8a0b87d1bbbbbbf0:00000001

ike 0: comes HO.HO.IP.IP:500->SP.SP.IP.IP:500,ifindex=5....

ike 0: IKEv2 exchange=AUTH_RESPONSE id=f9f295be2d3dd98c/8a0b87d1ab66f5f0:00000001 len=2960

ike 0: in F9F295BE2D3DD98C8A0B87D1AB66F5F02E2023200000000100000B9024000B7488XXXXXXXXXXXXXXXXXXXxxxxx

ike 0:p1-sp-to-ho:286: dec F9F295BE2D3DD98C8A0B87D1AB66F5F02E20232000000001EXXXXXXXXXXXXXXXXXXXxxxxxxxxxxxxxxxxxxxxx

ike 0:p1-sp-to-ho:286: initiator received AUTH msg

ike 0:p1-sp-to-ho:286: received peer identifier DER_ASN1_DN 'C = US, ST = State, L = City, O = Company, CN = WXXXX_VPN2_HO, emailAddress = xXxXx@xXxXx.com'

ike 0:p1-sp-to-ho:286: Validating X.509 certificate

ike 0:p1-sp-to-ho:286: peer cert, subject='WXXXX_VPN2_HO', issuer='WXXXX_VPN_RT1'

ike 0:p1-sp-to-ho:286: peer CA cert, subject='WXXXX_VPN_RT1', issuer='WXXXX_VPN_RT1'

ike 0:p1-sp-to-ho:286: peer ID verified

ike 0:p1-sp-to-ho:286: building fnbam peer candidate list

ike 0:p1-sp-to-ho:286: FNBAM_GROUP_NAME candidate 'GARBAGE_T'

ike 0:p1-sp-to-ho:286: certificate validation pending

ike 0:p1-sp-to-ho:286: certificate validation complete

ike 0:p1-sp-to-ho:286: certificate validation succeeded

ike 0:p1-sp-to-ho:286: signature verification succeeded

ike 0:p1-sp-to-ho:286: auth verify done

ike 0:p1-sp-to-ho:286: initiator AUTH continuation

ike 0:p1-sp-to-ho:286: authentication succeeded

ike 0:p1-sp-to-ho:286: received notify type MESSAGE_ID_SYNC_SUPPORTED

ike 0:p1-sp-to-ho:286: processing child notify type MESSAGE_ID_SYNC_SUPPORTED

ike 0:p1-sp-to-ho:286: established IKE SA f9f29bbbbbb98c/8a0bbbbbbbf0

ike 0:p1-sp-to-ho: set oper up

ike 0:p1-sp-to-ho: schedule auto-negotiate

ike 0:p1-sp-to-ho:286:p2-sec-to-ho-cams:133: incoming child SA proposal:

ike 0:p1-sp-to-ho:286:p2-sec-to-ho-cams:133: proposal id = 1:

ike 0:p1-sp-to-ho:286:p2-sec-to-ho-cams:133:   protocol = ESP:

ike 0:p1-sp-to-ho:286:p2-sec-to-ho-cams:133:      encapsulation = TUNNEL

ike 0:p1-sp-to-ho:286:p2-sec-to-ho-cams:133:         type=ENCR, val=AES_CBC (key_len = 128)

ike 0:p1-sp-to-ho:286:p2-sec-to-ho-cams:133:         type=INTEGR, val=SHA256

ike 0:p1-sp-to-ho:286:p2-sec-to-ho-cams:133:         type=ESN, val=NO

ike 0:p1-sp-to-ho:286:p2-sec-to-ho-cams:133:         PFS is disabled

ike 0:p1-sp-to-ho:286:p2-sec-to-ho-cams:133: matched proposal id 1

ike 0:p1-sp-to-ho:286:p2-sec-to-ho-cams:133: proposal id = 1:

ike 0:p1-sp-to-ho:286:p2-sec-to-ho-cams:133:   protocol = ESP:

...

Any thoughts on what is going on?

[tanr]

Did some more testing of this, and what I found was disturbing.

Specifying a PKI peer, to authenticate only a specific certificate, appears to be badly broken in 5.4.1 IPSec VPN, at least if you specify a ca certificate in the peer.

If I specify a ca cert in the peer, the IPSec phase1 will accept ANYTHING signed by that ca cert.  It doesn't check the peer's cn, it doesn't check the subject, it doesn't even check the cn-type.  I hope it won't accept a signed but revoked cert, but who knows.

I read that this used to be an issue with FortiOS 4.x SSL VPN, but the forum comments implied that IPSec VPN verified the subject/cn correctly.  No longer, I guess.

Anybody aware of this, or have a workaround?  Has it already been reported as a bug to Fortinet?

Right now, the only workaround I see is to generate a unique CA cert for each site, have that CA sign a dummy cert for the site which the site will authenticate with, and give the other sites the public ca cert to verify against the dummy cert.  Hopefully that will work with intermediate CA certs.  Yuck.

[emnoc]

Why would you use a "ca cert". You should have the ca issue a  peer1/peer2 certificate imho , and then you  check just that certificate. Since the ca.cert should be the signer and sits at the top of the chain, anything should pass against the CA and any sub-certificates.

Just run openssl and verify the 2 certificates,  and I bet they probably will pass. I believe this is what the  fortiOs is doing btw. Simple and plain check.

reference my blogspot openssl tip

http://socpuppet.blogspot...certfiicate-thats.html

[tanr]

In 5.4.1 it doesn't let you create or edit a peer (config user peer) without setting ca to some ca certificate.  I've tried from the CLI and from the GUI.  Maybe there is some way to do it that I'm missing, but all attempts give me:

PeerNameX must have certificate CA

object check operator error, -56, discard the setting

Command fail. Return code -56

Per http://help.fortinet.com/fos50hlp/52data/Content/FortiOS/fortigate-ipsecvpn-52/Phase_1/Authenticatin... I would expect to be able to create one without specifying a CA, but it doesn't allow it.

Then, with that CA specified in the peer, the IPSec Phase1 just accepts anything signed by that CA, ignoring the values for cn, cn-type, and subject.

That's why I was considering just generating multiple ca certs -- to use them in place of the much easier peer1/peer2 solution you suggest.  The peer1/peer2 certs were what I had in place with my previous firewalls.  But with the peer requiring a ca cert and IPSec VPN accepting any cert signed by that ca (without verifying it against the cn or subject) I don't see many other options.

[tanr]

Just re-read my post and realised I didn't state that succinctly.

I'm fine with the FGT verifying the chain for whatever certificate the other peer provides, and am fine with it requiring that the ca certificate in the chain match the one specified in the peer.

My concern is that it is ignoring the CN and subject specified in the peer and not requiring that the certificate the other peer provides match that CN and subject.  Thus I can't require the peer to have a specific certificate.

[bommi]

Hi,

any news on this?

I have the same problem with an customer right now.

Regards

bommi

[tanr]

I'm just about finished upgrading our second site to 5.4.4.  I hope to test this again once both sites are at 5.4.4.

I haven't seen anything in the release notes to imply that this has been changed, but there have been a number of IPSec fixes so you never know.

[bommi]

At least with 5.4.3 there is no change in this behavior.