Troubleshooting: Problems Accessing the Admin Console

Version Affected: 9.2 and later — the version range differs by cause, noted individually below.
 
 

Overview

Accessing the Admin Console (New Experience) can fail in a few different ways — a blank white page, a "Please Wait..." message that never proceeds, a recycle back to the Username authentication prompt, or an outright error — instead of the console loading. There are several independent symptoms, each with its own error signature in the browser's Developer Tools Network tab (F12 in most browsers). Check DevTools first to identify which symptom applies before working through a resolution:

• See Symptom 1 - The Admin Console shows a blank/white page. DevTools shows a 500 Internal Server Error for these files, requested via httpproxy/tatooine/assets:
  • sa-components.min.css
  • webadmin.js
  Browsing to either URL directly shows a more detailed 500.24 error.
• See Symptom 2 - The Admin Console shows a blank/white page. DevTools shows a 502 error for one of these:
  • sysinfo/ping
  • sa-components.min.css and webadmin.js
  Navigating to the failing URL(s) directly shows a 502.3 error specifically.
• See Symptom 3 - The Admin Console shows a blank/white page. DevTools shows a 302 then 404, or a plain 404, for these files:
  • sa-components.min.css
  • webadmin.js
• See Symptom 4 - The Admin Console shows a blank screen, shows "Please Wait..." and never proceeds, or recycles back to the sign-in prompt. DevTools shows a 500 error for the following endpoints:
  • accesscontrol
  • sysinfo/ping
  Navigating to sysinfo/ping directly shows the misleading message "API is not enabled for Realm 0 or API Id/Key has not been generated"
• See Symptom 5 - The Admin Console shows a blank white screen or cycles back to the sign-in page. DevTools may also show a 500 error for this endpoint:
  • sysinfo/ping
• See Symptom 6 - After upgrading to 24.04, the Admin Console shows "Please Wait...". DevTools shows a 500 error for both of these:
  • sysinfo/ping
  • rbac_rules/accesscontrol
  Navigating to either directly shows a Newtonsoft.Json assembly load error.
• See Symptom 7 - The Admin Console shows "Please Wait..." and never proceeds, or cycles back to the sign-in page. DevTools shows a 500 error for both of these:
  • sysinfo/ping
  • rbac_rules/accesscontrol
  Navigating to either directly shows a different, mismatched-version file in the error (not Newtonsoft.Json).
• See Symptom 8 - The Admin Console shows "Please Wait...". DevTools shows the same 500 error for both of these:
  • sysinfo/ping
  • rbac_rules/accesscontrol
  Navigating to either directly shows a .NET Framework/targetFramework error instead.
• See Symptom 9 - The Admin Console shows "Please Wait..." and never proceeds, or cycles back to the sign-in page. DevTools shows a 500 error for this endpoint:
  • sysinfo/ping
  Opening the URL directly shows {"sysInfo":null,"status":"Failure","message":[]}, and the AdminApiLog shows Error while retrieving or refreshing Titan access_token.
• See Symptom 10 - On a server that previously worked fine, the Admin Console shows "Please Wait...". DevTools shows a 500 error for this endpoint:
  • sysinfo/ping
  Navigating to it directly returns {"sysInfo":null,"status":"Failure","message":[]}.
• See Symptom 11 - The Admin Console displays a NET::ERR_CERT_COMMON_NAME_INVALID or a HSTS error
• See Symptom 12 - The New Experience Dashboard specifically shows "ERROR Unable to load Dashboard Error: Request failed with status code 500", with related errors in the browser's Developer Tools Console
• See Symptom 13 - Opening a realm shows a server error reading "Input string was not in a correct format"
• See Symptom 14 - The Web Admin UI throws a NullReferenceException in Populate_InstanceList

These symptoms are not related, so a fix for one will not resolve another — use the signature above to identify which section applies.

 

In this article

