Hi everyone. New-ish to the BeyondTrust ecosystem, but I’ve been deep in the logs this week and hitting a wall. Hoping someone has seen this pattern.
We use certificate-based auth for a chunk of our jump servers. After a recent round of Windows Server OS patching (mostly 2022, some 2019), a subset of connections started failing. The error in the BeyondInsight logs points to a generic “authentication failure,” but the Windows Security logs on the target servers show a Schannel error 36887 — “The certificate received from the remote server has not validated correctly.”
Here’s the odd part: it’s not all servers, and it’s not all connections. It seems to fail when the connecting user’s certificate chain requires an intermediate CA that *is* present in the local machine store, but the validation path is somehow broken post-patch. If we manually import the intermediate cert into the user store on the BeyondTrust component server, it starts working again.
This feels like a change in how the TLS handshake is being handled or which certificate store is being referenced after the OS update. We’ve verified the root CAs are trusted, and the certificates themselves haven’t expired.
Has anyone else run into this since the latest patches? Specifically around Schannel validation changes? I’m trying to figure out if this is a Windows patch quirk we need to work around, or if there’s a specific BeyondTrust service (like the Privileged Access Service) that needs its store permissions or access rules reconfigured after these updates.
Any pointers on where to look next would be huge. The intermittent nature makes me think it’s a race condition or a store lookup order issue.
You've isolated the variable well - the manual import into the user store on the component server being a workaround is the critical clue. This points directly to a change in the default certificate store enumeration order or context used by Schannel after the security patches.
We've observed a similar pattern where patches, particularly those addressing CVE-2022-35826 or related TLS/SSL trust changes, can alter the chain building logic. The system may now be checking the issuing intermediate against the user context of the BeyondTrust service account before falling back to the Local Machine store, and failing if it's not found in that first location. It's not universal because it depends on whether the intermediate was deployed via GPO to the machine store or if the service account's personal store was ever populated.
Your temporary fix is correct, but for a scalable solution, you need to ensure the intermediate CA certificates are placed in the "Intermediate Certification Authorities" store for the *Computer Account* on every BeyondTrust server, not just the target jump servers. A group policy preference targeting those machines is the most reliable method.
Your point about the enumeration order is exactly what I've seen when troubleshooting RabbitMQ with mutual TLS after similar patches. The Schannel logic shift can be incredibly subtle; it's not just a store location change but often a timing or context change in how the chain is built during the initial handshake.
One nuance I'd add: even with the intermediate in the Computer Account's store, you might still hit issues if the BeyondTrust service is configured to run under a specific virtual account like `NT SERVICE`. In some locked-down environments post-patch, that virtual account's certificate store isolation can act differently than the traditional `LocalService`. It's why the GPO push is essential, but you also need to verify the service's actual security context at runtime.
A quick `certutil -store My` from the service account's context (via PsExec or a scheduled task) can confirm it actually sees the chain.
throughput first