You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is less of a bug and more of a suggestion to include a PSA in the README to avoid the run-around I went through. I've found the following behaviors:
Wildcard certs do not appear to work. The logs in the container will not indicate anything awry, but clients will simply fail to connect.
Connecting to any hostname not specified in the cert does not appear to work. Clients simply fail to connect.
The most damning thing about this particular category of failure is how it appears. The client will give the "Failed to connect to server API" message. I was running the server in Kubernetes and this sent me on a wild goose-chase because that message appears to indicate the TCP port isn't forwarding traffic. There are a million different reasons that might happen, so it took a while to chase them all down.
The container logs don't indicate anything awry either. They indicate that the cert was loaded without issue:
[2024.10.04-19.40.31:517][ 0]LogServer: Display: Using user-provided Certificate Chain file '/config/gamefiles/FactoryGame/Certificates/cert_chain.pem' and Private Key file '/config/gamefiles/FactoryGame/Certificates/private_key.pem'
[2024.10.04-19.40.31:517][ 0]LogHttpServerModule: Starting all listeners...
[2024.10.04-19.40.31:517][ 0]LogHttpServerModule: All listeners started
[2024.10.04-19.40.31:519][ 0]LogServer: Display: Successfully loaded provided certificate chain file '/config/gamefiles/FactoryGame/Certificates/cert_chain.pem'
I went into this not knowing anything about the Satisfactory server protocols and ended up having to drop into Wireshark to figure out what the hell was going on. Thanks a ton for the API documentation@wolveix btw, I ended up using it to sanity check that the UDP API traffic was in fact working as expected. After verifying the UDP messages indicated no issues, I tried connecting to the TCP API manually with a node library and all looked good, which left me stumped.
After some more Wireshark comparison with a known-good server, I realized the Satisfactory game client just hangs up the TCP connection in the middle of the handshake when using a wildcard cert. There's no indication of this in the client AFAICT, but I believe whatever TLS library its using rejects connections that don't match strict hostname verification (e.g., certHostname == specifiedHostname).
Some caveat emptor messaging around TLS setup in the README would probably help others in the future!
The text was updated successfully, but these errors were encountered:
This is less of a bug and more of a suggestion to include a PSA in the README to avoid the run-around I went through. I've found the following behaviors:
The most damning thing about this particular category of failure is how it appears. The client will give the "Failed to connect to server API" message. I was running the server in Kubernetes and this sent me on a wild goose-chase because that message appears to indicate the TCP port isn't forwarding traffic. There are a million different reasons that might happen, so it took a while to chase them all down.
The container logs don't indicate anything awry either. They indicate that the cert was loaded without issue:
I went into this not knowing anything about the Satisfactory server protocols and ended up having to drop into Wireshark to figure out what the hell was going on. Thanks a ton for the API documentation @wolveix btw, I ended up using it to sanity check that the UDP API traffic was in fact working as expected. After verifying the UDP messages indicated no issues, I tried connecting to the TCP API manually with a node library and all looked good, which left me stumped.
After some more Wireshark comparison with a known-good server, I realized the Satisfactory game client just hangs up the TCP connection in the middle of the handshake when using a wildcard cert. There's no indication of this in the client AFAICT, but I believe whatever TLS library its using rejects connections that don't match strict hostname verification (e.g.,
certHostname == specifiedHostname
).Some caveat emptor messaging around TLS setup in the README would probably help others in the future!
The text was updated successfully, but these errors were encountered: