Troubleshooting: Invalid User Errors After SecureAuth G3 Intermediate Certificates Expire

Version Affected: All — most commonly seen after May 16, 2025.

 

Overview

After the SecureAuth G3 Intermediate Certificates have expired, some authentication attempts against New Experience Datastores fail with an Invalid User error shown to end users.

Opening the New Experience Datastore's Summary tab fails to display the configured Service Account credentials — the Service Account Login and Password fields appear blank even though the Datastore is configured:

Browsing directly to https://localhost/SecureStorageApi/keychain/v1/secure_stores/ on the IdP server also throws a 500.30 error:

(Optional) SecureStore logging will also show an error similar to the below:

Unhandled exception. System.ArgumentNullException: Value cannot be null. (Parameter 's')
   at System.Convert.FromBase64String(String s)
   at SecureAuth.SecureStorage.Api.Configuration.DataProtectionConfiguration.ConfigureDataProtection(IServiceCollection services, Certificates certificateInfo, String idPCertificateBase64)
   at SecureAuth.SecureStorage.Api.Startup.ConfigureServices(IServiceCollection services)

To turn on SecureStore logging, open D:\SecureAuth\SecureStorageApi\web.config and change:

<aspNetCore processPath="dotnet" arguments=".\SecureAuth.SecureStorage.Api.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />

to:

<aspNetCore processPath="dotnet" arguments=".\SecureAuth.SecureStorage.Api.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />

Save the file, browse to the URL above again, and check the log file under D:\SecureAuth\SecureStorageApi\logs.

Turn off SecureStore logging again as soon as possible by reversing this web.config change — it should not be left running.

 

Cause

This is caused by SecureStore referencing an older Appliance Certificate that was issued by one of the following Intermediate Certificate Authority servers:

SecureAuth G3 Intermediate Certificate Authority 1A
SecureAuth G3 Intermediate Certificate Authority 1B
SecureAuth G3 Intermediate Certificate Authority 2A
SecureAuth G3 Intermediate Certificate Authority 2B
SecureAuth G3 Intermediate Certificate Authority 3A
SecureAuth G3 Intermediate Certificate Authority 3B
SecureAuth G3 Intermediate Certificate Authority 4A
SecureAuth G3 Intermediate Certificate Authority 4B

Since the certificate path is no longer trusted for the Appliance Certificate SecureStore uses, the connection cannot be made successfully.

 

Resolution

Use either method below:

Manual method:

• Go to D:\SecureAuth\SecureStorageApi.
• Back up the file SecureAuth.SecureStorage.Api.dll.
• Download the replacement file for your IdP version (make sure to unblock the file after downloading, if needed):
  • 20.06 / 21.04 / 21.08: SecureAuth.SecureStorage.Api.dll
  • 22.02 / 22.12: SecureAuth.SecureStorage.Api.dll
  • 23.07: SecureAuth.SecureStorage.Api.dll
  • 24.04: SecureAuth.SecureStorage.Api.dll
• Stop IIS on the server.
• Place the downloaded file in D:\SecureAuth\SecureStorageApi (on secondary servers too, if any).
• Restart IIS on the server.

Hotfix method:

• Download the SecureAuth-SecureStorage-Hotfix.exe (covers versions 20.06 through 24.04; make sure to unblock the file after downloading, if needed).
• Run the hotfix on the server (on secondary servers too, if any).
• Stop IIS on the server.
• Restart IIS on the server.

Confirm test results:

• Browse to https://localhost/SecureStorageApi/keychain/v1/secure_stores/ again and confirm it now shows a 405 response instead of a 500.30 error:

• Confirm the New Experience Datastore's Summary tab now shows the Service Account credentials as expected.
• Run a Test Connection for the Service Account in the Datastore's configuration to confirm it completes successfully.
• Test authentication against realms that use this Datastore.

Special Considerations

In rare cases, the steps above do not resolve the issue. If that happens, create a new Datastore (leaving the existing one in place), assign a realm to use the new Datastore, and confirm authentication succeeds against it.

Turn off SecureStore logging as soon as possible by reversing the web.config change above — it should not be left running.


 

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.