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:
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).
This document will only configure a configuration of the first method, Legacy SCEP.
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.
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:
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
dns-server value <dns-server-ip-address>
vpn-tunnel-protocol ikev2 ssl-client ssl-clientless
group-lock value certenroll
split-tunnel-network-list value acl_certenroll
default-domain value cisco.com
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
tunnel-group certenroll webvpn-attributes
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="http://schemas.xmlsoap.org/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://schemas.xmlsoap.org/encoding/ AnyConnectProfile.xsd">
<CAURL PromptForChallengePW="false" >scep_url</CAURL>
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 192.168.1.0 255.255.255.0
rtpvpnoutbound6(config)# show run group-p gp_legacyscep
group-policy gp_legacyscep internal
group-policy gp_legacyscep attributes
split-tunnel-network-list value acl_fw-policy
default-domain value cisco.com
anyconnect modules value dart
rtpvpnoutbound6(config)# show run tunnel tg_legacyscep
tunnel-group tg_legacyscep type remote-access
tunnel-group tg_legacyscep general-attributes
tunnel-group tg_legacyscep webvpn-attributes
group-alias legacyscep enable
group-url https://rtpvpnoutbound6.cisco.com/legacyscep 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 https://rtpvpnoutbound6.cisco.com.
[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 https://rtpvpnoutbound6.cisco.com.
[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.