Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Configuration Guide: Configuring Legacy SCEP using the CLI.

Feature Infomration:

The Simple Certificate Enrollment Protocol is a protocol designed to make the issuing and revocation of digital certificates as scalable as possible. The idea is that any standard network user should be able to request their digital certificate electronically and with as little intervention from network adminstrators. For VPN deployments require certificate authentication using  the enterprise CA or any 3rd party CA which supports, SCEP, this means the users can now request for signed certs from their client machines without having to involve their network adminstrators. If the user wants to configure the ASA as the CA server itself then SCEP is not what you're looking for, please refer to the following document instead:

The Local CA

As of ASA v8.3 there are two methods of SCEP that are supported:

1. the old method also called legacy SCEP is what will be discussed in this document.

2. SCEP proxy, is the newer method where the ASA proxies the certificate enrollment request on behalf of the client. This process is neater as it doesn't require an extra tunnel group and is also more secure. However the downside is that SCEP proxy only works with AC v3.x. This means that the current AC client version for mobile devices doesn't support SCEP proxy. You'll find more information related to the feature parity between mobile clients and the latest AC client version documented in bug #CSCtj95743(check the j-comments).

Note:  If the user requires certificate enrollment for anything other than mobile devices, always use SCEP proxy over legacy SCEP. Only in cases where it isn't supported due to either ASA or client versions should you configure legacy SCEP, and even then in case of the former upgrade the ASA code is the better option.

This document will only configure a configuration of the first method, Legacy SCEP.

Configuration Steps:

When using Legacy SCEP, there are a few things that you have to keep in mind:

1. After the client has recieved the signed certificate, for the ASA to be able to authenticate the client it should recognise the CA that signed the certificate so you need to ensure that the ASA has also enrolled with the CA server. The process of enrolling the ASA should be the first step as it established two things:

       a. the CA is configured correctly and able to issue certificates via SCEP(if you use URL for enrollment method)

       b. the ASA is able to communicate with the CA, so if your client isn't able to then it's an issue between the client and the ASA.

2. When the client attempts its first connection it will not have a signed certificate, so there has to be some other way to authenticate the client.

3. during the certificate enrollment process, the ASA plays  no role whatsoever. It only serves as the VPN aggregator so that the client can build a tunnel to securely obtain the signed certificate. Once the tunnel has established, the client has to be able to reach the CA server otherwise it will not be able to enroll.

Step 1: Enroll the ASA

This step is relatively easy and doesn't require anything new. You can find more details on how to enroll the ASA to a 3rd party CA here:

Enrolling the Cisco ASA to a CA Using SCEP

Step 2: Configure the tunnel to use for enrollment

As I mentioned before, for the client to be able to get a certificate it should be able to build a secure tunnel with the ASA using some other method of authentication. To do this you need to configure one tunnel-group that will only be used for the very first connection attempt when the client makes a cert request. Here's a snapshot of the configuration I use to define this tunnel-group, the important lines are marked in bold-italics:

rtpvpnoutbound6(config)# sh run user
username cisco password ffIRPGpDSOJh9YLq encrypted privilege 0

rtpvpnoutbound6# sh run group-policy gp_certenroll
group-policy gp_certenroll internal
group-policy gp_certenroll attributes
wins-server none
dns-server value <dns-server-ip-address>
vpn-tunnel-protocol ikev2 ssl-client ssl-clientless
group-lock value certenroll
split-tunnel-policy tunnelspecified
split-tunnel-network-list value acl_certenroll
default-domain value
anyconnect profiles value pro-sceplegacy type user

rtpvpnoutbound6# sh run access-l acl_certenroll
access-list acl_certenroll remark to allow access to the CA server
access-list acl_certenroll standard permit host <ca-server-ipaddress>

rtpvpnoutbound6# sh run all tun certenroll
tunnel-group certenroll type remote-access
tunnel-group certenroll general-attributes
address-pool ap_fw-policy
authentication-server-group LOCAL
secondary-authentication-server-group none
default-group-policy gp_certenroll
tunnel-group certenroll webvpn-attributes
authentication aaa
group-alias certenroll enable

Here's the client profile that I've used, you can either paste this into a notepad file and then import it into the ASA or you can configure it using the ASDM directly:

<?xml version="1.0" encoding="UTF-8"?>
<AnyConnectProfile xmlns="" xmlns:xsi="" xsi:schemaLocation=" AnyConnectProfile.xsd">
<UseStartBeforeLogon UserControllable="true">false</UseStartBeforeLogon>
<AutomaticCertSelection UserControllable="true">false</AutomaticCertSelection>
<AutoConnectOnStart UserControllable="true">false</AutoConnectOnStart>
<MinimizeOnConnect UserControllable="true">true</MinimizeOnConnect>
<LocalLanAccess UserControllable="true">false</LocalLanAccess>
<ClearSmartcardPin UserControllable="true">true</ClearSmartcardPin>
<AutoReconnect UserControllable="false">true
<AutoReconnectBehavior UserControllable="false">ReconnectAfterResume</AutoReconnectBehavior>
<AutoUpdate UserControllable="false">true</AutoUpdate>
<RSASecurIDIntegration UserControllable="false">Automatic</RSASecurIDIntegration>
<PPPExclusion UserControllable="false">Disable
<PPPExclusionServerIP UserControllable="false"></PPPExclusionServerIP>
<EnableScripting UserControllable="false">false</EnableScripting>
<CAURL PromptForChallengePW="false" >scep_url</CAURL>
<EnableAutomaticServerSelection UserControllable="false">false

Note:  You'll notice that's i've not configured a group-url for this tunnel group. This is important because legacy SCEP will not work the URL, you have to select the tunnel group with using it's alias.

Step 3: Configure the tunnel that will actually be used by the client for connection user certificates for authentication

Once the client has recieved the signed ID certificate it can now connect using cert authentication. But the actually tunnel-group that the client will actually use to connnect has still not been configured. This configuration is very similar to how you configure any other connection-profile(this term is synonymous with tunnel-group and not to be confused with client profile) which uses cert authentication. Here's a snapshot of the configuration I've used for this tunnel:

rtpvpnoutbound6(config)# show run access-l acl_fw-policy
access-list acl_fw-policy standard permit

rtpvpnoutbound6(config)# show run group-p gp_legacyscep
group-policy gp_legacyscep internal
group-policy gp_legacyscep attributes
vpn-tunnel-protocol ssl-client
split-tunnel-policy tunnelspecified
split-tunnel-network-list value acl_fw-policy
default-domain value
anyconnect modules value dart

rtpvpnoutbound6(config)# show run tunnel tg_legacyscep
tunnel-group tg_legacyscep type remote-access
tunnel-group tg_legacyscep general-attributes
address-pool ap_fw-policy
default-group-policy gp_legacyscep
tunnel-group tg_legacyscep webvpn-attributes
authentication certificate
group-alias legacyscep enable
group-url enable


As of when going to press, the only situation one should use legacy scep is when using mobile devices so this section only deals with mobile clients. When you attempt to connect the first time, just put in the ASA's hostname or ip address and then select "certenroll" or whatever group alias you configured in step 2. Here you'll be prompted for a username and password and you'll have the "get certicate" button. Once you hit this button, if you check your client logs, you should see the following:

[06-22-12 11:23:45:121] <Information> - Contacting
[06-22-12 11:23:45:324] <Warning> - No valid certificates available for authentication.
[06-22-12 11:23:51:767] <Information> - Establishing VPN session...
[06-22-12 11:23:51:879] <Information> - Establishing VPN session...
[06-22-12 11:23:51:884] <Information> - Establishing VPN - Initiating connection...
[06-22-12 11:23:52:066] <Information> - Establishing VPN - Examining system...
[06-22-12 11:23:52:069] <Information> - Establishing VPN - Activating VPN adapter...
[06-22-12 11:23:52:594] <Information> - Establishing VPN - Configuring system...
[06-22-12 11:23:52:627] <Information> - Establishing VPN...
[06-22-12 11:23:52:734] <Information> - VPN session established to
[06-22-12 11:23:52:764] <Information> - Certificate Enrollment - Initiating, Please Wait.
[06-22-12 11:23:52:771] <Information> - Certificate Enrollment - Request forwarded.
[06-22-12 11:23:55:642] <Information> - Certificate Enrollment - Storing Certificate.
[06-22-12 11:24:02:756] <Error> - Certificate Enrollment - Certificate successfully imported. Please manually associate the certificate with your profile and reconnect.

Even though the last message says "error" it's infact only to inform the user that this step is necessary for that client to be used for the next connection attempt which will be to the second connection profile configured in step 3.

Version history
Revision #:
1 of 1
Last update:
‎07-04-2012 06:18 PM
Updated by:
Labels (1)