• Symptom 1: Non-default IIS Authentication settings (500 Internal Server Error)
• Symptom 2: Bad SSL Binding Certificate or Incorrect ARR Proxy Settings (502.3 Error)
• Symptom 3: Sparkles CDN Unreachable, or ARR ‘Enable Proxy’ Disabled
• Symptom 4: Machine Key Mismatch or Incorrect Proxy Settings Between SecureAuth0 and the API (misleading "API is not enabled" error)
• Symptom 5: Appliance Is Behind a Proxy and IIS ARR Is Not Chaining Through It
• Symptom 6: Outdated Newtonsoft.Json binding redirect after upgrading to 24.04
• Symptom 7: A file under D:\SecureAuth\Api\bin is at the wrong version after an upgrade
• Symptom 8: .NET Framework 4.8 not installed (required for 24.04)
• Symptom 9: Incorrect Proxy Config in globalSettings.config
• Symptom 10: Missing Client Certificate on SecureAuth0
• Symptom 11: Certificate Bound to Port 443 Doesn't Cover the Access Hostname
• Symptom 12: Missing or Incorrect .NET (Core) Version for the Dashboard
• Symptom 13: Realm Folder Name Is Not in Upper Camel Case
• Symptom 14: Application Directory / Physical Folder Count Mismatch

Symptom 1: Non-default IIS Authentication settings (500 Internal Server Error)

Applies to versions 9.3 and later.

sa-components.min.css and webadmin.js (requested via httpproxy/tatooine/assets) return 500 Internal Server Error.

Browsing directly to https://localhost/httpproxy/tatooine/assets/sa-components.min.css shows a more detailed error, similar to the below:

This is caused by non-default authentication settings on the Default Web Site or the HttpProxy application in IIS — most commonly, ASP.NET Impersonation has been enabled.

Resolution:

To resolve this:

1. In IIS Manager, select Default Web Site, then open Authentication:

2. Confirm the settings match the defaults: Anonymous Authentication Enabled, and ASP.NET Impersonation, Basic Authentication, Forms Authentication, and Windows Authentication all Disabled. Correct anything that doesn't match.

3. Repeat the same check for the HttpProxy application specifically:

Back to top

Symptom 2: Bad SSL Binding Certificate or Incorrect ARR Proxy Settings (502.3 Error)

Applies to version 19.07 and later.

Opening the Admin Console shows a white screen, with DevTools showing a 502 error for sysinfo/ping, or for sa-components.min.css/webadmin.js. Navigating to the failing URL(s) directly shows a 502.3 error specifically.

Cause 1: Bad SSL Binding Certificate

DevTools shows the 502 error for sysinfo/ping. This is typically caused by a problem with the certificate bound to the Default Web Site's HTTPS binding — commonly an expired certificate, or a certificate whose full chain (intermediate and root certificates) isn't installed. A network trace confirms this:

Resolution 1:

To resolve this:

1. Acquire a valid replacement certificate, and confirm its full chain (intermediate and root certificates) is present in the Certificates console — a missing chain produces the same 502 error even with an otherwise valid certificate.
2. In IIS Manager, select Default Web Site and open Bindings.
3. Select the https binding and click Edit.
4. Click Select, choose the new certificate, and click OK.

If the error persists after replacing the certificate, capture a network trace to identify the exact cause and send it to SecureAuth Support:

1. Open an administrative Command Prompt.
2. Run netsh trace start scenario=internetclient capture=yes persistent=no level=verbose tracefile=c:\temp\net.etl.
3. Reproduce the issue.
4. Run netsh trace stop to stop tracing.
5. Send the resulting C:\Temp\net.etl file to SecureAuth Support.

Cause 2: Incorrect ARR Proxy Settings

DevTools shows the 502 error for sa-components.min.css and webadmin.js instead of sysinfo/ping, and opening either URL directly shows 502.3 - Bad Gateway specifically. This is caused by incorrect Proxy settings in IIS's Application Request Routing (ARR).

Resolution 2:

To resolve this:

1. Open IIS Manager and select the server name.
2. Open Application Request Routing Cache, then in the Actions pane select Server Proxy Settings.
3. Under Proxy Chain, confirm the proxy server's address and port match this environment's actual proxy configuration, then click Apply.
4. Reload the Admin Console.

