Skip to main content
apFortinet
Staff
Staff
August 24, 2025

Troubleshooting Tip: SAML Authentication fails after firmware upgrade to v7.2.12, v7.4.9 or v7.6.4

  • August 24, 2025
  • 0 replies
  • 140904 views
Description This article describes how to resolve the SAML authentication issue that occurs after upgrading to v7.2.12, v7.4.9, or v7.6.4.
Scope FortiGate v7.2.12, v7.4.9, v7.6.4.
Solution

Beginning from v7.2.12, v7.4.9, and v7.6.4, FortiGate verifies the signature of SAML Response messages, in addition to SAML assertions. See this document: SAML certificate verification in Release Notes. This also includes the FIPS-CC CVE-Patched builds for FortiOS v7.2, such as FIPS-CC-72-5 and onward.

 

Update: 

As per Change #1196434, the following FortiOS versions add a CLI option that allows administrators to control signature verification for SAML responses and assertions: v8.0.0 (ETA Mar. 2026),  v7.6.5, v7.4.10, v7.2.14, v7.0.18, and all later versions. The new CLI option is displayed below and allows administrators to select between requiring both the response and the assertion to be signed (enable, set by default) OR requiring that at least one of the two is signed (disable). More information can be found in the FortiOS Release Notes, and the original article continues below:

 

config user saml

    edit <name>

        set require-signed-resp-and-asrt <enable | disable>

    next

end

 

  • enable: Both response and assertion must be signed and valid.
  • disable: At least one of the responses or assertions must be signed and valid (default).

 

After the upgrade, SAML authentication when using FortiGate as the Service Provider (e.g., for IPsec/SSL VPN, FortiGate administrator logins, SAML captive portal) may fail. The below debugs can be run on the FortiGate while reproducing the issue from the test user's PC:

 

diagnose debug console timestamp enable

diagnose debug application samld -1

diagnose debug application eap_proxy -1

diagnose debug enable

 

To stop the debugs:

 

diagnose debug disable

diagnose debug reset

 

The following error, 'Signature element not found', will be seen in the debugs on the FortiGate:

   

IDP sig verify is required for response and assertions

__samld_sp_login_resp [833]: Failed to process response message. ret=101(Signature element not found.)

samld_send_common_reply [92]: Code: 1, id: 563501, pid: 2470, len: 65, data_len 49

samld_send_common_reply [101]:     Attr: 22, 12, e

samld_send_common_reply [101]:     Attr: 23, 37, Signature element not found.

samld_send_common_reply [120]: Sent resp: 65, pid=2470, job_id=563501.

 

The user can see one of the errors below in the browser:

 

Stephen_G_0-1770816899567.png

 

Stephen_G_1-1770816899568.png

 

Stephen_G_2-1770816899710.png

 

Stephen_G_3-1770816899568.png

 

In certain scenarios, the SAML authentication process redirects users back to the SAML login page immediately after they complete the Multi-Factor Authentication step.

When trying to sign in with Security Fabric on the FortiGate as an administrator, the following error appears on the GUI. The SAML debug logs show the same error previously mentioned:

 

Stephen_G_4-1770816899664.png

 

When connecting via FortiClient SSL VPN, the connection will reach 'Status: 40%' and then fail with an error message stating 'Credential or SSLVPN configuration is wrong. (-7200)':

 

Stephen_G_5-1770816899572.png

 

Stephen_G_6-1770816899686.png

 

After the upgrade, both the SAML assertion and the response must be signed, not just the SAML assertion. 'Signature element not found' indicates that the signature was not provided. To resolve this issue, the SAML IdP must be configured to enable signing of both SAML responses and assertions. Note that it is safe to enable this on the IdP both before and after upgrading firmware on the FortiGate, as earlier FortiOS versions (such as FortiOS v7.2.10, v7.4.8, and v7.6.3) already supported signed responses and assertions.

 

The signatures can be verified in SAML Debug as follows:

To ensure that the entire Response is signed, it must include a <Signature> element, which is typically placed near the top of the Response. If the Assertion itself needs to be signed, a separate <Signature> element must be included within the <Assertion> sub-element, usually positioned near the top of the <Assertion>.


Microsoft Entra ID.
If Microsoft Entra ID is used as IdP, select 'Sign SAML response and Assertion' for the signing option under Single sign-on -> SAML Certificates -> Select Edit -> SAML Signing Certificate, as shown in the screenshot below:

 

