Accentuated characters in certs filename do not work anymore with 2.7 RC2

[Freeben666]

Describe the bug
I've encountered a bug with the OpenVPN GUI client v2.7 RC2 on Windows : our .ovpn config files don't include the cert, but refer to another file : cert User.crt . Same for the *.pem file.

My cert file is named Firstname_Lastname.crt, problem is, my first name has a "special" character (not that special here in France) : Benoît. Leading to the following error :

2025-11-28 08:44:22 OpenSSL: error:80000002:system library::No such file or directory:calling stat(Benoît_Xxx.crt)
2025-11-28 08:44:22 MANAGEMENT: Client disconnected
2025-11-28 08:44:22 Cannot load certificate from URI <Benoît_Xxx.crt>
2025-11-28 08:44:22 Exiting due to fatal error

I know special characters in filenames are bad practice, but it worked previously with v2.6

Removing that î from the filename solved the issue.

To Reproduce
Use a certificate file with special characters in its name

Expected behavior
Should work fine, like in v2.6

Version information (please complete the following information):

• OS: Windows 11
• OpenVPN version: 2.7 RC2

[cron2]

Does it work with current 2.6? This might be an OpenSSL issue (more recent OpenSSLs are much stricter in many regards) or something in our "load certs from URIs" code - which is new in 2.7

I can't promise we'll be able to fix this... non-ascii characters are a horrible can of worms.

[Freeben666]

The previous version of OpenVPN GUI, with which it worked, was v2.6.15. So yes, maybe the problem lies with OpenSSL 3.6. I won't be able to test this right now.

I'd understand if this does not get fixed, I'm aware "special" characters in filenames are a bad practice. Just thought I'd let you know so you could at least add the info in the release notes.

[Freeben666]

A colleague (named Loïc, so he also encountered this issue) told me it worked when he uninstalled v2.7RC2 and grabbed the latest v2.6 from the official website, which I assume was v2.6.16. Which would mean the issue does not lie with OpenSSL 3.6.0.

[cron2]

ok, thanks for the reports. So it's the "load certs from URI" stuff that is the most likely suspect - I'll ping @selvanair as he might have suggestions how to fix or workaround this

[selvanair]

Indeed this appears to be caused by the change to treat "--cert" and "--key" option values as URIs. Internally files are still opened using BIO_new_file() by OpenSSL. And, that works with UTF-8 filenames that we pass in. But, the file-store provider also does a stat() on the file which on Windows would assume the file name to be in the current code-page.

Setting the system-wide codepage to UTF-8 will fix this error (available as a beta feature on Windows 10 and 11), but that may not be a viable solution for all users. I'll ask openssl folks for some guidance. Otherwise, we could work around this using the store management functions only for non-file URI's.

[cron2]

@Freeben666 can you confirm that it works with 2.7_rc4, and if yes, please close the issue?

[Freeben666]

@Freeben666 can you confirm that it works with 2.7_rc4, and if yes, please close the issue?

I'll be able to test this in a few days (I'm away for the holidays).

[Freeben666]

Seems to be working fine now (2.7 RC4), even with special characters in filenames 👍

Thank you !