When Satisfactory asks you to trust a dedicated-server certificate, compare its fingerprint with the one reported by the server you intend to join. Get the expected value through the administrator or a console you already trust. Accepting the warning without that comparison skips the identity check the prompt is there to provide.
This desktop dedicated-server guide covers first trust and unexpected certificate changes. You need the correct server console or an owner who can check it. Do not reset the world or server settings to clear a warning.
A self-signed certificate is an identity decision#
The game's HTTPS management interface uses TLS. When no custom certificate is supplied, the server creates a self-signed certificate; the client asks for manual trust and remembers the accepted certificate for that server. That behaviour is described in the bundled API documentation.
The practical question is whether the certificate belongs to the intended instance. “Self-signed” does not by itself mean the traffic is unencrypted, and knowing the server's friendly name does not establish its identity.
Before trusting it, confirm the address, main port and intended server with the owner. Where the console displays a certificate fingerprint, compare the complete SHA256 value with the client prompt, including all characters rather than only the beginning. Use a separate trusted channel to obtain it. A value copied from the same unfamiliar prompt provides nothing independent to compare.
If the values match and the owner confirms the instance, accept the certificate and continue to server authentication. Keep the expected fingerprint with the instance record. Keep passwords and private keys out of public support posts.
Treat an unexpected replacement as a separate event#
A reinstall or deliberate certificate replacement can change its identity. Investigate an unexplained change before renewing trust.
Ask the administrator what changed. Verify that the address or DNS name still reaches the expected machine and that a second instance is not answering on the chosen port. Then compare the client value with the certificate currently used by that process through trusted host access. Check the server log around startup for certificate selection and related errors.
Only after confirming the new identity should you refresh that server's saved trust using the client's available controls. Removing and re-adding a server may remove stale client state, but it cannot prove that the replacement endpoint is legitimate. Do not make “delete and accept again” the first step.
If you cannot establish the expected fingerprint, leave the connection untrusted and ask the owner to resolve it. Changing the game password will not answer which machine supplied the certificate.
A visible banner does not prove the API works#
A community report describes a visible name and ping alongside API/fingerprint errors. Its resolution is unconfirmed, but the symptom shows why status alone is insufficient.
When there is no trust prompt or the API cannot be reached, collect the exact client message and time. Confirm that the client and server builds match, wait for an active save load to finish, and check the endpoint used by the client. Also check the host and client clocks when the error concerns certificate validity.
The default main port is 7777, with TCP used for the HTTPS API and UDP for game/query traffic. For 1.1 and later, reliable messaging also uses TCP, starting at 8888 by default. The developer's 1.1 patch notes explain that automatic allocation can choose a later reliable port; read the actual startup allocation rather than assuming 8888 was selected. An explicit -ReliablePort= pins that choice or causes initialization to fail if it is unavailable.
Check the actual listeners, firewall and forwarding for the configured instance. These transport checks address reachability. They do not authorize a different certificate. Conversely, a verified certificate does not establish that the gameplay connection will finish.
Browser trust and game trust are separate#
Opening the server's HTTPS address in a browser can expose a certificate warning too. Approving that browser exception is not the game's certificate-confirmation step. A successful browser connection only tests that browser's route to the HTTPS endpoint; it does not verify UDP gameplay or the reliable messaging path.
Keep ordinary certificate validation enabled in administration tools. Do not turn a temporary “ignore certificate errors” diagnostic into a permanent configuration or use it to send administrator credentials to an unverified endpoint. Record the exact TLS error before changing anything; a name mismatch, invalid date and unknown issuer require different investigations.
Custom certificates are an optional maintenance commitment#
If you need a certificate issued by a trusted authority, consult CommunityResources/DedicatedServerAPIDocs.md in the installed game version. The documented custom files are FactoryGame/Certificates/cert_chain.pem and FactoryGame/Certificates/private_key.pem, relative to the server installation. A certificate installed only on a separate website or proxy does not automatically become the certificate presented by the game server.
Plan the hostname players will use, private-key permissions, renewal delivery and a controlled restart before switching. Keep a recoverable configuration copy and recheck the identity afterward. A certificate from Let's Encrypt still needs the correct hostname and ongoing renewal; it is not required merely to use the default self-signed game workflow.
For several instances on your own infrastructure, centralized server management can make it easier to keep the instance record beside routine administration. Record the endpoint, certificate and authorized administrator.
Finish by verifying trust in the game, authenticating normally and actually loading the intended session. Repeat the identity check after a planned restart. Those results distinguish a resolved certificate warning from a connection that only reached the server banner.
