OpenVPN
Accentuated characters in certs filename do not work anymore with 2.7 RC2
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
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.
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.
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.
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
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.
