Explains the authorization policy, configuration workflows, and verification steps for enabling MIC and LSC APs to securely join the controller, highlights behavioral changes, and outlines recommendations and limitations for policy deployment.

Support for MIC and LSC APs joining the controller

Support for MIC and LSC access points joining the controller is an authorization policy feature that

allows MIC APs to join LSC-deployed controllers without requiring LSC provisioning
enables LSC and MIC APs to coexist on the same controller simultaneously, and
eliminates the need to provision LSC on MIC APs before moving them to LSC-deployed controllers.

Authorization policy behavior changes

The authorization policy behavior differs between software releases:

Cisco IOS XE Bengaluru 17.4.1 and earlier: If your APs have default certificates (Manufacturing Installed Certificates [MIC] or Secure Unique Device Identifier [SUDI]), they cannot join an LSC-deployed controller, where the management certificate of the controller is an LSC. To resolve this issue, provision LSC on your APs. Use the provisioning controller before you move them to the LSC-deployed controller.
Cisco IOS XE Bengaluru 17.5.1 onwards: The new authorization policy configuration allows MIC APs to join the LSC-deployed controller, so that LSC APs and MIC APs can coexist on the controller.

Recommendations and limitations

When you configure the CA server with manual enrollment to accept certificate signing request (CSR), the controller monitors for the CA server response. If the CA server does not respond for 10 minutes, the fallback mode activates.

Cisco Wave 2 APs regenerate CSR, and a fresh CSR is sent to the CA server.
Cisco IOS APs restart, and then Cisco IOS APs send a fresh CSR, which is in turn sent to the CA server.

The locally significant certificate (LSC) feature on the controller does not work with password challenge authentication. Therefore, for LSC to work, you must disable password challenge on the CA server.

If you are using Microsoft CA, use Windows Server 2012 or later as the CA server.

MIC and LSC access point authentication

Summary

The Manufacturer Installed Certificate (MIC) and Local Significant Certificate (LSC) access point authentication configuration involves these stages:

Controller: Manages authentication policies and trustpoint configuration for secure access point connections
Access points: Require certificate-based authentication to join the controller
LSC trustpoint: Provides local significant certificate authentication mechanism
AP certificate policy: Defines authentication requirements and allowed access point lists

Workflow

The key components involved in the MIC and LSC access point authentication configuration are:

The network administrator configures the LSC trustpoint on the LSC deployed controller using CLI. Configure LSC on the controller (CLI)
The network administrator enables the AP certificate policy on access points using CLI. Enable the AP certificate policy on the APs (CLI)
The network administrator configures the AP policy certificate using the GUI interface. Configure the AP policy certificate (GUI)
The network administrator configures the allowed list of APs to join the controller using CLI. Configure the allowed list of APs to join the controller (CLI)

Result

Access points are properly authenticated and authorized to join the controller with secure certificate-based authentication enabled.

Configure LSC on the controller (CLI)

The server certificate used by the controller for CAPWAP-DTLS (Control and Provisioning of Wireless Access Points - Datagram Transport Layer Security) is based on the following configuration.

Before you begin

Ensure that you enable LSC by setting the appropriate trustpoints for the following wireless management services:
- AP join process: CAPWAP DTLS server certificate
- Mobility connections: Mobility DTLS certificate
- NMSP (Network Mobility Services Protocol) and CMX (Connected Mobile Experiences) connections: NMSP TLS certificate

Procedure

	1.	Enter global configuration mode. Example: `Device# configure terminal`
	2.	Configure the LSC trustpoint in the LSC-deployed controller. Example: `Device(config)# wireless management trustpoint trustpoint-name`

Enable the AP certificate policy on the APs (CLI)

Enable AP certificate policy during CAPWAP-DTLS handshake to allow MIC APs to join the controller.

If the management trustpoint is a locally significant certificate (LSC), by default, manufacturing installed certificate (MIC) APs fail to join the controller. This configuration acts as an enable or disable configuration knob that allows MIC APs to join the controller.
This configuration is a controller authorization to allow APs to join MIC at the time of Datagram Transport Layer Security (DTLS) handshake.

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
```
Note

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

Procedure

	1.	Enter global configuration mode. Example: `Device# configure terminal`
	2.	Configure the trustpoint name for the controller certificate chain. Example: `Device(config)# ap auth-list ap-cert-policy allow-mic-ap trustpoint trustpoint-name` Note The allow-mic-ap trustpoint command is required only for the virtual controller (Cisco Catalyst 9800-CL Wireless Controller for Cloud). In all the other appliance controller platforms, the default certificate is selected. This default certificate is manufacturer-installed SUDI.
	3.	Enable the AP certificate policy during CAPWAP-DTLS handshake. Example: `Device(config)# ap auth-list ap-cert-policy allow-mic-ap`
	4.	Enable the AP certificate policy as MIC. Example: `Device(config)# ap auth-list ap-cert-policy mac-address H.H.H policy-type mic` Example: `Device(config)# ap auth-list ap-cert-policy mac-address 1111.1111.1111 policy-type mic`

The AP certificate policy is now enabled and configured for MIC APs to join the controller during CAPWAP-DTLS handshake.

Configure the AP policy certificate (GUI)

Procedure

Choose Configuration > Wireless > Access Points

In the All Access Points window, click AP Certificate Policy.

In the AP Policy Certificate window, complete the following actions:

Click the Authorize APs joining with MIC toggle button to enable AP authorization.
From the Trustpoint Name drop-down list, choose the required trustpoint.
Click Add MAC or Serial Number to add a MAC address or a serial number manually or through a .csv file.

The Add MAC or Serial Number window is displayed.
Click the AP Authlist Type and enter the MAC address or the serial number. Upload the .csv file or enter the MAC address in the list box.

The newly added MAC address and serial numbers are displayed under List of MAC Address and Serial Numbers.
Click Apply.

The AP certificate policy is added to the AP Inventory window.

Note

To add a new AP with MIC, perform Step 1 to Step 3 described in Configuring the AP Policy Certificate (GUI) section. To add a new AP with LSC, perform the procedure described in the Configuring AP LSC Provision List (GUI) and Step 1 to Step 3 in the Configuring the AP Policy Certificate (GUI) section.

Configure the allowed list of APs to join the controller (CLI)

Create an allowed list of access points that can join the controller based on MAC address or serial number authentication.

The allowed list of APs can either be populated based on the Ethernet MAC address or based on the serial number of the APs.

Procedure

Enter global configuration mode.

Example:

Device# configure terminal

Configure the AP certificate policy based on the Ethernet MAC address or based on the assembly serial number of the AP.

Example:

Device(config)# ap auth-list ap-cert-policy mac-address AP-Ethernet-MAC-address policy-type mic

Example:

Device(config)# ap auth-list ap-cert-policy serial-number AP-serial-number policy-type mic

Example:

Device(config)# ap auth-list ap-cert-policy mac-address 00b0.e192.0d98 policy-type mic

The AP certificate policy is configured and the specified access points are added to the allowed list for joining the controller.

Verifying the configuration status

To verify if the APs have been authorized by the AP certificate policy, use this command:

Device# show ap auth-list ap-cert-policy
Authorize APs joining with MIC : ENABLED
MIC AP policy trustpoint
Name : CISCO_IDEVID_SUDI
Certificate status : Available
Certificate Type : MIC
Certificate Hash : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

To verify the AP certificate policy on the MAC address and the serial number of the AP, use these commands:

Device# show ap auth-list ap-cert-policy mac-address
MAC address      AP cert policy
---------------------------------
1111.2222.3333   MIC

Device# show ap auth-list ap-cert-policy serial-number
Serial number    AP cert policy
--------------------------------
F1234567890      MIC

Note
If you set an invalid trustpoint (not SSC), the allow-mic-ap policy does not enable. If you set an invalid trustpoint, this error displays on the console:
Device(config)# ap auth-list ap-cert-policy allow-mic-ap trustpoint lsc-root-tp
Dec 18 07:38:29.944: %CERT_MGR_ERRMSG-3-CERT_MGR_GENERAL_ERR: Chassis 1 R0/0: wncd: General error: MIC AP Policy trustpoint: 'lsc-root-tp' cert-chain type is LSC, It must be either MIC or vWLC-SSC

Need help?

Open a support case

(Requires a Cisco Service Contract)

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.