ASA (v9.1) Site To Site VPN with IKEv2 and MS SCEP/NDES Certificates

[Jakob Roemhild]

Hello all,

I'm currently troubleshooting a issue with Site to Site VPN with IKEv2 and certifiactes as authentication method.

Here is the setup:

We have three locations with an any to any layer 2 connection. I set up each ASA (ASA5510 ver 9.1) to establish a Site to Site VPN connection to the other two locations. Setting this up with pre shared keys and certifications which are manually signed by the MS CA Administrator are working fine.

But when we try to enroll those certificates via SCEP/NDES its not working.

Here are my Steps:

1. Configure the CA Turstpoint to request the CA certificate

2. Request the CA Certificate via SCEP is working fine

3. Configure a Trustpoint and Keypair for the S2S-VPN Connection

4. Request the identity certificate form the CA via SCEP with a one time password is working fine

5. Set the created trustpoint as authentication method for the IKEv2 S2S-VPN.

Now I have done this also for the other site of the VPN-Tunnel. But when I try to ping a host wich is on the other location to bring up the VPN-Tunnel the VPN session is not established. At the debugs I can see that there are some issues during authentication of the remote peer.

At the MS CA I can see that the indentity certifactes for both ASAs are issued and not revoked or on pending state. The certificate was issued based on the "IPSec (Offline)" Template.

When the CA-Admin and me issue a certificate manually based on a template copy of "Domaincontroller" the connection is established sucessfully.

So I like to know which is the correct Certificate Template for IP-Sec peers to use for SCEP and MS Enterprise CA (Its an Microsoft 2008R2 Enterprise Server)?

Anyone done this before?

[Jakob Roemhild]

No Idea anyone?

[Peter Koltl · Accepted solution]

ASA requires that the local and remote certificate contains IP Security Tunnel Endpoint (1.3.6.1.5.5.7.3.6) EKU (aka IP Security Tunnel Termination). You can create a Microsoft CA template to add it.

If you absolutely must go with the 'bad' cert, there is a command

ignore-ipsec-keyusage

but it's deprecated and not recommended.

Meanwhile at IETF:

RFC 4809

3.1.6.3.  Extended Key Usage

Extended Key Usage (EKU) indications are not required.  The presence
   or lack of an EKU MUST NOT cause an implementation to fail an IKE
   connection.

[Peter Koltl]

Is it solved, Jakob?

[Jakob Roemhild]

Hello Peter,

Sorry for the delayed reply. Yes this worked for me and saved me a lot of time!

Thank you very much!

Have a great day ahead!