ValveSoftware
Potential SSL certificate issue with Serious Sam VR: The Last Hope (465240) and SLR - Soldier (Proton 5.13+)
There's some noise in the feedback which makes it unclear if there's a regression in Proton or if it's a side effect from Proton being run in the Steam Linux Runtime - Soldier container environment which should be looked at from the runtime container's side. This issue report is specifically focusing on the latter possibility. All other feedback regarding Serious Sam VR: The Last Hope run with Proton should continue to be added to https://github.com/ValveSoftware/Proton/issues/2708.
Starting with https://github.com/ValveSoftware/Proton/issues/2708#issuecomment-973652716:
@kisak-valve commented on 2021-11-19T01:48:20:
Serious Sam Last Hope won't verify license
Issue transferred from https://github.com/ValveSoftware/SteamVR-for-Linux/issues/481. @pete777moen posted on 2021-11-19T01:42:13:
I am trying to load Serious Sam Last Hope, but I get the error message that the license verification can't be accessed. I have run many VR games like Saints and Sinners with no problem with my Index system. Here is a list of things that I have tried:
used 8.8.8.8, 8.8.4.4 as dns on computer
tried 8.8.8.8, 8.8.4.4 on router (not allowed)
2001:4860:4860::8888 and/or 2001:4860:4860::8844 IP6 tried
tried +gfxapi OGL launch option
tried proton version 6.3-7
tried various ways to start, desktop icon (unpacked direct x) normal, without VR on, etc.
SamTLH.log can't find
fire wall disabled, thought i could change it, but it was not on
Here is my system information: Computer and Steam Information.
Manufacturer: ASRock
Model: X399 Phantom Gaming 6
Form Factor: Desktop
No Touch Input Detected
SteamVR Version:\\t1.21.2 (1636664637)
SteamVR Date:\\t2021-11-11
Steam:\\tPublic
Steam Branch:\\tbeta
Steam AppID:\\t250820
Tracking:\\tlighthouse
OS:\\tLinux version 5.11.0-40-generic (buildd@lgw01-amd64-010) (gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #44~20.04.2-Ubuntu SMP Tue Oct 26 18:07:44 UTC 2021
OS Version:\\t0.0.0.0
Direct Mode Vendor:\\tUnknown
Direct Mode Version:\\t
Admin:\\tYes
AsyncReprojection:\\tEnabled
Performance drops:\\t20/1 6/2 2/3 2/4 553/614
Display Mode:\\tDirect Mode
</Report>
<Displays>
</Displays>
<Devices>
Device 1 - LHR-F65B100F Headset Index Valve
Device Path:\\t/devices/lighthouse/LHR-F65B100F
Best Alias:\\t/user/head
Firmware: \\t1623823641 WMBUILD-W64$@wmbuild-w64 2021-06-15 FPGA 538(2.26/9/2) BL 1555018600
Hardware Revision: \\tproduct 34 rev 21.65.9 lot 2000/0/0 0
Hardware Id: \\t0x22154109
Watchman Firmware: \\t1623823641 / 1623823641 (2021-06-15)
Watchman FPGA: \\t538 / 538 (2.26)
VRC Version: \\t1623823641 / 0 (2021-06-15)
Camera Firmware: \\tVersion not available.
VSync to Photons: \\t0.011375
Display Frequency:\\t90
User IPD (m):\\t0.07
Current Universe ID:\\t0
Previous Universe ID:\\t0
Dongle Version: \\t0ACC1BE8E3-RYB Version: 1553895605 / 1558748372 (2019-03-29) (Update necessary)
Dongle Version: \\tC250D258F1-LYM Version: 1553895605 / 1558748372 (2019-03-29) (Update necessary)
<Device1_Additional>
HMD Report:
.version = 2
Processor Information:
CPU Vendor: AuthenticAMD
CPU Brand: AMD Ryzen Threadripper 1900X 8-Core Processor
CPU Family: 0x17
CPU Model: 0x1
CPU Stepping: 0x1
CPU Type: 0x0
Speed: 3800 Mhz
16 logical processors
8 physical processors
HyperThreading: Supported
FCMOV: Supported
SSE2: Supported
SSE3: Supported
SSSE3: Supported
SSE4a: Supported
SSE41: Supported
SSE42: Supported
AES: Supported
AVX: Supported
AVX2: Supported
AVX512F: Unsupported
AVX512PF: Unsupported
AVX512ER: Unsupported
AVX512CD: Unsupported
AVX512VNNI: Unsupported
SHA: Supported
CMPXCHG16B: Supported
LAHF/SAHF: Supported
PrefetchW: Unsupported
Operating System Version:
Ubuntu 20.04.3 LTS (64 bit)
Kernel Name: Linux
Kernel Version: 5.11.0-40-generic
X Server Vendor: The X.Org Foundation
X Server Release: 12011000
X Window Manager: GNOME Shell
Steam Runtime Version: steam-runtime_0.20211102.0
Video Card:
Driver: NVIDIA Corporation GeForce RTX 2060/PCIe/SSE2
Driver Version: 4.6.0 NVIDIA 460.91.03
OpenGL Version: 4.6
Desktop Color Depth: 24 bits per pixel
Monitor Refresh Rate: 60 Hz
VendorID: 0x10de
DeviceID: 0x1e89
Revision Not Detected
Number of Monitors: 1
Number of Logical Video Cards: 1
Primary Display Resolution: 1920 x 1080
Desktop Resolution: 1920 x 1080
Primary Display Size: 34.88" x 19.61" (40.00" diag)
88.6cm x 49.8cm (101.6cm diag)
Primary Bus: PCI Express 16x
Primary VRAM: 6144 MB
Supported MSAA Modes: 2x 4x 8x 16x
Sound card:
Audio device: Realtek ALC1220
Memory:
RAM: 15855 MB
VR Hardware:
Headset: Valve Index (lighthouse)
Base station or sensor: HTC HTC V2-XD/XE (lighthouse)
Base station or sensor: HTC HTC V2-XD/XE (lighthouse)
Miscellaneous:
UI Language: English
LANG: en_US.UTF-8
Total Hard Disk Space Available: 227081 MB
Largest Free Hard Disk Block: 109659 MB
Storage:
Number of SSDs: 0
Number of HDDs: 0
<Unfilled SteamVR issue report template omitted>
@samualblair commented on 2022-03-06T19:36:45:
@pete777moen I have been having the same Licensing issues for, I think years now. I played this game a lot in VR (linux and windows) back when Proton 2, 3 and 4 were current.
After doing some troubleshooting I also confirmed that my network connectivity is fine, (in general may be borked in Proton) yet the DRM issue remained, in modern versions of proton.
On a hunch I tried proton 4.2, and it works no problem. Also proton 4.11 works no problem. Any newer versions i tested (5,6,7,experimental) and GE newer versions (6,7) all fail to connect to license servers.
Game logs indicate SSL failure, so maybe proton updated with a new ssl/tls library (or is missing a CA for validation or or something). But normal networking checks out as multiplayer works. maybe this is a more complex DRM issue.
@pete777moen commented on 2022-03-07T02:59:31:
Thank you. When I get a chance I will try it.
Peter Moen
@kisak-valve commented on 2022-03-07T13:07:52:
Hello @pete777moen, @samualblair, can one of you please add PROTON_LOG=1 %command% to the game's launch options, reproduce the regression, and attach the generated $HOME/steam-$APPID.log to this issue report as a file. (Proton logs compress well if needed.)
Also, it would be interesting to try running the game with Proton 4.11 once, then switch to Proton 5.0 add see if it keeps working as intended.
@samualblair commented on 2022-03-08T01:45:46:
proton_4.11-13_steam-465240.log proton_5.0-10_tempissue_after_container_change_steam-465240.log proton_5.0-10_worked_after_steam_restart_steam-465240.log proton_5.13-6_launched_after_steam_restart_but_regression_hit_steam-465240.log proton_5.13-6_tempissue_after_container_change_2_steam-465240.log proton_5.13-6_tempissue_after_container_change_steam-465240.log
@samualblair commented on 2022-03-08T01:49:07:
Logs of working 4.11-13 instance. Logs of actually working 5.0-10 instance, as noted in a couple logs when I switch proton versions right away the game won't launch, apparently this tricked me earlier into thinking 5.0-10 was broken. After exiting steam, and re-launching it works. My thought is something is hung/pending with the new proton container. Anyway it looks like 5.0-10 is good.
The breakage/regression seems to happen in 5.13-6. Again I attached a (well 2 logs) of the game not launching after proton change, but again after closing and re-opening steam that wasn't a problem. Now the game launches but the "unable to contact licensing server" issue is present.
Logs do show SSL connection failures start on 5.13-6, but SSL connections are good with 5.0 and 4.11
@samualblair commented on 2022-03-08T01:55:20:
Also just FYI, whenever closing it appears the game engine throws an crash/error page, but that seems to be occurring on any version of proton I've used and from what I can tell is harmless, generally steam kills the window before I look at it or bother. Might just make the end of the logs more messy.
@samualblair commented on 2022-03-08T02:01:54:
From what I can see in the logs when working (4.11-13 and 5.0-10) we have: ERR: LVE: 2351 INF: OpenSSL 1.1.0e 16 Feb 2017
And when Failing: ERR: LVE: 2351 ERR: LVE: 2352 - Failed to initialize SSL! Error: unknown certificate verification error ERR:
Hopefully there is some more information in there somewhere.
I don't have access to VR hardware or this specific game, but here is what is meant to be happening in this situation:
The Steam Linux Runtime - soldier container is heavily based on Debian 10, and in particular it has Debian 10's ca-certificates package, so /etc/ssl/certs is meant to contain all the same certificates that an ordinary Debian 10 installation would. As a result, any certificate verification that relies on the runtime's libraries (OpenSSL or GNUTLS) should give us the same result that would have happened on Debian 10.
I think Proton 5.13's Wine relies on a system copy of GNUTLS, which in our case means the one from Steam Linux Runtime - soldier, and therefore indirectly the one from Debian 10.
Proton 5.0 and older versions don't run in a container, which means they are using the OpenSSL or GNUTLS from your host operating system, together with whatever SSL/TLS certificates your host operating system has (which might be in /etc/ssl/certs like they are on Debian, or they might be in some other location). This means their behaviour might not match newer versions.
My guess would be that there's something odd going on in the SSL/TLS certificate verification, like maybe a missing intermediate certificate on the server, or a missing bug-fix in soldier's GNUTLS, or a missing workaround for non-standard server behaviour.
Do we know what server this game is trying to connect to for the licensing check?
Proton developers might perhaps know how to make it give more information about SSL/TLS interactions?
@pete777moen, @samualblair: What operating system are you using to run Steam?
It would be useful if you could attach or send the Help -> System Information from Steam, after waiting for collection to finish. That will tell us more about the libraries that Proton is trying to use.
More information: https://github.com/ValveSoftware/steam-runtime/blob/master/doc/reporting-steamlinuxruntime-bugs.md
Give me some time tonight and I will get some more details for you, I am very familiar with SSL/TLS and networking, somewhat familiar with container technology just not with steam/proton implementation.
I can say right now I am running current PopOS on my main rig (the one which generated these logs) but I have absolutely seen this on my other two systems. One runs Ubuntu, current. As the issue has been around for a while i can say that I have also experienced it over a couple versions of Ubuntu and PopOS (likely back as far as Ubuntu 19.10 at least).
I do have the reported server URL, I just need to dig it up. I can test with OpenSSL and also use a packet capture and confirm what cert(s) are being used.
Your explanation makes sense why the issue might persist. Is there a way to force injection of a trusted CA bundle at launch (or in the base container template)?
I can test with OpenSSL and also use a packet capture and confirm what cert(s) are being used
That would be very useful. I think Wine uses GNUTLS, so it would also be useful to get the equivalent with gnutls-cli: that's a closer comparison for what Proton/Wine will actually be doing.
somewhat familiar with container technology just not with steam/proton implementation
Oh, in that case: if it would help, you can fetch a SDK version of the runtime as an OCI container image suitable for Docker, Podman or Toolbx, by using the image name registry.gitlab.steamos.cloud/steamrt/soldier/sdk. This is a more complete environment used to compile and debug games (and Proton). Inside the container, if the openssl and gnutls-cli tools aren't already installed, you can install them with apt install openssl gnutls-bin like you would on an ordinary Debian/Ubuntu system.
When used one of those container frameworks, it won't be taking your graphics drivers from the host OS like the Steam container runtime does, and doesn't have the rest of the desktop integration stuff - so it's probably unsuitable for playing games, but extremely suitable for investigating what's wrong with TLS/SSL.
If Proton/Wine really uses GNUTLS (I'm reasonably sure it does), then I would hope it would have the same behaviour as gnutls-cli in the Docker/Podman/Toolbx container.
Is there a way to force injection of a trusted CA bundle at launch (or in the base container template)?
Not easily: the user-facing Steam Linux Runtime is set up to be as robust as possible for launching games, rather than to be easily hackable. If you can get a packet capture, or if you can reproduce the same thing talking to the same endpoint in Docker/Podman/Toolbx, then that would be a very useful step towards resolving this.
I have previously found (from forms) a support provided URL/URI to test with.
g83f81g8j8.execute-api.us-west-2.amazonaws.com
I was a little unsure at first if this was the correct URL/URI as it has no problems from my systems, but after a packet capture of the failure I do see the system making a DNS lookup that matches this hist.
Support provided request was to run the following code:
curl -H "Content-Type: application/json" -X POST -d "{\"request\": \"test\"}" "https://g83f81g8j8.execute-api.us-west-2.amazonaws.com/prod/ConnectionTest"
And obtain the following if working:
"success!"
During the packet capture I can find the DNS lookup to the expected AP server host, and DNS returns the expected IPs. After that I do not see any traffic from the client the API server. Seems as if that the game/application is simply failing to make the actual TLS connection attempt at all.
Queries
g83f81g8j8.execute-api.us-west-2.amazonaws.com: type A, class IN
Answers
g83f81g8j8.execute-api.us-west-2.amazonaws.com: type A, class IN, addr 99.84.66.5
g83f81g8j8.execute-api.us-west-2.amazonaws.com: type A, class IN, addr 99.84.66.8
g83f81g8j8.execute-api.us-west-2.amazonaws.com: type A, class IN, addr 99.84.66.102
g83f81g8j8.execute-api.us-west-2.amazonaws.com: type A, class IN, addr 99.84.66.22
Although that was the only relevant information I could parse out, the overall capture (about 60sec) was 500mb , as Steam appears to have been grabbing/sending status updates, obtaining feeds, reporting crashes, etc. If you believe it would be helpful I can try and share the whole capture, but I didn't see anything that looked useful outside of the DNS request that then had no follow up traffic (no followup seen to any of the 99.84.66.[5,8,102,22] addresses.
I have not obtained a working capture yet for comparison.
EDIT: I should note that not only did I not see any traffic to those IP's after the DNS lookup in the packet capture, but my firewall (set to log everything) also matched what I saw in the TCPDUMP PCAP. This lends me to be more confident that I didn't just miss the capture. I also wasn't filtering the capture down, which is why is the capture was so large so quickly. Still I am not apposed to performing more captures if needed.
I was able to test within the Soldier Container, running in Podman. Overall results were very similar to outside of the Container running on another system.
Overall looked very similar, files are attached for review. All of my tests worked (with the API test at least).
You can recreate with:
gnutls-cli --crlf g83f81g8j8.execute-api.us-west-2.amazonaws.com
POST /prod/ConnectionTest HTTP/1.1
Host: g83f81g8j8.execute-api.us-west-2.amazonaws.com
Content-Type: application/json
Content-Length: 19
{"request": "test"}
Or
openssl s_client -showcerts -crlf -connect g83f81g8j8.execute-api.us-west-2.amazonaws.com:443 -servername g83f81g8j8.execute-api.us-west-2.amazonaws.com
POST /prod/ConnectionTest HTTP/1.1
Host: g83f81g8j8.execute-api.us-west-2.amazonaws.com
Content-Type: application/json
Content-Length: 19
{"request": "test"}
@smcv
All of these tests to the API server were successful. Overall cert information looked pretty similar to me.
gnutls-cli_test_on_macos.txt gnutls-cli_test_in_fedora_podman_soldier.txt openssl_test_in_fedora_podman_soldier.txt openssl_test_on_macos.txt system_dns_lookup_nslookup.txt
Support provided request was to run the following code:
curl -H "Content-Type: application/json" -X POST -d "{\"request\": \"test\"}" "https://g83f81g8j8.execute-api.us-west-2.amazonaws.com/prod/ConnectionTest"And obtain the following if working:"success!"
This works for me, although the Steam Runtime's curl is linked to OpenSSL and Proton uses GNUTLS, so there might be some subtleties of behaviour that are different - I haven't tried gnutls-cli yet.
To make sure I'm not hitting a subtle difference between the podman and Steam Linux Runtime environment, I'm using the Steam Linux Runtime:
/path/to/steamapps/common/SteamLinuxRuntime_soldier/run -- xterm
This container environment should be equivalent to how we run Proton.
Similarly, I can connect an OpenSSL client to that endpoint successfully:
$ ~/SteamLibrary/steamapps/common/SteamLinuxRuntime_soldier/run --devel -- openssl s_client -connect g83f81g8j8.execute-api.us-west-2.amazonaws.com:443
CONNECTED(00000003)
depth=2 C = US, O = Amazon, CN = Amazon Root CA 1
verify return:1
depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
verify return:1
depth=0 CN = *.execute-api.us-west-2.amazonaws.com
verify return:1
---
Certificate chain
0 s:CN = *.execute-api.us-west-2.amazonaws.com
i:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
1 s:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
i:C = US, O = Amazon, CN = Amazon Root CA 1
2 s:C = US, O = Amazon, CN = Amazon Root CA 1
i:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2
3 s:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2
i:C = US, O = "Starfield Technologies, Inc.", OU = Starfield Class 2 Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIF/jCCBOagAwIBAgIQBCfSriCZ5v8GQZffsI/96DANBgkqhkiG9w0BAQsFADBG
MQswCQYDVQQGEwJVUzEPMA0GA1UEChMGQW1hem9uMRUwEwYDVQQLEwxTZXJ2ZXIg
Q0EgMUIxDzANBgNVBAMTBkFtYXpvbjAeFw0yMTA4MTIwMDAwMDBaFw0yMjA5MTAy
MzU5NTlaMDAxLjAsBgNVBAMMJSouZXhlY3V0ZS1hcGkudXMtd2VzdC0yLmFtYXpv
bmF3cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZdt3mpL3q
7wYCJrwPjg1IVuXEqdhPg7k6wBJKN51Xsi4nej2qkHou/Y5vcFtys+izYVk1Zllx
rjz9z+zz/xXIgH3WBTDKoDlP3dBR1cz0qd6/dEHfMiODC6p1hvDtOeGOlj1Cly5h
6nxxc7R7smSj7/G6GvCitD9t3TaoGBoI+dCjILNyn/xksAzipm27aAa96YDYBFXG
Cb2oehW45juEhwf+NY05wncG0D379Pm5n8otj9Fn8Ibhsz2AaGH3SY5dHTlV8H01
ZRbQ4X2j47sd5Tp7H5Iq1duiHolYCxV9J+XYcsnsUWoIF+oCN5EDikNuHoZHX6Hn
+9RdxgoCuGoTAgMBAAGjggL8MIIC+DAfBgNVHSMEGDAWgBRZpGYGUqB7lZI8o5QH
J5Z0W/k90DAdBgNVHQ4EFgQUiXaMrgKgc1dvqYijoHx6p9SeJUgwMAYDVR0RBCkw
J4IlKi5leGVjdXRlLWFwaS51cy13ZXN0LTIuYW1hem9uYXdzLmNvbTAOBgNVHQ8B
Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMDsGA1UdHwQ0
MDIwMKAuoCyGKmh0dHA6Ly9jcmwuc2NhMWIuYW1hem9udHJ1c3QuY29tL3NjYTFi
LmNybDATBgNVHSAEDDAKMAgGBmeBDAECATB1BggrBgEFBQcBAQRpMGcwLQYIKwYB
BQUHMAGGIWh0dHA6Ly9vY3NwLnNjYTFiLmFtYXpvbnRydXN0LmNvbTA2BggrBgEF
BQcwAoYqaHR0cDovL2NydC5zY2ExYi5hbWF6b250cnVzdC5jb20vc2NhMWIuY3J0
MAwGA1UdEwEB/wQCMAAwggF8BgorBgEEAdZ5AgQCBIIBbASCAWgBZgB1ACl5vvCe
OTkh8FZzn2Old+W+V32cYAr4+U1dJlwlXceEAAABezigqJIAAAQDAEYwRAIgX7mQ
mIWjC7aqPTsMgFFOnE1aoi7+7eGW9574B4i7xmsCIHX6pP1dDrkbHqC4AkpA7nCx
lNnnMrk2dqHYYRB9dL3SAHYAUaOw9f0BeZxWbbg3eI8MpHrMGyfL956IQpoN/tSL
BeUAAAF7OKCofAAABAMARzBFAiEAuqtMAk1BIrcdcoIX900KT6U74AyFy235QFHV
geiKFc0CIHAwkXz11on7Mz7eszJ4hkN9Hktost7DRAi4/8Wgknv8AHUAQcjKsd8i
RkoQxqE6CUKHXk4xixsD6+tLx2jwkGKWBvYAAAF7OKCoGQAABAMARjBEAiBLQMW+
49EtAKX2SqOybRMMcsWGo5j8WkLcGuve5gmW3QIgB2OUvbJdMro+ySpi0cyLmX/9
Uk9SmQScAn34Nq6l7NIwDQYJKoZIhvcNAQELBQADggEBACKG+xe1RNvsYxzIZPSE
7uDrvebfZKAC+hBorFPdAlo294gT+iUG6yKAFPo1HHmvG8qperXyRpi2p1FPjTBB
5pEGE2Gq1S1uduA3o7LgpKyeUfZcd1t30FO+BcicZzNpWDGmg4oNfnQLbykQu4M0
hJI7PdTDQyqDtBgyxDtHO264dg8BZLYrJgzGVpfirjtVa/bG8tzl0/V5fxgKn+N9
ByAtStfQBAILMkCE3O93mCzlo4Hx8B7eQ6NQrGThtAJ/k39yDFQ+aR/O1nQhJX4a
xH5tVVDJvHvDgar8cR/FmHJj6UZ05jw20iPpfMBEGF2BtWLt2dGhcOS8cJ7enocz
mVA=
-----END CERTIFICATE-----
subject=CN = *.execute-api.us-west-2.amazonaws.com
issuer=C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 5517 bytes and written 402 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
DONE
The container's /etc/ssl/certs seems to have both Amazon and Starfield CAs, so we should be OK there too.
I think this might need to be handed over to a Proton developer who is familiar with how Proton uses the system CA trust store to emulate Windows' equivalent. The game log says OpenSSL 1.1.0e, which is not a version that we ship, so I think this must be a copy of OpenSSL-for-Windows that is included in the game, using whatever Windows' mechanism is for deciding which CAs are trusted.
For anyone else wanting to test/reproduce in game, if you have a system without VR attached (or working) I found you can still launch this game with the options (at least in windows, I haven't tried with Proton yet).
+vr_strAPI "Emulated"
That way it will launch the game on normal screen, and the failure (if it is going to occur) will be observable, during the loading screen and before the intro cinematic. No need for any input or viewpoint change to replicate. I used this to test on an older windows system I had (didn't support my Index HMD) and was able to reproduce success.
Doesn't help with not owning the game sadly.
@smcv ,
As you previously asked for system information it is attached below. In addition there are fresh Steam Container and Proton Logs during a failure.
STEAM_LOG_slr-app465240-t20220310T113303.log PROTON_LOG_steam-465240.log
This is my main system right now , PopOS. I have two other Ubuntu systems (both running 21.10 right now) that have similar issues, varying hardware.
Edit: Attached for easier viewing sysinfo.txt
Thanks, that confirms that the container is correctly using soldier's OpenSSL, GNUTLS and libcurl rather than the ones from your host system (which is what I expected, but it's good to rule out sources of possible weirdness).