Back to top

Symptom 3: Sparkles CDN Unreachable, or ARR ‘Enable Proxy’ Disabled

Applies to version 9.3 and later.

The Admin Console shows a white page because sa-components.min.css and webadmin.js fail to load. In DevTools, these files show either a 302 redirect followed by a 404, or a plain 404.

Cause 1: Sparkles CDN Blocked or Unreachable

DevTools shows a 302 redirect followed by a 404 for both files, rather than loading successfully. These files (and the others the Admin Console needs) can't be retrieved from the Sparkles CDN at all — not because of a local IIS misconfiguration, but because the appliance's network can't reach the CDN in the first place, typically due to a firewall or proxy blocking it.

To confirm this is the cause, browse directly to https://sparkles-content.prod.secureauth.com. A reachable URL returns an XML bucket listing similar to:

Anything other than a response like that — a timeout, a connection error, or a block page — means the URL isn't reachable from this network.

Resolution 1:

To resolve this, have your network team whitelist sparkles-content.prod.secureauth.com so the appliance can reach it, then reload the Admin Console.

Cause 2: Application Request Routing’s ‘Enable Proxy’ Setting Is Disabled

DevTools shows a plain 404 for both files (no 302 redirect first), and opening either URL directly shows 404.4 - Not Found specifically. SecureAuth Identity Platform requires Application Request Routing to have Enable proxy enabled.

Resolution 2:

To resolve this:

1. Open IIS Manager and select the server name.
2. Open Application Request Routing Cache, then in the Actions pane select Server Proxy Settings.
3. Under Proxy Setting, select the Enable proxy checkbox.
4. Click Apply, then reload the Admin Console.

Back to top

Symptom 4: Machine Key Mismatch or Incorrect Proxy Settings Between SecureAuth0 and the API (misleading "API is not enabled" error)

Applies to version 19.07.x and later.

The Admin Console shows a blank screen, hangs on 'Please Wait...' or recycles back to the Username Authentication Prompt, with DevTools showing a 403 or 500 error requesting https://localhost/httpproxy/api/v3/sysinfo/ping:

Navigating to that URL directly shows the actual response body:

Despite what the error says, this isn't actually about the API being disabled or missing an API Id/Key. Both causes below produce this exact same error.

Cause 1: Machine Key Mismatch

The Machine Key Validation Key and Decryption Key in SecureAuth0's token settings don't match the values in the API's own web.config.

Resolution 1:

To resolve this:

1. In the Admin Console, decrypt the Admin API.
2. Open D:\SecureAuth\Api\web.config and locate the machineKey element. Note its validationKey and decryptionKey values.
3. In the SecureAuth0 realm's token settings, replace the Validation Key and Decryption Key with the values from the API's web.config, then save.
4. Confirm you can now reach the New Experience UI, then re-encrypt the Admin API.
5. If this doesn't resolve it, check the rest of the Forms section for other mismatches between the two web.configs (for example, Forms Name) — any mismatched value there can produce the same misleading error.

Cause 2: Incorrect Proxy Settings on SecureAuth0's System Info Tab

Incorrect Proxy settings configured on SecureAuth0's System Info tab can also produce this same error.

Resolution 2:

To resolve this, confirm the Proxy settings on SecureAuth0's System Info tab are configured correctly for this environment.

Back to top

Symptom 5: Appliance Is Behind a Proxy and IIS ARR Is Not Chaining Through It

In an environment where internet access is only available through a proxy server, Internet Information Services (IIS)'s Application Request Routing (ARR) feature — which SecureAuth uses in a way similar to a proxy — needs to be configured to chain its own requests through that upstream proxy. If ARR is not configured to do this, it cannot reach the internet, and the Admin Console gets stuck on a blank white screen. Note that IIS ARR does not forward or proxy credentials, so the proxy being used must allow unauthenticated access from the appliance.

Resolution:

To resolve this:

