Windows agent with some locales cannot do proper security check

We have faced with ovpnagent problem. In some cases Windows paths of client and server differ. It leads to server rejecting client connection via named pipe. I double checked source code and found nothing suspicious, but after adding additional logging we've found this:

Thu Feb 22 16:13:38 2024 C:\Program Files\OpenVPN\bin\service.exe not recognized as a valid client
Thu Feb 22 16:13:38 2024 exception in handle_accept: http_server_exception: client socket rejected
Thu Feb 22 16:13:41 2024 connection from C:\Program Files\OpenVPN\bin\service.exe
Thu Feb 22 16:13:41 2024 normalized client exe path: c:\Program Files\OpenVPN\bin
Thu Feb 22 16:13:41 2024 normalized server exe path: c:\program files\openvpn\bin

As you can imagine check compares paths and fails.

We have found that it was users who have English localization instead of Russian (as many others in our case). Probably it's easy to fix but converting both paths to lower case, but I am not it's good from security point.

Start by tracing the Windows named-pipe connection handling in the source code, focusing on executable-path normalization and the client validation that emits these log messages. Reproduce the mismatch across Windows locales and review the existing security checks. Done means legitimate clients with equivalent paths are accepted without weakening executable validation, with relevant tests or logging confirming the behavior.