EAP-TLS Renewal and MAB Fallback
A manufacturer has 1,200 domain laptops doing 802.1X EAP-TLS against FortiNAC-F, with certificates from a Microsoft AD certificate authority. MAB is enabled for 80 printers and 40 badge readers that cannot run a supplicant. After the FortiNAC server certificate is renewed, Windows laptops show 'server certificate does not match the name' and fall back to MAB, landing in the guest VLAN. Some other laptops fail with 'unknown CA'. Printers whose MAC addresses are recorded in uppercase with hyphens fail MAB, while badge readers recorded in lowercase with colons succeed. The RADIUS shared secret is correct and unchanged. AD LDAP synchronization runs nightly, and the wireless and wired supplicant profiles use the FQDN nac.example.com. The security team does not want failed EAP-TLS to fall back to MAB for laptops.
1. Why do some laptops report 'server certificate does not match the name' while others report 'unknown CA' after the same renewal?
Read the worked answer
These are two different trust failures. The name mismatch means the new server certificate's subject alternative name does not include the FQDN the supplicant is configured to validate, nac.example.com, or the client is still validating the old name. The unknown-CA error means the client does not trust the certificate chain that signed the new certificate, usually because the new issuing CA or intermediate is missing from the client's trusted store. Check the certificate SAN and full chain on FortiNAC, then compare it with the GPO or supplicant profile that defines the trusted root and server name. Test with an OpenSSL client command from a failing client network. Do not treat both errors as one problem; fixing the SAN will not fix a missing CA, and vice versa.
2. Why do the printers fail MAB while the badge readers succeed, and what do you change?
Read the worked answer
The difference is likely the MAC address format presented as the RADIUS User-Name. FortiNAC matches MAB against its endpoint database, and uppercase hyphenated values may not normalize to the lowercase colon format used by the successful records. Check the RADIUS authentication log for one failing printer and compare the User-Name string with the endpoint record. If they differ only in case or separators, add the printers in the format FortiNAC expects or enable normalization if supported. Also confirm the switch port is configured for MAB and that the printer is not sending EAP. Do not widen the MAB policy to match any MAC; correct the data and test one printer and one badge reader. If the printer still fails, check whether its MAC is learned on a different port or VLAN.
3. What policy do you recommend for laptops that fail EAP-TLS, and why?
Read the worked answer
Do not let laptop EAP-TLS failures fall back to MAB. That turns a certificate or configuration failure into a weaker MAC-only authentication path and can place a corporate laptop in a guest VLAN with different access. Put failed EAP-TLS laptops into a remediation or deny VLAN, return a clear message, and require the certificate problem to be fixed. Reserve MAB for devices that genuinely cannot supplicant, such as printers and badge readers, and combine MAB with profiling and a restricted VLAN. If MAB must be a fallback for a small exception group, scope it by switch port or device profile, not globally. Log and alert on EAP-TLS failures so the certificate renewal issue is visible rather than silently downgraded.