故障现象描述

• 时间/地点：周二上午，办公楼3-5层；企业SSID“Corp-Secure”。
• 终端：Windows 与 iOS。
• 现象：
  • 802.1X（EAP-TLS）认证失败，控制器日志提示 unknown CA。
  • 5GHz信号强度良好（-58 dBm）、干扰低。
  • 偶发拿到IP失败并被分配到隔离VLAN。
  • 访客SSID正常。
• 变更背景：近期更换了RADIUS服务器证书与中级CA（Intermediate CA）。

影响范围分析

• 空口/RF层面：信号强、干扰低，非无线覆盖/干扰问题。
• 局部性：仅3-5层，指向该楼层AP组/WLC映射、AAA Server Group、VLAN策略存在差异。
• 访客SSID正常：基础网络、AP/Switch/DHCP整体可用；问题集中在企业SSID的802.1X/AAA链路及动态策略。
• 结合“unknown CA”：主要集中在EAP-TLS证书链校验阶段（服务端证书链或RADIUS对客户端证书链的信任）。

排查步骤详解

以下步骤按照从底层到应用/安全分层进行，均为安全、可回退的只读或小范围验证操作。

1. 无线/物理与接入层快速确认

• AP与控制器状态：确认3-5层AP是否归属同一AP组/同一WLC，是否与其他楼层使用不同的WLAN Profile或RADIUS Server Group。
  • Cisco WLC 示例（针对单用户点调试，避免全局debug）：
    • show ap summary / show ap config general
    • show wlan <WLAN_ID>
    • show radius summary / show radius auth statistics
  • Aruba 示例：
    • show ap active / show ap bss-table
    • show aaa authentication-server
• 交换机/上行VLAN连通性：确认企业SSID对应的生产VLAN与隔离VLAN在3-5层上行Trunk已放通（只读检查），避免误判为二层封堵。

2. AAA链路连通性与分流检查

• RADIUS可达性（从WLC/控制器对RADIUS）：检查RADIUS组指向、超时/重传统计、是否与其他楼层使用不同RADIUS集群或不同证书版本。
  • 重点：3-5层AP组/WLAN是否绑定到了“新证书链”的RADIUS Server Group，而其他楼层仍用“旧证书链”。
• 认证失败原因核对（以RADIUS侧权威日志为准）：
  • ISE：Operations > RADIUS Live Logs，常见EAP-TLS失败码如 12514（证书信任失败/握手失败），Detail中出现 unknown ca/unknown CA。
  • NPS：事件查看器
    • 系统日志 Schannel 事件ID 36882/36886（未知CA/证书链问题）
    • NPS 事件6273（拒绝，原因：证书链或策略）
  • FreeRADIUS：-X 调试显示 “TLS Alert unknown ca”。
• 明确“unknown CA”归属：
  • 若RADIUS日志显示在验证客户端证书阶段报“unknown CA”：说明RADIUS不信任客户端证书的颁发链（客户端Root/Intermediate未被RADIUS信任）。
  • 若客户端/WLAN控制器日志显示在验证RADIUS服务器证书阶段报“unknown CA”：说明客户端不信任RADIUS服务器证书链（常见于缺失中级CA或证书名不匹配）。

3. 证书链与名称校验（EAP-TLS双向）

• RADIUS服务器证书（Server side）：
  • 证书链是否完整：RADIUS是否在握手中发送了完整链（Server Cert + 必要的Intermediate CA），不可只发Server Cert。
    • ISE：Admin > System > Certificates > System Certificates，查看EAP证书，确保“Trust for client authentication and Syslog”勾选合规，并且相关中级CA已导入到Trusted Certificates，且“Include Intermediate Certificates/Send CA certificates”选项正确。
    • NPS：RADIUS主机的本地计算机证书存储中，服务证书在“个人”下；对应的中级CA需在“中级证书颁发机构”，根CA在“受信任的根证书颁发机构”；EAP属性中选定的证书必须链路完整、EKU含Server Authentication、SAN包含期望FQDN。
  • 名称匹配：终端配置（Windows/iOS）若指定“连接到这些服务器名称/证书”，需与证书CN或SAN匹配（例如 radius.corp.com）。
  • 有效期与撤销：系统时间准确；若强制OCSP/CRL校验，确保终端可访问证书撤销分发点（可通过访客/蜂窝先验证网络路径）。
