[Bug 57063] New: Programs in Wine do not trust self-signed Root CA in system trust store
https://bugs.winehq.org/show_bug.cgi?id=57063
Bug ID: 57063 Summary: Programs in Wine do not trust self-signed Root CA in system trust store Product: Wine Version: 9.5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: asicosilomu@protonmail.com Distribution: ---
Created attachment 76926 --> https://bugs.winehq.org/attachment.cgi?id=76926 Output of curl https://rfdext.net under Linux and Wine.
I will keep this introduction short as it does not serve much of a purpose.
I am trying to get some old Roblox clients to work on my local server, and they insist on using HTTPS for the web APIs. I had modified them to use rfdext.net as the domain name, it and all relevant subdomains redirected to 127.0.0.1 in /etc/hosts.
I had issued a Root CA (with 274 years validity) to serve this purpose. Then, I used this Root CA to sign the webserver certificate (valid for just as long). The web certificate has rfdext.net, *.rfdext.net, localhost, *.localhost, 127.0.0.1 as the alternate names.
My setup consists of a PHP server on localhost:80, and socat listening on localhost:443 (using the web cert) redirecting all requests to localhost:80. I have also tried openssl s_server for testing the connection.
The actual issue is with getting the client to trust my CA.
I add the Root CA (rootca.crt, DER format) to the system trust store as you would on Fedora. Drop into /etc/pki/ca-trust/source/anchors and run update-ca-trust as root.
After a reboot, I can confirm it is trusted by the system. I can visit https://rfdext.net (as well as localhost) in Firefox without any security warnings. cURL on the command line does not complain either.
Trying the clients and... nothing. It appears as they are all unable to access the required endpoints. Downloading curl for Windows from curl.se and doing the same, and it complains about the Root CA being self-signed (see attachment 1). It appears as if programs running under Wine do not trust my CA. No amount of reboots fixed that.
The Root CA is listed in Control Panel > Internet Settings > Content > Certificates... > Trusted Root Certification Authorities (under Wine). Re-importing the certificate from that menu appears to succeed but is completely useless. Under Linux, the certificate exists in the standard location /etc/ssl/certs, as well as in /etc/ssl/certs/ca-certificates.crt and /etc/ssl/certs/ca-bundle.crt.
I am using Fedora 40 and Wine 9.5 (staging), which might be worth mentioning.
https://bugs.winehq.org/show_bug.cgi?id=57063
--- Comment #1 from asicosilomu@protonmail.com --- Oops, didn't expect „attachment 1” to become a link. Kinda new here.
This one should work: attachment 76926
https://bugs.winehq.org/show_bug.cgi?id=57063
--- Comment #2 from asicosilomu@protonmail.com --- Created attachment 76929 --> https://bugs.winehq.org/attachment.cgi?id=76929 cURL under Wine has no issues if the Root CA is specified manually.
cURL under Wine has no issues if the Root CA is specified manually. That won't help with the clients, though...
https://bugs.winehq.org/show_bug.cgi?id=57063
mata sutupud@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sutupud@yahoo.com
--- Comment #3 from mata sutupud@yahoo.com --- Are you sure that those clients actually use the system certificate store on windows? If they don't then they won't do so on wine either. A sign for that might be if they bring their own crypto libraries (something like ssleay.dll or similar in their program directory). They might load their certificates from somewhere else.
https://bugs.winehq.org/show_bug.cgi?id=57063
--- Comment #4 from mata sutupud@yahoo.com --- To add to the previous: curl for windows by default does not use the system certificate store, that's why it doesn't work. It can be made to use it using the `--native-ca` flag, or equivalent via config file.
https://bugs.winehq.org/show_bug.cgi?id=57063
--- Comment #5 from asicosilomu@protonmail.com --- (In reply to mata from comment #3)
Are you sure that those clients actually use the system certificate store on windows? If they don't then they won't do so on wine either. A sign for that might be if they bring their own crypto libraries (something like ssleay.dll or similar in their program directory). They might load their certificates from somewhere else.
I'll report back next time I'm at my computer. Maybe it was just me and Wine isn't at fault here, that would mean something else is making it not work.
I did think initially that the 274 years validity was an issue, but that seemed way too unlikely :)
https://bugs.winehq.org/show_bug.cgi?id=57063
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=57063
--- Comment #6 from asicosilomu@protonmail.com --- I am reporting again and it seems that something is definitely not working as intended. I regenerated both certificates with an expiry of 2029, in case the date was an issue.
Everything works fine under Linux, as always. I tried accessing the server using two browsers in Wine (Wine Internet Explorer and QtWeb) and they are experiencing similar difficulties. When tasked with the http url, both browsers load it fine.
When asked to go to https://rfdext.net or https://localhost, both browsers hang. IE appears to be doing nothing while QtWeb is stuck with a spinning loading indicator. No relevant messages in the terminal.
If I don't have the CA in system trust, they recognize that (disproving the original bug) and (sometimes) prompt a security warning. If I continue anyway, they both get stuck like before. I tried a clean wineprefix, using the openssl s_server, nothing would get these browsers to connect to my server over HTTPS.
These browsers probably use Win32 native APIs, which seem to be the point of failure. Installing Firefox for Windows (terrible idea, I know) in a clean wineprefix and navigating to https://rfdext.net works perfectly. Except, Firefox doesn't see my CA in system trust and gives me a security warning (possibly it doesn't use system trust by default?).
Maybe Wine's APIs are choking on my webserver cert for some reason? Or I'm missing something.
https://bugs.winehq.org/show_bug.cgi?id=57063
--- Comment #7 from asicosilomu@protonmail.com --- Created attachment 76936 --> https://bugs.winehq.org/attachment.cgi?id=76936 How I generated the Root CA and webserver certificate.
Maybe the certificates are the issue? I'm pretty sure I've done this part right, but maybe I screwed something up.
https://bugs.winehq.org/show_bug.cgi?id=57063
--- Comment #8 from Hans Leidekker hans@meelstraat.net --- (In reply to asicosilomu from comment #7)
Created attachment 76936 [details] How I generated the Root CA and webserver certificate.
Maybe the certificates are the issue? I'm pretty sure I've done this part right, but maybe I screwed something up.
Would you be able to add test for this in dlls/crypt32/tests/chain.c?
https://bugs.winehq.org/show_bug.cgi?id=57063
--- Comment #9 from asicosilomu@protonmail.com --- (In reply to Hans Leidekker from comment #8)
(In reply to asicosilomu from comment #7)
Created attachment 76936 [details] How I generated the Root CA and webserver certificate.
Maybe the certificates are the issue? I'm pretty sure I've done this part right, but maybe I screwed something up.
Would you be able to add test for this in dlls/crypt32/tests/chain.c?
I would probably first write a program that uses crypt32 directly, to see if it's causing the problem. If it doesn't like my certificate, I will definitely add a test for it.
The previous observations make sense as Firefox uses its own crypto libraries, while the other two browsers use crypt32 APIs I assume. I would have expected a relevant error message, exception or fixme from those browsers however.
Will report back once I figure out the cause.
-
WineHQ Bugzilla