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

PDF

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

Locally significant certificates

Updated: October 7, 2026

Want to summarize with AI?

Log in

Explains how to configure Cisco Catalyst 9800 Series Wireless Controller and Access Points (APs) to use the Locally Significant Certificate (LSC).

You can use the LSC certificates for two things:

  • To mutually authenticate the controllers and the APs in CAPWAP.

  • To authenticate APs against the switch using 802.1X and EAP-TL.

The controller allows for two methods to forward certificate requests to the CA:

  • Simple Certificate Enrollment Protocol (SCEP): it is used to forward certificate requests generated on the APs to the SCEP server for the CA signs them. After that they are sent back to the controller, later the APs install them. 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.

  • Enrollment over Secure Transport (EST): it is very similar to SCEP, it is used to forward the certificates requests generated on the APs to the EST Server for the CA signs them. After that they are sent back to the WLC, later the APs install them. In EST HTTPS is used as the transport protocol for the PKI messages. EST is considered as a more secure SCEP alternative by the industry.

LSC provisioning and communication process

The AP communicates with the controller using the CAPWAP protocol. Any request to sign the certificate and issue the CA certificates for AP and controller itself must be initiated from the controller. The AP does not communicate directly with the CA server. The CA server details must be configured on the controller and must be accessible.

  • 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.