• 客户端证书（Client side）：
  • RADIUS信任的客户端CA是否包含颁发终端证书的根/中级CA。
    • ISE：Trusted Certificates中勾选“Trust for client authentication”给对应企业CA。
    • NPS：将客户端证书的根CA导入“受信任的根证书颁发机构”，中级CA导入“中级证书颁发机构”。
• 变更核对：近期“更换了RADIUS服务器证书与中级CA”后，是否同步：
  • 在RADIUS上正确安装并发送新的中级CA（经常遗漏，导致客户端报unknown CA）。
  • 在客户端侧（GPO/MDM）下发信任新的中级CA/更新802.1X配置中的受信任颁发者列表。
  • 在3-5层所用RADIUS组上的证书链与其他楼层不一致（强提示根因定位点）。

4. 动态VLAN/隔离VLAN策略验证

• 检查RADIUS返回属性（Tunnel-Type/Medium-Type/Tunnel-Private-Group-ID 或厂商特性如 Airespace-ACL-Name）：
  • 正常通过EAP-TLS应返回生产VLAN或权限；认证失败通常不应分配业务VLAN。
• WLC/WLAN配置：
  • 是否启用了失败时的“隔离/准入失败VLAN”或Posture/Fail-Open策略，导致失败用户被放入隔离VLAN。
  • 隔离VLAN的DHCP/ACL是否正确，偶发拿不到IP可能是隔离VLAN DHCP地址池耗尽或Trunk未放通该VLAN。
• 与其他楼层对比：确认3-5层AP组的WLAN策略是否单独启用AAA Override或隔离策略。

5. 客户端侧快速验证（选取1-2台样本机）

• Windows：
  • 事件查看器：Microsoft-Windows-WLAN-AutoConfig/Operational 中12013等EAP失败日志，常见“证书颁发者不受信任/unknown CA”。
  • mmc certlm.msc：检查“受信任的根证书颁发机构/中级证书颁发机构”中是否含新中级CA；802.1X配置是否限制特定服务器名称/CA。
• iOS：
  • 通过MDM配置文件核对802.1X Payload的受信任证书列表，是否包含新的中级CA；若用户端手动配置，风险更高，建议统一MDM。
• 工具化测试（可在隔离环境或实验AP上）：
  • eapol_test（wpa_supplicant工具）对RADIUS执行EAP-TLS握手，明确是服务端证书链问题还是客户端证书链不被信任。
  • FreeRADIUS rad_eap_test/ISE试用客户端认证模拟（不影响生产流量）。

根因分析结论

• 高概率根因（优先级最高）：
  • 3-5层AP组/WLAN指向了使用“新RADIUS证书链”的RADIUS Server Group，该RADIUS在EAP握手中未正确发送新的中级CA，或客户端未预置信任新的中级CA，导致客户端在验证RADIUS服务器证书时出现“unknown CA”并中止EAP-TLS。
  • 该失败触发WLAN的失败策略，用户被置入隔离VLAN；由于隔离VLAN DHCP/ACL配置不完善，出现偶发无法获取IP。
• 次高概率根因：
  • RADIUS侧未将用于验证客户端证书的企业Root/Intermediate CA纳入信任列表（RADIUS对客户端证书链报“unknown CA”），导致EAP-TLS被RADIUS拒绝。
• 影响范围呈楼层定向：
  • 指向AP组/WLAN Profile或RADIUS Server Group按楼层差异化配置，致使3-5层使用了“新证书链/新策略”，而其他区域未受影响或仍使用旧配置。

解决方案实施

A. 立即修复（保持安全基线，不降低加密/校验）

1. 修复RADIUS服务器证书链（首选）

• 在RADIUS上正确安装并链路化证书：
  • 安装服务证书（EKU含Server Authentication，SAN含radius FQDN），并将对应的中级CA导入“中级证书颁发机构/Trusted Certificates”。
  • 启用在EAP握手中发送中级CA（ISE勾选“Include/Send CA Certificates”，NPS确保证书链完整可被客户端构建）。
