Cisco Catalyst 9800 Series Wireless Controller Software Configuration Guide, Cisco IOS XE 26.1.x

PDF

Cisco Catalyst 9800 Series Wireless Controller Software Configuration Guide, Cisco IOS XE 26.1.x

Locally significant certificates

Updated: April 10, 2026

Want to summarize with AI?

Log in

Explains how to configure a wireless controller and LAP to use the locally significant certificate (LSC).

A locally significant certificate (LSC) is a PKI certificate that

  • provides mutual authentication between Cisco Catalyst 9800 Series Wireless Controller and Lightweight Access Points (LAPs)

  • generates certificates directly on APs and controllers, and

  • enables organizations to use their own PKI for better security control and Certificate Authority (CA) management.

LSC provisioning and communication process

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 Enrollment

Certificate provisioning in controllers

Certificate provisioning in controllers is a security process that you use to:

  • Install new Locally Significant Certificate (LSC) certificates (both Certificate Authority (CA) certificates and device certificates) on the controller

  • Use Simple Certificate Enrollment Protocol (SCEP) to receive Certificate Authority (CA) certificates from the CA server during initial setup when the controller has no certificates, and

  • Push the same Certificate Authority (CA) certificates to Access Points (APs) when you provision the Access Points (APs) with Locally Significant Certificates (LSCs).

RSA keypair recommendations

These recommendations apply when configuring PKI certificates with RSA keypairs:

Note

We recommend that you use a new RSA keypair name for the newly configured PKI certificate. If you want to reuse an existing RSA keypair name (that is associated with an old certificate) for a new PKI certificate, do either of the following:

  • Do not regenerate a new RSA keypair with an existing RSA keypair name. Instead, reuse the existing RSA keypair name. All certificates associated with the existing RSA keypair become invalid when you regenerate a new RSA keypair with an existing name.

  • Remove the old PKI certificate configurations before reusing the existing RSA keypair name for the new PKI certificate.

How device certificate enrollment works

When your Lightweight Access Point (LAP) and controller request Certificate Authority (CA)-signed certificates, they send the certRequest as a PKCS#10 message. The Certificate Authority (CA) receives a PKCS#10 certRequest. The Certificate Authority (CA) requires additional information to authenticate the identity of the requester and verify that the request is unaltered.

Summary

The key components involved in the device certificate enrollment process are:

  • Lightweight Access Point (LAP) and controller: request Certificate Authority (CA)-signed certificates by sending PKCS#10 messages. These messages contain Subject Name, Public Key, and other attributes.

  • Certificate Authority (CA): transforms the certRequest into an X.509 certificate after authentication and verification

  • PKCS#10 certRequest: contains digitally signed certificate request information including Subject Name and Public Key

  • Simple Certificate Enrollment Protocol (SCEP) client: provides functionality to wrap PKCS#10 in PKCS#7 Signed Data message type

Workflow

Your device certificate enrollment process works through these stages:

  1. The Lightweight Access Point (LAP) and controller create a PKCS#10 certificate request containing the Subject Name, Public Key, and other attributes to be included in the X.509 certificate, and digitally sign it with the Private Key of the requester.
  2. The PKCS#10 is wrapped in a PKCS#7 Signed Data message type as part of the Simple Certificate Enrollment Protocol (SCEP) client functionality, and the PKCSReq message is sent to the controller.
  3. The Certificate Authority (CA) receives the PKCS#10 certRequest and authenticates the identity of the requester and verifies that the request is unaltered.
  4. The Certificate Authority (CA) transforms the certRequest into an X.509 certificate.

Result

Upon successful enrollment operation, both the Certificate Authority (CA) and device certificates are available on the controller.

How certificate provisioning works on lightweight APs

Certificate provisioning enables lightweight APs (LAPs) to obtain new signed X.509 certificates while operating in CAPWAP mode. This process ensures secure communications between APs and controllers using updated security credentials.

Summary

The key components involved in certificate provisioning on lightweight APs are:

  • Lightweight Access Point (LAP): Initiates certificate requests and receives new certificates while in CAPWAP mode

  • Controller: Acts as a CA proxy to help obtain signed certificates from the Certificate Authority for the LAP

  • Certificate Authority (CA): Signs and validates certificate requests to issue new X.509 certificates

  • LWAPP payloads: Transport mechanism for certificate requests and responses between LAP and controller

Workflow

These stages describe how certificate provisioning works on lightweight APs:

  1. The LAP sends a certificate request to the controller to obtain a new signed X.509 certificate. The controller acts as a CA proxy and helps obtain the certificate request signed by the CA for the LAP.
  2. The certificate requests and certificate responses are transmitted between the LAP and controller using LWAPP payloads.
  3. Both the LSC CA and LAP device certificates are installed in the LAP, and the system reboots automatically.
  4. When the system comes up after reboot, the AP sends the LSC device certificate to the controller as part of the JOIN Request because it is configured to use LSCs. As part of the JOIN Response, the controller sends the new device certificate and validates the inbound LAP certificate with the new CA root certificate.

What’s 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.

Restrictions for locally significant certificates

  • The locally significant certificate (LSC) workflow differs in FIPS and WLANCC mode. Your Certificate Authority (CA) server must support Enrollment over Secure Transport (EST) protocol. Your CA server must also issue EC certificates in FIPS and WLANCC mode.

  • The Elliptic Curve Digital Signature Algorithm (ECDSA) cipher works only if both your AP and controller have EC certificates provisioned with LSC.

  • EC certificates (LSC-EC) can be provisioned only if CA server supports EST (and not SCEP).

  • You must configure FIPS and CC security modes to provision EC certificates.

  • Correct all AP misconfigurations before you enable LSC. You can view the count for misconfigured APs in the output of this show command: 
    Device# show wireless summary
Priming controller         : DISABLED
Max APs supported          : 3000
Max clients supported      : 32000
Access Point Summary
                      Total    Up    Down
------------------------------------------
802.11 2.4GHz             2     2       0
802.11 5GHz               5     2       3
802.11 6GHz               1     1       0
802.11 dual-band          2     0       2
802.11 dual-band(5/6GHz)  0     0       0
802.11 rx-dual-band       0     0       0
Client Serving(2.4GHz)    3     1       2
Client Serving(5GHz)      4     1       3
Client Serving(6GHz)      1     1       0
Monitor(Dual band)        0     0       0
Monitor(2.4GHz)           1     1       0
Monitor(5GHz)             1     1       0
Monitor(6GHz)             0     0       0
Sniffer(Dual band)        0     0       0
Sniffer(2.4GHz)           0     0       0
Sniffer(5GHz)             0     0       0
Sniffer(6GHz)             0     0       0
Misconfigured APs         1 (For more info use 'show ap tag summary')

    For more information about misconfigured APs, run the wireless config validate command. To view reported errors, run the show wireless config validation status command.