If you’re trying to connect older Access Points (APs) to a newer Wireless LAN Controller (WLC), you might stumble upon this frustrating issue: the AP simply refuses to join. Instead, the log fills up with errors like DTLS-5-PEER_DISCONNECT (Peer x.x.x.x has closed connection) and FATAL: Certificate unknown.
This can feel like a bad networking horror movie: the APs promise they’ll join, but no matter what you do, they ghost you.
The Problem
Legacy APs often rely on older certificates—sometimes expired or signed via outdated mechanisms—that newer WLC firmware considers insecure. More modern controllers play hardball, rejecting these APs outright during the certificate validation process. While this security feature is crucial for modern environments, it can be a nightmare if you’re working with legacy gear.
This issue tends to rear its head in scenarios where older access points are needed to bridge technology gaps, particularly in small office environments or branch offices where budgets don’t always allow for a full refresh of wireless infrastructure.
The Resolution
Good news! There’s a straightforward workaround that lets you tell your WLC, “Hey, ease up on the certificate checks for these APs.” Here’s how I resolved the issue on my Cisco 4404 WLC:
- Log into the controller via SSH.
- Run the following commands:
config ap cert-expiry-ignore mic enable
config ap cert-expiry-ignore ssc enable
Within seconds, your rogue APs will start registering one by one. You’ll start seeing logs indicating successful joins, and your APs will be operational again.
What’s Happening Under the Hood?
The commands effectively disable certificate expiry checks for Management Interface Certificates (MICs) and Self-Signed Certificates (SSCs) on the WLC. While this does skirt certificate validation (not recommended in ultra-secure environments), it’s perfectly fine for lab setups, older hardware, or practical use cases like breathing life into APs still serving a purpose for smaller office locations.
Saving money by utilizing existing infrastructure makes sense, but just be mindful of security implications if these APs are in production.
Final Thoughts
This isn’t a scenario most people will run into unless you’re dealing with older hardware. Still, it’s worth documenting because situations like this can catch sysadmins off guard and leave you scrambling. If nothing else, it’s a reminder to double-check hardware compatibility, test upgrades in a sandbox environment, and plan for refresh cycles as hardware ages out.
Also, a pro tip: whenever you’re patching systems in smaller environments, try to have a contingency plan (like a spare AP or temporary fallback network). Even in a small office, downtime can be disruptive if employees depend on a stable connection for their work.