1. Take a snapshot of the appliance.
2. In IIS Manager, click the server name, then open Application Request Routing Cache.
3. In the right-hand pane, click Server Proxy Settings.
4. Scroll down to Proxy Chain, enter the proxy server's address and port, then click Apply.
5. Confirm the proxy allows outbound access to the IP addresses required for SecureAuth Cloud Services. See the SecureAuth Cloud Services documentation for the current list.
6. Try the Admin Console again.

Back to top

Symptom 6: Outdated Newtonsoft.Json binding redirect after upgrading to 24.04

Applies to version 24.04.

After installing 24.04, the New Experience/SWAP dashboard shows "Please Wait..." and never proceeds. DevTools shows a 500 error for both https://localhost/httpproxy/api/v3/sysinfo/ping and https://localhost/httpproxy/api/v3/rbac_rules/accesscontrol. Navigating to either URL directly shows:

The D:\SecureAuth\Api\web.config file's binding redirect for Newtonsoft.Json still points at the version range 24.04's Admin API expects to have been updated.

Resolution:

There are two ways to fix it:

Option A — use the built-in Update Web Config tool:

1. Load https://localhost/SecureAuth0/Authorized/WebAdminSwap.aspx, then change the URL to https://localhost/SecureAuth0/Authorized/WebAdminStart.aspx.
2. In the Advanced Configuration screens, open the Tools dropdown and select Update Web Config.
3. Click Update and wait for it to complete.
4. Click Update Resource and wait for it to complete.

Option B — edit the binding redirect manually:

1. Decrypt the Admin API web.config using Advanced Settings.
2. In D:\SecureAuth\Api\web.config, find the Newtonsoft.Json <dependentAssembly> element.
3. Change its <bindingRedirect> from oldVersion="0.0.0.0-12.0.0.0" newVersion="12.0.0.0" to oldVersion="0.0.0.0-13.0.0.0" newVersion="13.0.0.0", then save.

Either option should resolve the dashboard hang.

 

Back to top

Symptom 7: A file under D:\SecureAuth\Api\bin is at the wrong version after an upgrade

Applies to all versions.

The Admin Console fails to load and cycles back to the Authentication page, even when accessed via localhost. DevTools shows a 500 error for both https://localhost/httpproxy/api/v3/sysinfo/ping and https://localhost/httpproxy/api/v3/rbac_rules/accesscontrol. Navigating to either URL directly shows a Could not load file or assembly error, and the AdminApiLog confirms it with a version mismatch:

System.IO.FileLoadException: Could not load file or assembly 'SA.Common.WebConfig, Version=2.1.92.0, Culture=neutral, PublicKeyToken=0caf08c1933e853d' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.
File name: 'SA.Common.WebConfig, Version=2.1.92.0, Culture=neutral, PublicKeyToken=0caf08c1933e853d'
 ---> System.IO.FileLoadException: Could not load file or assembly 'SA.Common.WebConfig, Version=2.1.91.0, Culture=neutral, PublicKeyToken=0caf08c1933e853d' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.
File name: 'SA.Common.WebConfig, Version=2.1.91.0, Culture=neutral, PublicKeyToken=0caf08c1933e853d'

A named file under D:\SecureAuth\Api\bin — in this example, SA.Common.WebConfig — is at a different version than Identity Platform expects. The log above shows exactly this: Identity Platform is looking for version 2.1.92, but the file actually installed is version 2.1.91. This is usually seen after an upgrade where that specific file was not upgraded correctly.

Resolution:

To resolve this:

1. Retrieve a copy of the affected file at the version Identity Platform expects.
2. Place it in D:\SecureAuth\Api\bin, replacing the mismatched version.
3. Reload the Admin Console.

Back to top

Symptom 8: .NET Framework 4.8 not installed (required for 24.04)

Applies to version 24.04.

The same "Please Wait..." hang, with 500 errors on sysinfo/ping and rbac_rules/accesscontrol in DevTools — but navigating to either URL directly shows a .NET Framework configuration error instead of a Newtonsoft.Json error:

.NET Framework 4.8 is the minimum version required for Identity Platform 24.04, and it isn't installed on this server.

Resolution:

