Authentication attempts against New Experience Datastores fail with 'Invalid User' after SecureAuth G3 Intermediate Certificates have expired

Description:  
*** This is likely to only apply after May 16th 2025 ***

After the SecureAuth G3 Intermediate Certificates have expired, some authentication attempts against New Experience Datastores can fail and display an 'Invalid User' error to end users



Opening the New Experience Datastore Summary should fail to display the Service Account credentials, as below



Browsing to the below URL directly on the IdP Server will also throw a 500.30 error
https://localhost/SecureStorageApi/keychain/v1/secure_stores/



(Optional) SecureStore logging will also display 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)
at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
at System.Reflection.MethodBaseInvoker.InvokeDirectByRefWithFewArgs(Object obj, Span`1 copyOfArgs, BindingFlags invokeAttr)
at System.Reflection.MethodBaseInvoker.InvokeWithOneArg(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at Microsoft.AspNetCore.Hosting.ConfigureServicesBuilder.InvokeCore(Object instance, IServiceCollection services)
at Microsoft.AspNetCore.Hosting.GenericWebHostBuilder.UseStartup(Type startupType, HostBuilderContext context, IServiceCollection services, Object instance)
at Microsoft.AspNetCore.Hosting.GenericWebHostBuilder.<>c__DisplayClass7_0.<UseStartup>b__0(HostBuilderContext context, IServiceCollection services)
at Microsoft.Extensions.Hosting.HostBuilder.InitializeServiceProvider()
at Microsoft.Extensions.Hosting.HostBuilder.Build()
at SecureAuth.SecureStorage.Api.Program.Main(String[] args)

To turn on SecureStore logging, go to the below file:
D:\SecureAuth\SecureStorageApi\web.config

Change the following value:

<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 and browse to https://localhost/SecureStorageApi/keychain/v1/secure_stores/ again.
Open the log file found at D:\SecureAuth\SecureStorageApi\logs
*** Turn off SecureStore logging as soon as possible by reversing the change to the web.config - this should NOT be left running ***

Cause:  
This is caused by SecureStore referencing an older Appliance Certificate which has been issued by the Intermediate Certificate Authority Servers mentioned below:

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

As the Certificate Path is not trusted for the Appliance Certificate used for SecureStore, the connection cannot be made successfully

Resolution:  

• Go to the following folder - D:\SecureAuth\SecureStorageApi
• Take a backup of the file named - SecureAuth.SecureStorage.Api.dll
• Download the file below, relevant to your version of IdP
  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 the folder - D:\SecureAuth\SecureStorageApi (must be done on secondary servers as well)
• Restart IIS on the Server
• Browse to https://localhost/SecureStorageApi/keychain/v1/secure_stores/ to ensure you no longer see a 500.30 error, you should see a 405 response, as below
  
  
  
  
• At this point, check your New Experience Datastore to ensure it is retrieving your Service Account Credentials as expected.
• Run a 'Test Connection' for the Service Account within the Datastore Configuration to ensure it completes successfully
• Test Realm Authentications
  
  

Special Considerations: 
In rare situations, it has been necessary to create a new Datastore.
If doing the above does not fix the issue, create a new Datastore (leaving your existing Datastore in place), assign a Realm to use the new Datastore and confirm the authentication behaviour.

*** Turn off SecureStore logging as soon as possible by reversing the change to the web.config - this 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.