Information About Locally Significant Certificates (LSC)
This module explains how to configure the Cisco Embedded Wireless Controller on Catalyst Access Points and Lightweight Access Points (LAPs) to use the Locally Significant Certificate (LSC). If you choose the Public Key Infrastructure (PKI) with LSC, you can generate the LSC on APs and embedded wireless controllers. You can then use the certificates to mutually authenticate the embedded wireless controller and AP.
In Cisco embedded wireless controllers, you can configure the embedded wireless controller to use an LSC. You can use LSC, if you want your own PKI to provide better security, have control of your Certificate Authority (CA), and define policies, restrictions, and usages on the generated certificates.
You need to provision the new LSC certificate on the embedded wireless controller and then the Lightweight Access Point (LAP) from the Certificate Authority (CA) Server.
The LAP communicates with the embedded wireless controller using the CAPWAP protocol. Any requests to sign the certificate and issue the CA certificates for LAP and embedded wireless controller itself must be initiated from the embedded wireless controller. The LAP does not communicate directly with the CA server. The CA server details must be configured on the embedded wireless controller and must be reachable.
The embedded wireless controller makes use of the Simple Certificate Enrollment Protocol (SCEP) to forward certReqs generated on the devices to the CA and makes use of SCEP again to get the signed certificates from the CA.
The SCEP is a certificate management protocol that the PKI clients and Certificate Authority servers use to support certificate enrollment and revocation. It is widely used in Cisco and supported by many CA-Servers. In the SCEP protocol, HTTP is used as the transport protocol for the PKI messages. The primary goal of SCEP is the secure issuance of certificates to network devices. SCEP is capable of many operations, but for our release, SCEP is utilized for the following operations:
CA and RA Public Key Distribution
Certificate Provisioning on Controllers
The new LSC certificates, both CA and Device certificates must be installed on the controller.
With the SCEP protocol, the CA certificates are received from the CA server. During this point, there are no certificates in the controller, this is a clear Get Operation. These are installed on the controller. The same CA certificates are also pushed to the APs when the APs are provisioned with LSCs.
Preventing the Expiry of Manufacturing Installed Certificate
To prevent Manufacturing Installed Certificate (MIC) certificate-expiry failures, ensure that you configure a policy as shown below:
Create a certificate map and add the rules.
configure terminal crypto pki certificate map map1 1 issuer-name co Cisco Manufacturing CA
You can add more rules and filters under the same map. The rule mentioned in the above configuration specifies that any certificate whose issuer-name contains Cisco Manufacturing CA (case insensitive) is selected under this map.
Use the certificate map under the trustpool policy.
configure terminal crypto pki trustpool policy match certificate map1 allow expired-certificate
Device Certificate Enrollment Operation
For both LAP and controller that requests a CA signed certificate, the certRequest is sent as a PKCS#10 message. The certRequest contains the Subject Name, Public Key, and other attributes to be included in the X.509 certificate, and digitally signed by the PrivateKey of the requester. These are then sent to the CA, which transforms the certRequest into an X.509 certificate.
The CA that receives a PKCS#10 certRequest requires additional information to authenticate the requester identity and verify if the request is unaltered. Many a times PKCS#10 is combined with other approaches, such as PKCS#7 to send and receive the certificate request or response.
Here, the PKCS#10 is wrapped in a PKCS#7 SignedData message type. This is supported as part of the SCEP client functionality, while the PKCSReq message is sent to the controller. Upon successful enrollment operation, both CA and Device certificates are now available on the controller.
Certificate Provisioning on Lightweight Access Point
In order to provision a new certificate on LAP, while in CAPWAP mode the LAP must be able to get the new signed X.509 certificate. In order to do this, it sends a certRequest to the controller, which acts as a CA-proxy and helps obtain the certRequest signed by the CA for the LAP.
The certReq and the certResponses are sent to the LAP with the LWAPP payloads.
Both the LSC CA and the LAP Device certificates are installed in the LAP, and the system self-reboots. The next time it comes up, since it is configured to use LSCs, the AP sends the LSC Device Certificate to the controller as part of the JOIN Request. As part of the JOIN Response, the controller sends the new Device certificate and also validates the inbound LAP certificate with the new CA Root Certificate.
The LSC is supported on the controller and all Cisco Aironet Access Points.
LSC workflow is different in FIPS+WLANCC mode. CA server must support EST protocol and should be capable of issuing EC certificates in FIPS+WLANCC mode.
Also, the LSC is enabled on the controller (GUI and CLI).
What to Do Next
To configure, authorize, and manage certificate enrollment with the existing PKI infrastructure for controller and AP, you need to use the LSC provisioning.