To resolve this, install .NET Framework 4.8 and reboot the server(s) afterward.

 

Back to top

Symptom 9: Incorrect Proxy Config in globalSettings.config

The Admin Console shows "Please Wait..." and never proceeds, or cycles back to the sign-in page. DevTools shows a 500 error for sysinfo/ping, and opening the URL directly shows {"sysInfo":null,"status":"Failure","message":[]}.

The AdminApiLog shows:

Error while retrieving or refreshing Titan access_token. Cloud Response: Unauthorized-{"error":"invalid_client","errorMessage":"Client authentication failed (e.g., unknown client, no client authentication included, or unsupported authentication method). not_found"}

This is caused by the Proxy Config within D:\SecureAuth\globalSettings.config being incorrect and unable to be parsed correctly, so the appliance can't retrieve a Titan access token to reach SecureAuth's cloud services.

Resolution:

To resolve this, open D:\SecureAuth\globalSettings.config and correct the ProxyConfig section. The default Proxy settings should be:

"ProxyConfig": {
  "UseProxyServer": false,
  "ProxyAddress": "",
  "ProxyPort": 0,
  "ProxyUsername": "",
  "ProxyPassword": "",
  "ProxyUseDefaultCred": false
}

Back to top

Symptom 10: Missing Client Certificate on SecureAuth0

Applies to version 24.04 and later.

The Admin Console hangs at "Please Wait..." on a server where it previously loaded without issue. A network trace shows a 500 error specifically on https://localhost/httpproxy/api/v3/sysinfo/ping, with a response body of {"sysInfo":null,"status":"Failure","message":[]}. The AdminApiLog confirms this with:

System.NullReferenceException: Object reference not set to an instance of an object.
  at MFA.Utilities.TitanHelper.GetTitanGateway(String url)
  at MFA.Utilities.TitanHelper.GetCloudSysInfo(String titanUrl)
  at SecureAuth.Admin.BLL.Services.V3.SysInfoService.GetCloudSysInfo()
  at SecureAuth.Admin.BLL.Services.V3.SysInfoService.GetApplianceSysInfo()
  at SecureAuth.Admin.API.Controllers.API.V3.SysinfoV3Controller.GetSysInfo()

The Client Certificate in SecureAuth0's System Info tab is missing — a serial number may still be displayed there, but no certificate is actually selected. This is typically because the certificate wasn't carried over to a secondary server via FileSync, or the certificate previously used in this field was removed. Without it, the appliance can't reach the Titan cloud endpoint that sysinfo/ping depends on.

Resolution:

To resolve this, open SecureAuth0's System Info tab and select a valid Client Certificate.

 

Back to top

Symptom 11: Certificate Bound to Port 443 Doesn't Cover the Access Hostname

The browser blocks the Admin Console with a NET::ERR_CERT_COMMON_NAME_INVALID error, or refuses to load it at all because of a cached HTTP Strict Transport Security (HSTS) policy. The browser shows an error similar to:

"Your connection is not private... NET::ERR_CERT_COMMON_NAME_INVALID... You cannot visit <hostname> right now because the website uses HSTS."

This can happen with localhost, or with any other fully qualified domain name (FQDN) used to reach the appliance — for example, after changing the certificate bound to port 443 in IIS. Whichever hostname is actually typed in the browser's address bar, the underlying issue is always the same: that exact hostname is not present in the Subject or Subject Alternative Names (SAN) of the certificate currently bound to port 443.

Resolution:

To resolve this, add a binding for that hostname using a certificate whose Subject or SAN includes it:

1. Open IIS Manager and navigate to Default Web Site.
2. In the Actions pane, select Bindings, then click Add.
3. Set Type to https and Port to 443. For IP address, use [::1] if the hostname is localhost, or leave it as All Unassigned for another FQDN.
4. Under SSL certificate, select a SecureAuth certificate whose Subject or SAN includes that hostname.
5. Click OK, then test.

If the binding cannot be updated right away, the certificate warning can be bypassed again by clearing the browser's cached HSTS policy for that hostname:

6. In the browser, go to edge://net-internals/#hsts (Edge) or chrome://net-internals/#hsts (Chrome).
   
7. Under Delete domain security policies, enter that hostname (for example, localhost) in the Domain field and click Delete.
   

Back to top

Symptom 12: Missing or Incorrect .NET (Core) Version for the Dashboard

Applies to versions 22.02 and later.

Opening the New Experience Dashboard shows an error stating "ERROR Unable to load Dashboard Error: Request failed with status code 500", with related errors also visible in the browser's Developer Tools Console.

This is caused by a missing, or an incorrect version of, .NET (Core), or some of its components, on the appliance. See SecureAuth's Compatibility Guide for the .NET version required by each IdP version.

Resolution:

To resolve this:

1. Find out which version of .NET (Core) is installed. Either run the following in a PowerShell console:

(dir (Get-Command dotnet).Path.Replace('dotnet.exe', 'shared\Microsoft.NETCore.App')).Name

or check Add/Remove Programs.

2. Uninstall the current version of .NET (Core), if one is installed. It is important to uninstall the old version before installing the new one.
3. Go to the .NET download page, download the Hosting Bundle for the version required by your IdP version, and install it. This installs the required files and any missing .NET (Core) components.

The required .NET (Core) version by IdP version is:

• 19.07 to 21.04 -- .NET Core 2.1
• 22.02 to 22.12 -- .NET Core 3.1
• 23.07 -- .NET 6
• 24.04 -- .NET 8
• 26.2 and later -- .NET 10

Back to top

Symptom 13: Realm Folder Name Is Not in Upper Camel Case

Opening a realm in the Admin Console throws System.FormatException: Input string was not in a correct format., with a stack trace showing an InvalidCastException converting a realm folder name (for example, secureauth7) to type Integer, thrown from WebAdminMaster.BtnPopulateRealms_Click. This happens when a realm's folder under D:\SecureAuth is named entirely in lowercase instead of upper camel case -- the Admin Console expects the SecureAuth prefix's casing to match exactly when it parses the trailing realm number.

Resolution:

To resolve this:

1. Check the folder name for the affected realm(s) under D:\SecureAuth.
2. Rename any folder that is not in upper camel case to match the standard SecureAuth# pattern -- for example, rename secureauth7 to SecureAuth7.
3. Try the Admin Console again.

Back to top

Symptom 14: Application Directory / Physical Folder Count Mismatch

Opening the Web Admin UI throws System.NullReferenceException: Object reference not set to an instance of an object, with a stack trace showing the exception thrown from WebAdminMaster.Populate_InstanceList(). This happens when the number of SecureAuth{X} application directories registered in IIS does not match the number of physical SecureAuth{X} folders under D:\SecureAuth -- for example, after an application directory or physical folder was deleted manually without removing its counterpart.

Resolution:

To resolve this:

1. Compare the number of SecureAuth{X} application directories in IIS against the number of SecureAuth{X} physical folders under D:\SecureAuth, and reconcile them:
   • If there are more application directories than physical folders, either create the missing physical folders (by copying and renaming an existing one) or remove the extra application directories in IIS.
   • If there are more physical folders than application directories, either create the missing application directories in IIS or delete the extra physical folders.
2. For any application directory that is newly created, or that needs to be mapped to a different physical folder, right-click it in IIS, go to Manage Application -> Advanced Settings..., and set:
   • Application Pool: ASP.NET v4.0 (IIS 7.5) or .NET 4.5 (IIS 8)
   • Physical Path: D:\SecureAuth\SecureAuth{X} (matching the application directory's own {X})
   • Physical Path Credentials: leave blank
   • Physical Path Credentials Logon: ClearText
   • Preload Enabled: False
   • Virtual Path: /SecureAuth{X} (should be grayed out, and must match the Physical Path's {X})
   • Enabled Protocols: http
3. Run the Reset File Perms and Shares tool to ensure the correct permissions are set. This tool comes pre-installed on most SecureAuth IdP virtual machines, or log a call with SecureAuth Support for assistance.
4. Try the Web Admin UI again.

Back to top

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.