• 重启EAP/RADIUS服务进程（在窗口期，单节点轮转，保持HA）：
  • ISE节点逐台“停止/启动EAP服务”，或NPS服务重启，确保不中断整体认证能力。
• 验证1-2台Windows/iOS连接正常，再放大流量。

2. 客户端信任同步（并行执行，加速恢复）

• Windows域端：
  • 通过GPO下发新的中级CA到“受信任的中级证书颁发机构”，必要时同步新的根CA到“受信任的根证书颁发机构”。
  • 若802.1X策略限定服务器名称/颁发者，更新策略中受信任的服务器FQDN和CA列表。
• iOS端：
  • 通过MDM更新Wi-Fi配置文件，附带新的中级CA证书，并确认EAP-TLS服务器信任设置。
• 推送后抽检客户端证书存储与连接成功率。

3. 校验RADIUS信任客户端证书链（如RADIUS日志显示验证客户端失败）

• 将用于签发终端证书的企业Root/Intermediate CA导入RADIUS信任库，并标记“Trust for client authentication/EAP-TLS”。
• 再次发起认证，确认通过。

4. VLAN/隔离策略修正

• 明确隔离VLAN仅在认证失败或姿态失败时使用；检查其DHCP是否足够、Trunk是否放通，避免“拿不到IP”的混乱体验。
• 确认生产VLAN动态分配属性（Tunnel-Private-Group-ID等）在RADIUS策略中配置正确、楼层AP组策略一致。

B. 安全的临时绕过方案（不降低安全等级）

• 方案1（首推，最快速）：将3-5层AP组/WLAN临时指向“仍使用旧证书链且可用”的RADIUS Server Group（如现网有存量可用集群）
  • 只调整AP组到RADIUS组的映射，不改加密算法/不关闭服务器证书校验。
  • 小批量/小范围先行验证，再推广到3-5层全部AP。
• 方案2（同样安全）：快速下发信任更新
  • 通过GPO/MDM推送新中级CA与更新的802.1X配置，终端即可在数分钟至一小时内陆续恢复。
• 方案3（业务连续性）：临时使用访客SSID + 企业VPN（强制MFA、设备准入）
  • 确保访客到VPN网关的ACL放通，避免直连内部网；业务流量通过VPN受控，安全边界不降低。
• 明确禁止：禁用“验证服务器证书”、将EAP切换为明文凭据类协议（如PEAP-MSCHAPv2且不校验证书）、对WLAN作开放式接入等不安全操作。

C. 验证与回归

• 观察RADIUS/控制器日志：EAP-TLS成功率提升、unknown CA不再出现。
• 现场抽测Windows/iOS，确认正常拿到生产VLAN、DHCP成功。
• 连续监控24-48小时，关注3-5层与其他楼层的一致性。

预防建议措施

• 证书变更治理：
  • 在证书更换前至少2周完成客户端信任（GPO/MDM）预下发；采用并行有效期的中级CA过渡方案。
  • 在预生产/小范围AP组进行“灰度发布”，验证EAP-TLS握手、名称匹配、链路完整。
  • 使用证书到期与链路完整性监控（含中级CA），设置告警。
• 配置一致性：
  • 避免按楼层使用不同RADIUS证书链；若需分组，使用同一证书与同一信任集合，减少漂移。
  • 基线化WLAN/AAA策略，使用配置管理工具对比差异（AP组-WLAN-RADIUS映射、AAA Override、隔离VLAN等）。
• 可用性与可观测性：
  • 保持RADIUS集群HA与节点轮转升级策略，变更在低峰实施，控制器启用单客户端粒度debug。
  • 对隔离VLAN配置合理的DHCP与最小访问权限，避免误导性“无法获取IP”的现象。
• 名称与撤销策略：
  • 服务器证书SAN包含实际使用的FQDN；明确终端策略中“连接到这些服务器”列表。
  • 若启用OCSP/CRL强校验，确保相应地址可在预认证阶段可达（或采用允许列表放通）。

以上方案不涉及降低加密强度或关闭证书校验，符合安全规范。建议优先修复RADIUS证书链并统一3-5层RADIUS组与其他楼层的一致性，同时通过GPO/MDM推送新的中级CA以加速客户端侧恢复。