Skip to main content
vincent72
vincent72
New Member
May 30, 2025
Question

FAC with Windows Root CA - Windows Clients take several attempts to present certificate..

  • May 30, 2025
  • 2 replies
  • 1448 views

I'm running a FortiAuthenticator RADIUS (v_6.6.2) with Trusted CA policy, with the trusted CA being a Windows Server. We have a GPO setup to use either a machine or user cert and confirmed all the settings are consistent with the wireless SSID's auth settings. Clients are taking 60-100secs at times to authenticate.

When viewing the PCAP, the communication is seamless between the FG and FAC, but the client takes several Access-Challenges to finally present its certificate https://19216801.onl/ .

Has anyone else experienced this?

    2 replies

    Anthony_E
    Staff
    Anthony_E
    Staff
    June 2, 2025

    Hello Vincent,


    Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible.


    Thanks,

    Best Regards
    yungbull
    yungbull
    Explorer II
    August 19, 2025

    I have the same issue regardless of FortiAuth, FortiOS, or AP version.  Communication is seamless between the windows client and Fortiauth, but on frequent occasions, the client takes several attempts, sometimes 2 or more minutes to finally present the certificate.  Windows 11 clients are experience it more than Win10.

    Markus_M
    Staff & Editor
    Markus_M
    Staff & Editor
    August 19, 2025

    Better to open a new topic. For this issue, you'd better check in a packet capture what really is delayed. FortiAuthenticator responding to the client, client responding to the FortiAuthenticator. That'll determine where to look, and where not.

    Markus_M
    Staff & Editor
    Markus_M
    Staff & Editor
    June 2, 2025

    Hi Vincent,

     

    it will be difficult to say more with the given detail.

    Network packets seem fine and fast. You experience a delay, so see where the delay occurs.

    Important is what the authentication is and then continue with when the delay happens in that method.
    Since you have Wi-Fi and Access-Challenges, you would probably refer to some EAP method. As such, you have to find out which. The PCAP will tell you (the EAP type is written in the packet details).

    In EAP you'll see certificates sent from FortiAuthenticator to client in the challenges and in EAP-TLS, the client will also return certificate(s) in the Access-Requests.
    The delay will then sum-up from what happens in between the packets, such as the client responding slower with Access-Request to the Challenge, or the other way round. If the FortiAuthenticator is slow to respond to the Access-Requests, then check the RADIUS debug logs at https://fac-ip/debug. On the debug menu, enable the details debug mode and reproduce such slow communication alongside with a packet capture. The PCAP will show when the delay happens, which makes it easier to find that in the text-heavy debug log. Check to identify the packets with identifying criterion. The "State" attribute is quite good to identify a Access-Challenge and its single response, Access-Request.

     

    The Access-Challenge as response to the Access-Request will share the same ID. When you found the two packets, see what happens in between on FortiAuthenticator.

     

    Giving a few examples what might go wrong:

    • FAC is doing an LDAP lookup for the user with a given password (EAP-PEAP is likely for that) and the LDAP server responds very slow.
    • FAC could be generally overloaded, CPU processing is delayed if FortiAuthenticator is busy with other things or is running below specifications.
    • FAC can do some certificate checks on EAP-TLS, these might be slow, more boiling down to the point before.
    • There could be too many things to go on; the general log on FortiAuthenticator may give hints on that. Download them from the general log section (not the debug) and see if there is more stuff going on than you'd expect.

     

    Hope this helps for a start.

     

    Best regards,

     

    Markus

      Terms & ConditionsAccessibility statement