How to fix an invalid SSL certificate error on your MU Online server's site and launcher

An invalid SSL/TLS certificate error is one of the most visible (and most damaging to reputation) infrastructure problems an MU Online private server can face: the player opens the site to create an account or access the panel and gets a red "connection is not private" or "site not secure" warning. Besides scaring off new players, this can completely block registration in more restrictive browsers. This tutorial covers diagnosing the exact cause of the error, fixing it via certificate renewal/reissuance, and correctly configuring Nginx and Apache so it doesn't happen again.

How SSL/TLS works in practice on your server

When a player accesses https://yoursite.com, the browser expects to receive a valid digital certificate, issued by a recognized Certificate Authority (CA), that proves the domain is genuinely controlled by whoever it claims to be. The certificate has three elements that trigger an error if incorrect: validity (within the expiration period), domain (matching exactly what's being accessed, including www or not), and chain of trust (the CA's intermediate certificate is correctly installed on the server).

Diagnosing the exact type of error

Before blindly renewing a certificate, identify the exact message — each one points to a different cause:

Step 1 — Check the validity and details of the current certificate

In the browser, click the padlock (or the error warning) → "Certificate" to see the expiration date and the exact domain covered. Via terminal, it's faster and more reliable:

echo | openssl s_client -servername yoursite.com -connect yoursite.com:443 2>/dev/null | openssl x509 -noout -dates -subject

This returns the start/expiration date (notBefore/notAfter) and the subject (the domain the certificate was issued for). If the subject doesn't exactly match the accessed URL, that's the problem.

Step 2 — Fix an expired certificate with Let's Encrypt + Certbot

For servers running Nginx on Linux, renewal/issuance via Certbot is the most direct path:

sudo apt update && sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d yoursite.com -d www.yoursite.com

Certbot automatically detects Nginx's server blocks, issues the certificate, and adjusts the configuration to serve HTTPS. To make sure this doesn't expire again without warning, set up automatic renewal:

sudo systemctl enable certbot.timer
sudo systemctl start certbot.timer
sudo certbot renew --dry-run

The --dry-run flag simulates the renewal without actually applying it, confirming the automatic process will work when the certificate is close to expiring (Let's Encrypt auto-renews ~30 days before expiration).

Step 3 — Fix a mismatched domain (Common Name Invalid)

If the error is ERR_CERT_COMMON_NAME_INVALID, the certificate was issued only for one variation of the domain (e.g., only www.yoursite.com, but the player accesses yoursite.com without www, or vice versa). The fix is to reissue it including all necessary variations:

sudo certbot --nginx -d yoursite.com -d www.yoursite.com -d panel.yoursite.com

Alternatively, set up a permanent (301) redirect from the variant without a certificate to the one that has one, avoiding keeping multiple active domains unnecessarily.

Step 4 — Correctly install the intermediate chain (Apache)

On Apache servers, a common mistake is installing only the domain certificate (cert.pem) without the CA's intermediate certificate (chain.pem or fullchain.pem), producing ERR_CERT_AUTHORITY_INVALID even with a valid certificate. The correct VirtualHost configuration:

<VirtualHost *:443>
    ServerName yoursite.com
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/yoursite.com/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/yoursite.com/privkey.pem
    SSLCertificateChainFile /etc/letsencrypt/live/yoursite.com/chain.pem
</VirtualHost>

Using fullchain.pem (which already combines the certificate + chain) instead of separate cert.pem + chain.pem is the simpler, less error-prone approach on recent versions of Apache and Nginx.

Step 5 — Equivalent, more robust configuration in Nginx

server {
    listen 443 ssl http2;
    server_name yoursite.com www.yoursite.com;

    ssl_certificate     /etc/letsencrypt/live/yoursite.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yoursite.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}

server {
    listen 80;
    server_name yoursite.com www.yoursite.com;
    return 301 https://$host$request_uri;
}

The second block ensures any access via plain HTTP is automatically redirected to HTTPS, preventing the player from accidentally accessing the insecure version.

Step 6 — Fix mixed content

If the padlock shows "broken" even with a valid certificate, the issue is usually mixed content: the page is loaded over HTTPS, but references images, scripts, or fonts via explicit http://. The fix is to change all hardcoded absolute URLs in the HTML/CSS/JS to a relative protocol or explicit HTTPS:

<!-- Wrong -->
<script src="http://yoursite.com/assets/launcher.js"></script>

<!-- Correct -->
<script src="https://yoursite.com/assets/launcher.js"></script>

Tools like the browser's DevTools (Console/Security tab) list exactly which resources are being blocked as mixed content.

Step 7 — Cover the subdomains used by the launcher and API

If the launcher consumes an API at api.yoursite.com or panel.yoursite.com, each subdomain needs its own valid certificate (or a wildcard covering all of them). To simplify maintenance with multiple subdomains:

sudo certbot --nginx -d yoursite.com -d www.yoursite.com -d api.yoursite.com -d panel.yoursite.com

Or, for a wildcard (requires DNS validation, not HTTP):

sudo certbot certonly --manual --preferred-challenges dns -d "*.yoursite.com" -d yoursite.com

Continuous expiration monitoring

Don't rely on automatic renewal alone — set up an external alert. Free services like UptimeRobot, or a simple cron script that runs the openssl command from Step 1 weekly and sends an alert to the team's Discord if expiration is less than 15 days away, will prevent surprises.

Common errors and fixes

SSL/TLS health checklist

• Valid certificate with expiration date confirmed via openssl.
• Certificate domain covers all accessed variants (www and without www).
• Intermediate chain correctly installed (fullchain.pem).
• Automatic renewal configured and tested with --dry-run.
• HTTP → HTTPS redirection active on all domains.
• No mixed content (HTTP resources) on the page served over HTTPS.
• Launcher/API subdomains covered by a valid certificate.
• External expiration monitoring configured.

With the site's and launcher's SSL stabilized, it's worth reviewing your infrastructure's overall security — firewall, exposed ports, and database backups — to close off the most common gaps in a private server. If you haven't documented your server's foundation yet, start with the MU Online server creation guide.

Frequently asked questions