How to Add a Trusted SSL Certificate to a Satisfactory Dedicated Server
This guide explains how to generate and install a trusted SSL certificate for a Satisfactory dedicated server running on Linux.
This is especially useful for shared game hosting environments where server owners may not have access to ports 80 or 443, or where each game server only has a limited number of exposed ports.
What This Solves
By default, a Satisfactory dedicated server may use a self-signed certificate. This can cause certificate warnings when connecting to or managing the server.
Using a trusted SSL certificate from Let's Encrypt removes this issue and allows the server to present a valid certificate for its hostname.
Example Server Details
In this example, the Satisfactory server uses the following address:
play.gs1.eastgate.host:7777
The hostname is:
play.gs1.eastgate.host
The port is:
7777
The SSL certificate is issued for the hostname, not the port.
Recommended Certificate Type
For shared hosting, the recommended setup is to use a wildcard certificate.
For this hostname:
play.gs1.eastgate.host
The correct wildcard certificate would be:
*.gs1.eastgate.host
This wildcard certificate will cover hostnames such as:
play.gs1.eastgate.host server2.gs1.eastgate.host satisfactory123.gs1.eastgate.host
It will not cover:
gs1.eastgate.host play.server.gs1.eastgate.host play.gs2.eastgate.host
A wildcard certificate only covers one subdomain level.
Important Notes Before Starting
- You need a domain or subdomain. A trusted Let's Encrypt certificate cannot normally be issued for only an IP address.
- The hostname must point to the public IP address of the game server.
- The certificate can be generated on a different machine and then copied to the Satisfactory server.
- Port 80 and port 443 do not need to be open if DNS validation is used.
- For wildcard certificates, DNS validation is required.
Why DNS Validation Is Recommended
Let's Encrypt supports multiple validation methods. For game servers on shared hosting, DNS validation is the best option.
DNS validation works by creating a temporary TXT record in your DNS zone. This proves that you control the domain.
This means the certificate can be generated even if the Satisfactory server does not have ports 80 or 443 available.
Recommended Setup
The cleanest setup is:
Certificate provider: Let's Encrypt DNS provider: Cloudflare Validation method: DNS-01 Certificate type: Wildcard certificate
Cloudflare is used only for DNS validation. The actual certificate is issued by Let's Encrypt.
Do not use Cloudflare Origin Certificates for this. Cloudflare Origin Certificates are intended for Cloudflare-to-origin HTTPS traffic and are not normally trusted directly by game clients.
Step 1 - Install Certbot and Cloudflare DNS Plugin
On a Debian or Ubuntu machine, install Certbot and the Cloudflare DNS plugin:
sudo apt update sudo apt install certbot python3-certbot-dns-cloudflare -y
This machine does not have to be the same machine that hosts the Satisfactory server.
Step 2 - Create a Cloudflare API Token
Create a Cloudflare API token with permission to edit DNS records for your domain.
The token should have access to the DNS zone where the hostname exists. For example:
eastgate.host
The token needs permission to create and remove DNS TXT records for ACME validation.
Step 3 - Save the Cloudflare API Token
Create a directory for Certbot secrets:
mkdir -p /home/<username>/.secrets
Create the Cloudflare credentials file:
nano /home/<username>/.secrets/cloudflare.ini
Add the following content:
dns_cloudflare_api_token = YOUR_CLOUDFLARE_API_TOKEN
Replace YOUR_CLOUDFLARE_API_TOKEN with your actual Cloudflare API token.
Secure the file:
chmod 600 /home/<username>/.secrets/cloudflare.ini
Step 4 - Generate the Wildcard Certificate
Generate the wildcard certificate with DNS validation:
sudo certbot certonly \ --dns-cloudflare \ --dns-cloudflare-credentials /home/<username>/.secrets/cloudflare.ini \ -d "*.gs1.eastgate.host"
Important: do not request both of these in the same certificate:
play.gs1.eastgate.host *.gs1.eastgate.host
Let's Encrypt may reject this because play.gs1.eastgate.host is already covered by *.gs1.eastgate.host.
Step 5 - Check the Certificate
After the certificate is issued, check where Certbot saved it:
sudo certbot certificates
The certificate files are usually located in a path similar to:
/etc/letsencrypt/live/gs1.eastgate.host/fullchain.pem /etc/letsencrypt/live/gs1.eastgate.host/privkey.pem
The exact folder name may be different. Use the output from sudo certbot certificates to confirm the correct path.
Step 6 - Install the Certificate on the Satisfactory Server
Satisfactory expects the certificate files in the following directory:
FactoryGame/Certificates/
The certificate files should be named:
cert_chain.pem private_key.pem
Create the directory if it does not already exist:
mkdir -p /path/to/FactoryGame/Certificates
Copy the Let's Encrypt certificate files:
sudo cp -L /etc/letsencrypt/live/gs1.eastgate.host/fullchain.pem \ /path/to/FactoryGame/Certificates/cert_chain.pem sudo cp -L /etc/letsencrypt/live/gs1.eastgate.host/privkey.pem \ /path/to/FactoryGame/Certificates/private_key.pem
The -L option is important because Let's Encrypt files in the live directory are symbolic links.
Step 7 - Fix Permissions
Set safe permissions:
chmod 644 /path/to/FactoryGame/Certificates/cert_chain.pem chmod 600 /path/to/FactoryGame/Certificates/private_key.pem
If the Satisfactory server runs under a specific user, change ownership:
chown -R satisfactory:satisfactory /path/to/FactoryGame/Certificates
Replace satisfactory:satisfactory with the actual user and group used by your server.
On shared hosting panels such as Pterodactyl, the server may run under a container user. In that case, make sure the game server process can read the files.
Step 8 - Restart the Satisfactory Server
Restart the server after copying the certificate files.
If using systemd:
systemctl restart satisfactory
If using a game hosting panel, restart the server from the panel.
Step 9 - Test the Certificate
From another machine, test the server with OpenSSL:
openssl s_client -connect play.gs1.eastgate.host:7777 -servername play.gs1.eastgate.host -showcerts
A successful result should show:
subject=CN = *.gs1.eastgate.host issuer=C = US, O = Let's Encrypt Verification: OK Verify return code: 0 (ok)
The most important line is:
Verify return code: 0 (ok)
This confirms that:
- The server is presenting a trusted certificate.
- The certificate matches the hostname.
- The certificate chain is valid.
- The server is serving TLS correctly on the tested port.
Testing Another Server With the Same Wildcard Certificate
The same wildcard certificate can be used for another Satisfactory server if the hostname is still covered by the wildcard.
For example, this certificate:
*.gs1.eastgate.host
Can be used for:
play.gs1.eastgate.host:7777 server2.gs1.eastgate.host:7778 server3.gs1.eastgate.host:7779
Each server still needs its own port if multiple servers are hosted on the same IP address.
The certificate does not remove the need for unique port allocations.
Can the Certificate Be Generated on Another Machine?
Yes. When using DNS validation, the certificate can be generated on a different machine with a completely different IP address.
Example:
Machine A: Generates and renews the certificate Machine B: Runs the Satisfactory server
After generating the certificate on Machine A, copy these files to Machine B:
fullchain.pem privkey.pem
And place them on the Satisfactory server as:
FactoryGame/Certificates/cert_chain.pem FactoryGame/Certificates/private_key.pem
Automating Certificate Renewal
Let's Encrypt certificates expire after about 90 days. You should automate renewal and certificate deployment.
Create a deploy hook:
sudo nano /etc/letsencrypt/renewal-hooks/deploy/satisfactory-gs1.sh
Example deploy hook:
#!/bin/bash
LE_PATH="/etc/letsencrypt/live/gs1.eastgate.host"
SERVERS=(
"/path/to/server1"
"/path/to/server2"
"/path/to/server3"
)
for SERVER_PATH in "${SERVERS[@]}"; do
CERT_DIR="$SERVER_PATH/FactoryGame/Certificates"
mkdir -p "$CERT_DIR"
cp -L "$LE_PATH/fullchain.pem" "$CERT_DIR/cert_chain.pem"
cp -L "$LE_PATH/privkey.pem" "$CERT_DIR/private_key.pem"
chmod 644 "$CERT_DIR/cert_chain.pem"
chmod 600 "$CERT_DIR/private_key.pem"
done
# Optional: restart services here if needed
# systemctl restart satisfactory-1
# systemctl restart satisfactory-2
# systemctl restart satisfactory-3
Make the script executable:
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/satisfactory-gs1.sh
Test renewal:
sudo certbot renew --dry-run
Common Problems
The certificate works on one server but not another
Make sure the second server uses a hostname covered by the wildcard certificate.
For example, *.gs1.eastgate.host covers:
server2.gs1.eastgate.host
But it does not cover:
server2.gs2.eastgate.host abc.server2.gs1.eastgate.host
OpenSSL shows a self-signed certificate
The server is still using its default certificate. Check that the files were copied to the correct directory:
FactoryGame/Certificates/cert_chain.pem FactoryGame/Certificates/private_key.pem
Then restart the Satisfactory server.
OpenSSL shows "wrong version number"
You are probably testing a port that does not use TLS. Confirm which Satisfactory port is used for encrypted communication in your server configuration.
Connection refused
The port is not open, not forwarded, or the server is not listening on that port.
The certificate does not match the hostname
Make sure you connect using the hostname, not the raw IP address.
Correct:
play.gs1.eastgate.host:7777
Incorrect:
123.123.123.123:7777
Recommended Hosting Provider Setup
For shared game hosting, the recommended setup is:
Use one wildcard certificate per node or node group. Example: *.gs1.example.com *.gs2.example.com *.gs3.example.com
Then assign customers hostnames such as:
server001.gs1.example.com server002.gs1.example.com server003.gs1.example.com
This allows multiple Satisfactory servers to use the same wildcard certificate, while still keeping each server on its own allocated port.
Final Checklist
- The hostname points to the correct server IP.
- The wildcard certificate was issued successfully.
- The certificate files were copied to
FactoryGame/Certificates/. - The files are named
cert_chain.pemandprivate_key.pem. - The Satisfactory server can read both files.
- The server was restarted after installing the certificate.
openssl s_clientreturnsVerify return code: 0 (ok).
If all checks pass, the Satisfactory dedicated server is using a trusted SSL certificate correctly.
