Forum Discussion

  • Mks_1973's avatar
    Mks_1973
    Iron Contributor

    Check these:

    SAML certificates usually have a defined expiration date. If the certificate is near expiration or has expired, it will lead to authentication issues.

    Verify the expiration date of the token signing certificate in the Enterprise Application > Single sign-on settings

    Sometimes, there’s a delay in syncing the updated certificate across the identity provider (IdP) and service provider (SP), ensure that you are not testing the login immediately after setting up SAML SSO or uploading a new certificate. Wait a few minutes to allow changes to propagate.

    If using multiple environments  (e.g., testing, staging, production), ensure that all environments are using the same certificate, miss match certificates in different environments can cause unexpected login failures.

    If you’re managing the certificates manually, make sure the certificate is consistently uploaded and applied in the application's SAML settings. Consider enabling Certificate Rollover to allow automatic rotation of certificates.

    Verify the Reply URL (Assertion Consumer Service URL) and Entity ID  in the Enterprise Application for SAML settings.

    Check Azure AD > Sign-in logs, you can find specific error messages related to SAML login issues.
    (InvalidSignature or CertificateRevoked could indicate issues with the certificate itself.)

    If re-uploading the certificate resolves the issue temporarily, this suggests a potential caching or sync issue, then you may need to contact Microsoft Support to investigate if there are backend sync issues or delays in certificate validation.

    ===============================


    In case of frequently update or replace certificates, consider automating the certificate update process using scripts and APIs.

    Below is an Example Script to Re-upload Certificate Automatically (Only if Needed):

    # Connect to Azure AD
    Connect-AzureAD

    # Define Application and Certificate Path
    $applicationId = "<Your-Enterprise-Application-ID>"
    $certificatePath = "C:\path\to\your\certificate.cer"

    # Load Certificate
    $certificate = [System.IO.File]::ReadAllBytes($certificatePath)

    # Update Application Certificate
    Set-AzureADApplication -ObjectId $applicationId -KeyCredentials $certificate

    Note: Use automated scripts with caution, especially in production environments. Make sure to replace the placeholders with your actual application ID and certificate path.








    • rsajjad's avatar
      rsajjad
      Copper Contributor

      I have verified the expiration date. The certificate is neither near expiration nor it has expired.

      I am not testing immediately, but even after a few hours, I have to re-upload the certificate to my service provider, then I am able to authenticate the user. 

      If using multiple environments  (e.g., testing, staging, production), ensure that all environments are using the same certificate, miss match certificates in different environments can cause unexpected login failures.

      I have checked the sign-in logs and none of the logs indicate the InvalidSignature or CertificateRevoked issue.

      Narrowing down the list of possible solutions. Do we have more suggestions/recommendations? 

      • Mks_1973's avatar
        Mks_1973
        Iron Contributor

        Check if your Service Provider (SP) automatically fetches metadata updates from Azure AD or requires manual refreshes. Some SPs require manual updates for any changes, including certificate renewals.
        Try updating the metadata XML file in your SP settings after the initial SAML configuration to ensure there’s no caching or synchronization delay.

        Did this ? In Azure AD, under Enterprise Application > Single sign-on settings, check if you have the option to enable Certificate Rollover.

        Some Service Providers cache metadata or certificates. If the SP is caching the certificate, it may not be picking up changes immediately. Clear the SP’s cache, or if your SP supports a “refresh” or “reload” metadata feature, use it to ensure the latest Azure AD certificate is being recognized.

        Go to Azure AD > Enterprise Applications > Your Application > Single sign-on > SAML-based Sign-on and verify if there are multiple certificates listed (e.g., primary and secondary).

        If SAML assertions are encrypted, ensure that both the encryption and signing certificates are up-to-date and correctly configured. Sometimes mismatches occur between the two, causing authentication issues.

        Please also double-check that the signing certificate matches the encryption expectations of your SP, and update the SP with both certificates if needed.

        Also if you have access to logs on the SP side, enable detailed SAML logs. This could reveal whether the issue is related to certificate validation, metadata synchronization, or another problem.

        Also Look for specific errors or timeouts in the SP logs around the certificate validation steps. Errors such as cert_not_valid, unable_to_retrieve_metadata, or signing_cert_mismatch can provide clues.

        If Possible: Set up a temporary test instance of your application (or use a testing environment) and apply the same SAML settings. This will help isolate whether the issue is specific to the current SP configuration or an underlying Azure AD sync issue. If the test environment does not face the same issue, this suggests a configuration or caching problem specific to your SP environment.

        Also recheck Azure AD Synchronization/Latency Issues.


        If this problem persists, you might consider automating the certificate re-upload process as a temporary workaround using Azure AD APIs or scripts (similar to the PowerShell script provided earlier).
        By scheduling this update periodically (e.g., weekly or monthly), you can avoid frequent manual interventions while investigating the underlying issue.

        But if these steps don’t provide a resolution, I recommended to open a support ticket with Microsoft for a deeper investigation.

Resources