Expired SHA-2 (Oct 4, 2025) cert keeping APs from joining WLC [SOLVED]

[benjammin1001]

Hey all, 

 This is a new problem a lot of folks might be seeing soon as the SHA-2 cert that comes with AirOS 8.5.182 just expired Oct 4th, 2025. 

You know - this message in the AP logs: 

*Mar  1 00:01:41.335: AP has SHA2 MIC certificate - Using SHA2 MIC certificate for DTLS.
*Nov  3 21:20:04.000: %CAPWAP-5-DTLSREQSEND: DTLS connection request sent peer_ip: 192.168.x.x peer_port: 5246
*Nov  3 21:20:04.011: %PKI-3-CERTIFICATE_INVALID_EXPIRED: Certificate chain validation has failed.  The certificate (SN: <omitted>) has expired.    Validity period ended on 05:15:04 UTC Oct 4 2025 Peer certificate verification failed 001A
*Nov  3 21:20:04.011: DTLS_CLIENT_ERROR: ../capwap/base_capwap/capwap/base_capwap_wtp_dtls.c:509 Certificate verified failed!

The controller shows this cert: 

Certificate Name: Cisco SHA2 device cert
     Subject Name :
         C=US, ST=California, L=San Jose, O=Cisco Systems, CN=AIR-CT2504-K9-<omitted>, emailAddress=support@cisco.com
     Issuer Name :
         O=Cisco, CN=Cisco Manufacturing CA SHA2
     Serial Number (Hex):
         <omitted>
     Validity :
         Start : Oct  4 05:05:04 2015 GMT
         End   : Oct  4 05:15:04 2025 GMT
     Signature Algorithm :
         sha256WithRSAEncryption
     Hash key :
         SHA1 Fingerprint  : <omitted>
         SHA256 Fingerprint  : <omitted>

So - Besides the annoying "setting the clock back" to get the system up and rolling -- the question begs:

Is Cisco issuing updated certs that look like they can be loaded right into the controller?

If not - is this something that can be solved with certificates provided by, say LetsEncrypt?
(I realize the cert has to be loaded onto the controller via GUI/CLI -- but the CLI might be able to be automated via scripting)

So - I thought I'd see what people are up do coping with this problem. 

Thanks,

 -Ben

[Leo Laohoo]

---

@benjammin1001 wrote:
Is Cisco issuing updated certs that look like they can be loaded right into the controller?

---

No more releases after 8.5.182.0 (except Engineering Releases).

[benjammin1001]

Hey Leo, 

I realize the particular series WLC is EOL - and no more firmware releases.
But from what I'm reading so far (I'm still figuring it all out) - it looks like Cisco could just issue a cert to be uploaded to the unit. 

It also looks like the unit could just run in a "self-signed" or private CA mode. I just need to figure out the details. 

but thought I would ask if anyone else has this all figured out already since reboots are going to knock out existing installs. I can't think everyone upgraded off these just because they went EOL. 

let me know and thanks,

 -Ben

[Saikat Nandy]

These certs are called MIC - Manufactured installed certificates and these can not be updated or renewed. The other point that you have described is somewhat similar to LSC (Locally significant cert) which is a different concept altogether. LSC is mostly used by customers using AIR-CTVM. People having HW based controllers relies on MIC usually. So you will have to perform the workaround only. 

[benjammin1001]

Hi Saikat,

Thanks for the response. -- I do know what the MIC certs are. Thanks.

If "the workaround" you mean is setting:

config ap cert-expiry-ignore mic enable
config ap cert-expiry-ignore ssc enable

That's not working. Specifically, it appears the AP is rejecting the WLC's SHA-2 cert (as shown above) while the WLC is accepting the MIC cert from the AP regardless of date as the documentation for 8.5 describes on pdf page 658.

If that's the workaround you mean - then it's broken because of the AP side.

If you look at the AP's config - it looks like the proper "allow expired" are in the config -- but the AP is still
rejecting the SHA-2 cert from the WLC based on date.

(Since I'm not a dev I'm not sure if the ones without the ignore instruction are intended)

