Information About Locally Significant Certificates (LSC)
This module explains how to configure the Cisco Catalyst 9800 Series Wireless Controller 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 the APs and controllers. You can then use the certificates to mutually authenticate the controllers and the APs.
In Cisco controllers, you can configure the controller to use an LSC. Use an 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 controller and then the Lightweight Access Point (LAP) from the CA Server.
The LAP communicates with the controller using the CAPWAP protocol. Any request to sign the certificate and issue the CA certificates for LAP and controller itself must be initiated from the controller. The LAP does not communicate directly with the CA server. The CA server details must be configured on the controller and must be accessible.
The 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 CA servers use to support certificate enrollment and revocation. It is widely used in Cisco and supported by many CA servers. In SCEP, 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 Router Advertisement (RA) Public Key Distribution
Certificate Provisioning in Controllers
The new LSC certificates, both CA and device certificates, must be installed on the controller.
With the help of SCEP, CA certificates are received from the CA server. During this point, there are no certificates in the controller. After the get operation of obtaining the CA certificates, 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) expiry failures, ensure that you configure a policy, as shown here:
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 multiple rules and filters under the same map. The rule mentioned in the example above 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 the LAP and the controller that request 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 must be digitally signed by the Private Key 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's identity and verify if the request is unaltered. (Sometimes, PKCS#10 is combined with other approaches, such as PKCS#7 to send and receive the certificate request or response.)
The PKCS#10 is wrapped in a PKCS#7 Signed Data 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 the CA and device certificates are 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 reboots automatically. The next time when the system comes up, because 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 functionality.