After upgrading from 1.5.9 to either 1.5.12 or 1.5.14, STIG Manager returns "Error: Cannot connect to the Sign-in Service." This only affects new sessions to Keycloak.

[Zachary-Lemoine]

Good afternoon,

I'm dealing with a very strange issue. Previously, we attempted to upgrade our STIG Manager environment to the latest version, which at the time was 1.5.12. After doing so, we noted that new sessions could not be established from STIG Manager to Keycloak, and users received the "Error: Cannot connect to the Sign-in Service." noted above. We reverted back, but now that I have more time to troubleshoot this error (now appearing on 1.5.14), I've noticed that after logging into Keycloak via a separate SP / SAML application located in the same realm, I can take that same session and authenticate properly to STIG Manager.

STIG Manager (via Windows Binary), its underlying MySQL database, and the Nginx reverse proxy are all located on a single Windows Server 2022 server. The Keycloak IDP is located on another separate Windows Server 2022 server, behind another Nginx reverse proxy. I've followed the documentation, and in doing so I've disabled proxy_buffering globally (I'll limit to the correct endpoints after this isssue is resolved) on the STIG Man server, and I've enabled the iframe session reauth action. This is, of course, accompanied by an http header added on the Nginx server providing the Keycloak IDP. Below are my configurations (sanitized to the best of my ability):

stig-manager.bat:

set STIGMAN_CLASSIFICATION=CUI
set STIGMAN_OIDC_PROVIDER=https://sso.fqdn.mil/realms/ourorganization
set STIGMAN_CLIENT_OIDC_PROVIDER=https://sso.fqdn.mil/realms/ourorganization
set STIGMAN_DB_HOST=localhost
set STIGMAN_DB_PASSWORD=sanitizedpassword
set NODE_EXTRA_CA_CERTS=E:\\certs\\nipr_dod_ca.pem
set STIGMAN_JWT_NAME_CLAIM=displayName
set STIGMAN_JWT_PRIVILEGES_CLAIM=resource_access.stig-manager.roles
:: set STIGMAN_CLIENT_REAUTH_ACTION=reload
set STIGMAN_CLIENT_REAUTH_ACTION=iframe
:: set STIGMAN_CLIENT_STRICT_PKCE=false
set STIGMAN_LOG_LEVEL=4

nginx.conf (on STIG Man Server):

worker_processes  1;

events {
  worker_connections  4096;
}

http {
    server {
        listen                      443 ssl;
        server_name                 stigman.fqdn.mil;
        client_max_body_size        100M;

        ssl_protocols			TLSv1.2 TLSv1.3;
	ssl_ciphers			ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
        ssl_certificate			E:\\certs\\stigman.fqdn.pem;
        ssl_certificate_key		E:\\certs\\stigman.fqdn.key.pem;
        ssl_prefer_server_ciphers	on;

	add_header			Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
        proxy_set_header        	Host               $host;
        proxy_set_header        	X-Real-IP          $remote_addr;
        proxy_set_header        	X-Forwarded-For    $proxy_add_x_forwarded_for;
        proxy_set_header        	X-Forwarded-Host   $host;
        proxy_set_header        	X-Forwarded-Server $host;
        proxy_set_header        	X-Forwarded-Port   $server_port;
        proxy_set_header        	X-Forwarded-Proto  $scheme;
	proxy_buffering			off;

        location / {
            proxy_pass			http://localhost:54000/;
        }
    }

And now nginx.conf (on the Keycloak Server):

worker_processes  1;

events {
  worker_connections  4096;  ## Default: 1024
}

http {
    server {
        listen                      443 ssl;
        server_name                 sso.fqdn.mil;
        client_max_body_size        100M;
        
        ssl_certificate             E:\\Secrets\\sso.fqdn.crt.pem;
        ssl_certificate_key         E:\\Secrets\\sso.fqdn.key.pem;
        ssl_prefer_server_ciphers   on;
        ssl_client_certificate      E:\\Secrets\\nipr_dod_ca.pem;
        ssl_verify_client           optional;
        ssl_verify_depth            4;

        add_header                  Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
	add_header		    Content-Security-Policy "frame-ancestors 'self' https://stigman.fqdn.mil https://stigman;" always;
        server_tokens		    off;

        proxy_set_header        Host               $host;
        proxy_set_header        X-Real-IP          $remote_addr;
        proxy_set_header        X-Forwarded-For    $proxy_add_x_forwarded_for;
        proxy_set_header        X-Forwarded-Host   $host;
        proxy_set_header        X-Forwarded-Server $host;
        proxy_set_header        X-Forwarded-Port   $server_port;
        proxy_set_header        X-Forwarded-Proto  $scheme;
        proxy_set_header        ssl-client-cert    $ssl_client_escaped_cert;
        proxy_buffer_size       128k;
        proxy_buffers           4 256k;
        proxy_busy_buffers_size 256k;

	location /admin/ {
	    allow 127.0.0.1; # Localhost
	    deny all;
            proxy_pass              https://localhost:8443/admin/;
        }
	location /js/ {
            proxy_pass              https://localhost:8443/js/;
        }
	location /realms/ {
            proxy_pass              https://localhost:8443/realms/;
        }
	location /resources/ {
            proxy_pass              https://localhost:8443/resources/;
        }
	location / {
            deny all;
        }
    }
    map_hash_bucket_size 128;
}

Note that if we roll back to 1.5.9, the issue doesn't appear, and clients authenticate normally. Otherwise, following the upgrade, we encounter the issues here. If desired, I've taken an export of the traffic as har files via debug tools, and I'd be happy to email them to a .mil email address if someone is interested in assisting me with this. Otherwise, any information or assistance would be appreciated. Thank you!

[csmig]

We refactored the OIDC code in v1.5.10, so something around that is causing a local regression.

The new OIDC code uses a SharedWorker, whose console logs are more easily viewable with Firefox (Chrome requires an extra couple steps). Please access the web app using Firefox and open the DevTools to view the console. I suspect you're will see a message like this:

In this error message, we should see the URL the web app is requesting.

[cd-rite]

Hi @Zachary-Lemoine That message indicates the client can't reach the OIDC discovery endpoint. That endpoint should be reachable in your browser by going to the URL set by STIGMAN_CLIENT_OIDC_PROVIDER, followed by /.well-known/openid-configuration So that would be something like: https://sso.fqdn.mil/realms/ourorganization/.well-known/openid-configuration

If that works, it may be a CORS issue that only happens when the app tries to hit that endpoint, rather than you going directly to it in the browser.
In 1.5.10 we introduced a sharedWorker for oidc token handling, and it may be possible the browser is treating the worker a little different than the main app. In the console, you might see some errors mentioning Cross-Origin Request or Access-Control-Allow-Origin.
If you don't see it there, you might need to inspect the worker directly, which Dev Tools in Chrome does not let you do directly. You'll need to go to chrome://inspect/#workers in the browser and "inspect" the stigman-oidc-worker there.

In consult with claud.ai about the problem, it suggested adding the CORS headers to your keycloak nginx config
# Add CORS headers for /realms/ OIDC endpoints
add_header Access-Control-Allow-Origin "https://stigman.fqdn.mil" always;
add_header Access-Control-Allow-Methods "GET, POST, OPTIONS" always;
add_header Access-Control-Allow-Headers "Content-Type, Accept" always;

If the above doesn't illuminate any issues, you could send those files to the email found in our security policy:
https://github.com/NUWCDIVNPT/stig-manager/security/policy

[Zachary-Lemoine]

Good morning, and apologies for the delayed response. I attempted to add the headers, and it didn't appear to make a difference.

Referencing your instructions for inspecting worker states via Chrome, this is the error message I see in the chrome console:

oidc-worker.js:88 [OIDCWorker]: Failed to fetch OIDC configuration TypeError: Failed to fetch
    at fetchOpenIdConfiguration (oidc-worker.js:220:26)
    at initialize (oidc-worker.js:85:33)
    at MessagePort.onMessage (oidc-worker.js:118:32)
initialize @ oidc-worker.js:88

In Firefox, I instead receive the following:

I will immediately send the .har files after posting this.

[cd-rite]

Hi @Zachary-Lemoine Just to confirm, are you able to reach https://sso.fqdn.mil/realms/ourorganization/.well-known/openid-configuration from your browser?

[Zachary-Lemoine]

Thanks for the response. I'm able to access the url from the browser. The entire server stanza for Keycloak's NGINX server is configured with "SSL_CLIENT_VERIFY optional;". If I navigate to that endpoint, I'm prompted for certificate authentication. Whether I pass my credentials or not, the page will load correctly.

If I do pass my certificate, navigating to STIG Manager will result in a successful authentication. If I choose not to pass my credentials, navigating to STIG Manager once more will forward my traffic to the Keycloak's NGINX Server, and I'll receive a "400 Bad Request - No required SSL certificate was sent" error.

From STIGMan's point of view, when inspecting the worker, I see a "ERR_SSL_CLIENT_AUTH_CERT_NEEDED" error for the OIDC worker, as below:

[cd-rite]

Hi @Zachary-Lemoine Can you turn off ssl_verify_client for the .well-known endpoint? ie.

  location ~ ^/realms/.*/\.well-known/ {
      ssl_verify_client off;  
      # ... rest of proxy config
  }

It's usually not required for the .well-known/openid-configuration endpoint as it is advertising the options/config for authentication, not doing the auth itself.

[Zachary-Lemoine]

Good evening, Unfortunately, the 'ssl_verify_client' is not allowed within the location stanza. Attempting to do so presents me with an error from NGINX stating as such. I may need to look into migrating the configuration to Apache, as it appears to support this type of behavior based on some of the documentation I'm seeing.

…

On Fri, Oct 24, 2025 at 6:01 PM cd-rite ***@***.***> wrote: Hi @Zachary-Lemoine <https://github.com/Zachary-Lemoine> Can you turn off ssl_verify_client for the .well-known endpoint? ie. location ~ ^/realms/.*/\.well-known/ { ssl_verify_client off; # ... rest of proxy config } It's usually not required for the .well-known/openid-configuration endpoint as it is advertising the options/config for authentication, not doing the auth itself. — Reply to this email directly, view it on GitHub <#1801 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A7RGN74X62Q5HXYXWEMKMA33ZKOURAVCNFSM6AAAAACJ5PJBUKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTINZXG4YDKNQ> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[Zachary-Lemoine]

Okay, I was able to create a workaround for this by doing the following:

1 - On the Keycloak server itself, I allow port 8443 to be accessed by the STIG Manager Server, which grants direct access to the underlying instance of Keycloak to STIG Manager's reverse proxy.

2 - On the STIG Manager server's NGINX configuration, I've configured the NGINX Reverse Proxy to have an additional "/auth/realms/myorganization/.well-known/openid-configuration" location, which passes to the location specified above.

3 - Also on the STIG Manager server, I've updated the "STIGMAN_CLIENT_OIDC_PROVIDER" attribute from "sso.fqdn.mil/realms/myorganization" to "stigman.fqdn.mil/auth/realms/myorganization". The STIGMAN_OIDC_PROVIDER remains configured with sso.fqdn.mil/realms/myorganization

From here, the general client workflow appears to be the following:

1 - Client establishes (non-mutual) TLS authentication to STIG Manager

2 - Client requests OIDC configuration from stigman.fqdn.mil/auth/realms/myorganization/.well-known/openid-configuration

3 - Client is redirected to sso.fqdn.mil for authentication. Client is given the option to authenticate with a certificate for mTLS.

4 - Client selects their certificate, and they're able to log on. (Also validated that the reload iframe is working with this configuration)

This is opposed to the previous flow, which appeared to be the following:

1 - Client established (non-mutual) TLS authentication to STIG Manager

2 - Client requests OIDC configuration from sso.fqdn.mil/realms/myorganization/.well-known/openid-configuration

3 - The OIDC worker either fails to load altogether due to not being able to present a client certificate, or if it does load by dropping the cert (following SSL_VERIFY_CLIENT being disabled), the user is unable to authenticate at the auth endpoint.

Now, this is probably me making assumptions of my own, so please feel free to correct me (I'm not a web developer!). But, referencing the repository that provides the example configuration for CAC authentication, both the Keycloak Server and the STIG Manager server seem as if they're assumed to be on the same endpoint. To me, this would explain why others don't encounter this error, as mTLS is established upon connecting to STIG Manager initially. The client is then able to access the underlying ./.well-known url as well as the authorization url since the session is valid for both. Since I don't want clients to be given a certificate prompt to authenticate multiple times (Once for STIG Man, once for the SSO Server), I have mTLS disabled for STIG Manager, with the assumption that authentication will be done on the backend. This is obviously different than if they shared the same server, to which the initial mTLS session would be valid for both Keycloak and STIG Manager.

I suppose the next question would be, is there any way to preload the OIDC endpoint in an interactable way for the user, such that they'd be prompted to authenticate for the OIDC ./well-known url, which would also keep their mTLS session for the auth url? Between the popular web server providers, only Apache appears to support TLS Renegotiation, which would be a prerequisite for clients to connect unauthenticated to the configuration page, prior to authenticating to the protocols/auth page.

EDIT - Forwarding the location to port 8443 and modifying the server to proxy directly to Keycloak was unnecessary. I modified the new location block to reflect the existing server's standard URL. The NGINX proxy (STIGMAN) then correctly sends the request to the second NGINX Proxy (Keycloak), and it correctly fetches a valid OIDC configuration. Basically, step 1 for the workaround is ignored, and step 2 is modified to reflect the raw "sso.fqdn.mil/realms/...." versus "sso.fqdn.mil:8443/realms...." in the location block.

[cd-rite]

@Zachary-Lemoine Glad you found a workaround! We've merged PR:#1806, which moves the initial oidc-config fetch to the main thread (Check the PR for more details if interested).
If you want to try the new version with your original proxy config, this change is available in our :latest container on Docker Hub.

[csmig]

@Zachary-Lemoine We can workaround this issue by changing our code. I'll be opening a PR soon that aims to support your initial configuration having the OP and STIGMAN served from different origins and the OP always requesting a client cert.

We expected that Firefox handles this configuration without error. But you're seeing failures when using Firefox as well?

[csmig]

Opened #1806 to track work targeting this topic.