crypto pki trustpoint cisco-m2-root-cert
 revocation-check none
 rsakeypair Cisco_IOS_M2_MIC_Keys
!
crypto pki trustpoint Cisco_IOS_M2_MIC_cert
 revocation-check none
 rsakeypair Cisco_IOS_M2_MIC_Keys
 match certificate ciscomic allow expired-certificate
!
crypto pki trustpoint airespace-old-root-cert
 revocation-check none
 rsakeypair Cisco_IOS_MIC_Keys
!
crypto pki trustpoint airespace-device-root-cert
 revocation-check none
 rsakeypair Cisco_IOS_MIC_Keys
!
crypto pki trustpoint Cisco_IOS_MIC_cert
 revocation-check none
 rsakeypair Cisco_IOS_MIC_Keys
 match certificate ciscomic allow expired-certificate
!
crypto pki trustpoint virtual_wlc_trust_point
 revocation-check crl
 match certificate vwlcssc allow expired-certificate
!
crypto pki certificate map ciscomic 10
 issuer-name co cn = cisco manufacturing ca, o = cisco systems
!
crypto pki certificate map vwlcssc 1
 subject-name co o = cisco virtual wireless lan controller
!
crypto pki certificate chain cisco-m2-root-cert
!
 <certs deleted for brevity>
!
crypto pki certificate chain virtual_wlc_trust_point

This feels more like a bug after having set something that's supposed to ignore the expiration date. 

As for the LSC, the 8.5 Admin docs say right on pdf page 660:

You can use an LSC if you want your own public key infrastructure (PKI) to provide better security, to have
control of your certificate authority (CA), and to define policies, restrictions, and usages on the generated
certificates.

The LSC CA certificate is installed on access points and controllers. You need to provision the device certificate
on the access point. The access point gets a signed X.509 certificate by sending a certRequest to the controller.
The controller acts as a CA proxy and receives the certRequest signed by the CA for the access point.

This implies  LSCs aren't just a solution for virtual WLCs as LSCs can "provide better security".

Also, if you can better explain the RADIUS method (or point to an authoritative document) --- as it reads like it doesn't need the MIC date to be valid. I could set up RADIUS for the various clients still using these controllers/APs.... 

In the end, I'm looking to fix what looks like a missed bug waiting to happen after the SHA-2 cert expired and the "ignore" feature doesn't cover it. And regularly resetting the clock is something clients/users are going to raise an eyebrow at. Not a good look for Cisco.

Let me know and Thanks,

-Ben

[benjammin1001]

Just to bump this thread.....

I have a feeling a lot more people are going to be finding out their older Cisco WLC system breaking on the next reboot of either the controller (whole system) or AP (due to switch reboot or similar) and not understand why when they've already applied the ignore-expiry-date fix to their system. 

[benjammin1001 · Accepted solution]

So for anyone else watcing this post - it turns out, LSCs *ARE* indeed the answer to this problem.

Of course, available documentation leaves out a LOT of important details.

There's a mere obscure mention of a Cisco authored certificate server to handle this which (by the way) comes with almost no documentation. That was fun - but not too bad.

Then there's the LSC config page in the WLC that's all sorts of ugly to broken. Configuring using the CLI is the better way.

And then there's how to manage the clock -- and the missing steps in the Admin guide after enabling LSC and provisioning the APs that actually allows them to join.

It's fairly apparent Cisco had lost interest in keeping the documentation accurate for the final release version.

Oh well. Not really surprising.

Having to figure it out from scratch based on all the obstacles presented, it looks like this is a working solution although probably not for the faint of heart.

but it works. So... that's a win.

Cheers,

-Ben

[benjammin1001]

As an aside for people who may have viewed this thread, 
One of the installations I help a client with is using a 5508WLC running 8.1.131.0 -- It's Device SHA-2 cert expired Oct. 25, 2025 -- but the APs still join the system as one might expect. 

So - this issue feels like a bug with the 8.5.182.0 release where ignoring cert expiry doesn't work 100% like it should. 
Just thought I'd mention the very brief observation. 

Cheers, 

 -Ben