Troubleshooting: Invalid User Errors After SecureAuth G3 Intermediate Certificates Expire – SecureAuth Support

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.

End-user login page showing an Invalid User error banner above the username/password fields.

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:

New Experience Datastore Connection Settings summary showing empty Service Account Login and Password fields under Credentials, despite the Connection String and Search Filter being populated.

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

Browser showing HTTP Error 500.30 - ASP.NET Core app failed to start when browsing directly to the SecureStorageApi keychain endpoint.

(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:

Browser showing a generic HTTP Error 405 page when browsing to the SecureStorageApi keychain endpoint, confirming the endpoint is reachable again.

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.