How to automate SSL certificate renewal for your MU Online server's website
Set up Certbot with Let's Encrypt to automatically renew the SSL certificate for your MU Online server's website, account panel, and store, avoiding HTTPS outages and insecure-site warnings.
An expired SSL certificate is one of the most avoidable — and most damaging to your image — incidents a MU Online server can suffer: overnight, the website, account panel, and store start showing "insecure connection" in the browser, driving players away and blocking payments. The cause is almost al
An expired SSL certificate is one of the most avoidable — and most damaging to your image — incidents a MU Online server can suffer: overnight, the website, account panel, and store start showing "insecure connection" in the browser, driving players away and blocking payments. The cause is almost always the same: the certificate was issued manually once and nobody set up automatic renewal. This tutorial shows how to use Certbot with Let's Encrypt to issue and automatically renew certificates, covering Nginx, Apache, and the Windows/IIS alternative, plus the tests and alerts that guarantee this never becomes a problem again.
Why HTTPS is mandatory for the server's website
Besides the padlock icon in the browser, HTTPS protects login credentials, item store payment data, and session cookies from interception. Modern browsers (Chrome, Firefox, Edge) aggressively block or warn about sites without HTTPS, and search engines penalize the ranking of pages without a valid certificate — for a server that relies on organic promotion, this has a direct impact on new signups.
Understanding the Let's Encrypt certificate lifecycle
Unlike traditional commercial certificates (which can last 1 to 2 years), Let's Encrypt certificates are valid for 90 days, by design — this reduces the risk of misuse of forgotten certificates and forces automation to exist. Let's Encrypt's own expectation is that renewal is automatic; renewing manually every 3 months is exactly the kind of task any team eventually forgets.
| Milestone | Expected action |
|---|---|
| Day 0 | Certificate issued |
| Day 60 | Certbot already attempts automatic renewal (30 days before expiry) |
| Day 90 | Expiration — should never be reached without prior renewal |
Installing Certbot on the server (Linux + Nginx)
On Debian/Ubuntu-based distributions, installing via snap is officially recommended to keep Certbot always up to date:
sudo apt update
sudo apt install -y snapd
sudo snap install core; sudo snap refresh core
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbotIssuing the certificate for the server's domain
With Nginx already configured and responding on port 80 for the domain (e.g., myserver.com and www.myserver.com), issuance is interactive and also handles the HTTPS block configuration:
sudo certbot --nginx -d myserver.com -d www.myserver.com -d store.myserver.comCertbot detects the existing server blocks in Nginx, automatically adds the listen 443 ssl directives and certificate file paths, and offers to redirect all HTTP traffic to HTTPS — accept that option, it's best practice.
Equivalent configuration for Apache
If the server's website runs on Apache instead of Nginx, the corresponding plugin follows the same logic:
sudo apt install -y python3-certbot-apache
sudo certbot --apache -d myserver.com -d www.myserver.comVerifying automatic renewal (systemd timer)
Modern Certbot installations already register a systemd timer that runs twice a day checking certificates close to expiring. Confirm it's active:
systemctl status certbot.timer
sudo certbot renew --dry-runThe --dry-run simulates the full renewal process without actually replacing the certificate — if it finishes without errors, automation is working correctly.
Alternative via cron (systems without a systemd timer)
On older environments where the timer isn't installed automatically, add the cron entry manually:
0 3,15 * * * /usr/bin/certbot renew --quiet --deploy-hook "systemctl reload nginx"Running twice a day (3 AM and 3 PM) is the practice recommended by Let's Encrypt's own documentation, as it distributes load across validation servers and increases the chance of success even if one attempt fails due to momentary network instability.
The deploy hook: reloading the web server without downtime
The --deploy-hook flag runs a command only when renewal actually happens (not on every check), ensuring the new certificate loads without needing to take the site down:
sudo certbot renew --deploy-hook "systemctl reload nginx"A reload (not restart) is enough for Nginx/Apache to load the new certificate while keeping existing connections active — the player browsing the site notices nothing.
Wildcard certificate for subdomains (panel, store, forum)
MU servers usually have several subdomains (panel., store., forum., api.). Instead of issuing one certificate per subdomain, a wildcard certificate (*.myserver.com) covers all of them at once, but requires DNS validation (TXT record) instead of HTTP:
sudo certbot certonly --manual --preferred-challenges dns \
-d myserver.com -d "*.myserver.com"To fully automate the wildcard (without manual intervention on every renewal), use a DNS plugin specific to your provider (Cloudflare, Route53, etc.), which inserts and removes the TXT record automatically via API.
Automating the wildcard with Cloudflare (example)
If the server's domain is on Cloudflare, the certbot-dns-cloudflare plugin eliminates the manual DNS challenge step:
sudo apt install -y python3-certbot-dns-cloudflare# /etc/letsencrypt/cloudflare.ini
dns_cloudflare_api_token = YOUR_TOKEN_HEREchmod 600 /etc/letsencrypt/cloudflare.ini
sudo certbot certonly --dns-cloudflare \
--dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
-d myserver.com -d "*.myserver.com"With this, even the wildcard certificate renews on its own via the systemd timer, with no manual clicks every 90 days.
Alerting before expiration (extra layer of safety)
Even with automation, it's wise to have an independent alert monitoring the certificate's actual expiration date in production, in case renewal silently fails for any reason (rate limit, DNS outage, etc.):
DAYS_LEFT=$(echo | openssl s_client -servername myserver.com -connect myserver.com:443 2>/dev/null | \
openssl x509 -noout -enddate | cut -d= -f2 | xargs -I{} date -d {} +%s | \
xargs -I{} echo "(({} - $(date +%s)) / 86400)" | bc)
if [ "$DAYS_LEFT" -lt 15 ]; then
curl -s -X POST "$DISCORD_WEBHOOK_URL" -H "Content-Type: application/json" \
-d "{\"content\":\"⚠️ SSL certificate expires in $DAYS_LEFT days!\"}"
fiCommon errors and fixes
| Symptom | Likely cause | Fix |
|---|---|---|
| Browser shows "insecure connection" | Certificate expired without renewal | Run certbot renew manually and investigate why automation failed |
certbot renew --dry-run fails | Port 80 blocked by firewall | Open port 80 for the Let's Encrypt HTTP-01 challenge |
| Wildcard renewal doesn't automate | Manual DNS validation without an API plugin | Configure the corresponding certbot-dns-<provider> plugin |
| Site goes down after renewal | Missing deploy hook, config not reloaded | Add --deploy-hook "systemctl reload nginx" |
| Let's Encrypt rate limit reached | Too many repeated issuances in a short time | Use --dry-run for testing; only issue for real when needed |
| Certificate issued but new subdomain not covered | Subdomain not included in the -d flags at issuance | Reissue including all subdomains or use a wildcard |
Automated SSL checklist
- Certbot installed and certificate issued for all active domains/subdomains.
- HTTP → HTTPS redirect confirmed on Nginx/Apache.
certbot renew --dry-runrun with no errors.systemd timeror renewal cron confirmed active.- Web server reload deploy hook configured.
- Wildcard configured via a DNS plugin, if applicable.
- Independent expiration alert (openssl + webhook) implemented.
With SSL renewal fully automated, the server's website, account panel, and store no longer risk showing up as "insecure" to players. If you're still setting up the web environment from scratch, also check out the MU Online server creation tutorial to align the web infrastructure with the GameServer.
Frequently asked questions
Is the Let's Encrypt certificate really free forever?
Yes, Let's Encrypt is a free, nonprofit service run by the Internet Security Research Group. There's no cost to issue or renew certificates, as long as automatic renewal is set up — the certificate expires every 90 days and must be renewed before then.
What happens if the certificate expires without me noticing?
The player's browser starts showing an 'insecure connection' warning when accessing the website, account panel, or store, which sharply drops trust and sales conversions. Login and payment forms may stop working in more restrictive browsers.
Do I need to renew manually every 90 days?
No, if automation is set up correctly. Certbot installs a task by default (cron or systemd timer) that checks daily whether the certificate is less than 30 days from expiring and renews it automatically when needed.
Does it work with any web server (Nginx, Apache, IIS)?
Certbot has native support for Nginx and Apache on Linux. For IIS on Windows, the most common alternative is win-acme (also based on Let's Encrypt) with an equivalent schedule via Task Scheduler.
Do I need to restart the site every time the certificate renews?
Depends on the web server. Nginx and Apache normally only need a reload (not a full restart) to load the new certificate, which Certbot already does automatically via a post-renewal hook, with no noticeable downtime.