Stephen_G_7-1770816899579.png

 

This will fix the SAML authentication issue, and users will be able to authenticate successfully.

 

Google IdP users.

The Google implementation only signs either the assertion or reply based on the 'Signed reply' checkbox, but cannot sign both. If 'Signed reply' is unchecked, only the SAML Assertions are signed. If 'Signed reply' is checked, only the SAML Reply is signed. Both will fail since the FortiGate expects both Assertion AND Reply to be signed.

The workaround is to downgrade to v7.2.11, v7.4.8, or v7.6.3. There is a fix scheduled to be available on the next firmware version (v7.2.14, v7.4.10, v7.6.5; see 'Update' note at the top of the article).

 

Cisco DUO.

When Cisco Duo is used as the Identity Provider (IdP), ensure that both the ‘Sign response’ and ‘Sign assertion’ options are selected as shown in the screenshot below.

 

To configure this:

  1. Navigate to Applications -> Select the SSO Application -> Scroll down to SAML Response settings.

  2. Under Signing options, select both:

    • Sign response.

    • Sign assertion.
                                                                    

Stephen_G_8-1770816899579.png

 

One potential mitigation strategy involves reverting to a previous firmware version, which may offer more stable performance under current conditions. While it is not a definitive fix, this approach could serve as a temporary workaround until a more permanent resolution is identified.

 

For more information, see Set up your own custom SAML app.


JumpCloud SAML.

For JumpCloud SAML, ensure 'Assertion and Response' is selected.

 

Stephen_G_9-1770816899579.jpeg

 

Active Directory Federation Services (AD FS).

AD FS uses Relying Party Trust for SAML. To check the signing option of the Relying Party Trust, use the command below and look for ' SamlResponseSignature '.

 

Get-AdfsRelyingPartyTrust -name <Relying Party Trust Name>

Execute the following command on AD FS PowerShell to ensure that the message and assertion are signed.

 

Set-ADFSRelyingPartyTrust -TargetName <Relying Party Trust Name> -SamlResponseSignature "MessageAndAssertion"

 

FortiIdentity Cloud:

If FortiIdentity Cloud is used as an IDP, log in to FortiIdentity Cloud -> Applications -> SSO -> Select Triple dots icon -> Select Edit -> Select Interface Detail -> Toggle 'Sign SAML response' to enable it

 

Stephen_G_10-1770816899580.png

 

Okta SAML:

 

Okta admin console :

  1. Log in to the Okta Admin Console.
  2. Go to Applications.
  3. Look for these signing options:
    • Response: Signed.
    • Assertion Signature: Signed.

 

2026-02-17_12-29-30.png

 

Note:

In the SAML debug log, the admin can still observe 'IDP sig verify is required for response and assertions', but the error Failed to verify signature. Then, the issue remains.

 

_update_sp_sig_opt [269]: IDP sig verify is required for response and assertions.
_samld_sp_login_resp [832]: Failed to process response message. ret=-111(Failed to verify signature.)
samld_send_common_reply [91]: Code: 1, id: 563940, pid: 354, len: 64, data_len 48
samld_send_common_reply [99]: Attr: 22, 12,
samld_send_common_reply [99]: Attr: 23, 36, Failed to verify signature.
samld_send_common_reply [119]: Sent resp: 64, pid=354, job_id=563940.
samld_process_request [145]: len=443, cmd=0, pid=354, job_id=563943
samld_process_request [162]: Received 443, 0x55556261d0

 

If the issue remains the same after changing the response and assertion, ensure that the certificate has been updated correctly according to this KB article: Technical Tip: SSL VPN SAML Authentication Fails with Error 'Failed to verify signature'.

 

Notes:

In scenarios where the SAML Enterprise application is handling auth requests from FortiGates in v7.2.12, v7.4.9 or v7.6.4 and also handling auth requests from lower FortiOS versions, it will be necessary to use a new SAML Enterprise application to handle auth requests from affected versions applying KB suggestions and keeping current sign-in settings on the current SAML Enterprise application.

 

If the IDP used is Identity360, there is a chance to fail the SAML authentication with the same error 'Failed to verify signature' even though both Response and Assertions are set to sign at the IDP.

In that case, verify if the 'Canonicalization Method' is set to 'Exclusive Canonicalization' instead of 'Exclusive Canonicalization With Comments'.

 

See the following:

 

Stephen_G_11-1770816899734.png

 

Related articles: