How to set up SSL/HTTPS on a MU Online server website

Running your MU Online server website on plain HTTP, with no padlock, is a problem on several fronts at once. First, credibility: the browser displays "Not secure" next to the address, and no player trusts entering a password in that context. Second, real security: without HTTPS, login, registration and panel data travel in plain text, and anyone on the same network (a LAN-house Wi-Fi, an ISP, a compromised router) can capture the credentials. Third, functionality: modern website features, payment integrations and even search-engine ranking depend on HTTPS.

This guide is intermediate-level and covers the two environments most used on MU servers: IIS on Windows Server (the standard for those using webEngineNET and distros running on Windows) and Apache (XAMPP on Windows or LAMP on Linux). You will install a free, valid certificate, force HTTPS, automate the renewal and resolve the classic errors that show up right after enabling it. If you are still building the server foundation, first see how to create a MU Online server.

Prerequisites

Before you start, confirm you have all of this ready:

• Your own domain (e.g., myserver.com) — you cannot get a valid public certificate with just an IP.
• DNS pointed: an A record for the domain (and for www) pointing to the server's IP, already propagated.
• Administrative access to the server (RDP on Windows Server or SSH on Linux).
• A site working over HTTP (port 80) before touching SSL.
• Ports 80 and 443 open in the operating system firewall and in the provider/VPS panel.
• A low-traffic time slot to make the switch, since the site may fluctuate for a few minutes.

> Warning: port 80 must be open during certificate issuance. Let's Encrypt validates the domain by accessing a temporary file over HTTP. If 80 is closed, issuance fails.

Understanding the basics: certificate, CA and ports

Before installing, it is worth nailing down three concepts that avoid most errors:

The practical difference between a Let's Encrypt certificate (free, valid, accepted by all browsers) and a self-signed one (that you generate yourself) is enormous: the self-signed one encrypts, but the browser shows the red "connection is not private" screen. For a public server, always use a recognized CA. The self-signed one is only good for an internal test environment.

Option A — HTTPS on IIS (Windows Server) with win-acme

win-acme (wacs.exe) is the standard tool for Let's Encrypt on IIS. It issues, installs and configures the binding automatically.

Step 1 — Prepare the environment

1. Access the server via RDP as administrator.
2. Confirm that the site already responds at http://myserver.com.
3. Open PowerShell as administrator and create the working folder:

New-Item -ItemType Directory -Force C:\ssl-tools | Out-Null
Set-Location C:\ssl-tools

Step 2 — Open the ports in the firewall

New-NetFirewallRule -DisplayName "HTTP-80"  -Direction Inbound -Protocol TCP -LocalPort 80  -Action Allow
New-NetFirewallRule -DisplayName "HTTPS-443" -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow

Step 3 — Download and run win-acme

1. Download win-acme (x64 version) from the official repository at https://github.com/win-acme/win-acme/releases.
2. Extract it into C:\ssl-tools\wacs\.
3. Run wacs.exe as administrator.
4. In the menu, choose the option to create a simple new certificate (usually the N key).
5. win-acme lists the IIS sites. Select your MU site.
6. Choose the hostnames (myserver.com and www.myserver.com).
7. Accept the Let's Encrypt terms and provide an email for expiration notices.

win-acme validates the domain, issues the certificate, creates the HTTPS binding on port 443 in IIS and already sets up a scheduled renewal task. At the end, https://myserver.com should open with a padlock.

Step 4 — Check the binding in IIS

Open IIS Manager → Sites → your site → Bindings. There should be an https entry on port 443 with the domain certificate. If it does not exist, add it manually: Add → Type: https → Port: 443 → SSL certificate: your domain's.

Step 5 — Force HTTPS via web.config

Add (or edit) the web.config in the site root to redirect all HTTP to HTTPS. It requires the URL Rewrite module installed in IIS.

<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Forcar HTTPS" stopProcessing="true">
          <match url="(.*)" />
          <conditions>
            <add input="{HTTPS}" pattern="off" ignoreCase="true" />
          </conditions>
          <action type="Redirect" url="https://{HTTP_HOST}/{R:1}"
                  redirectType="Permanent" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

Option B — HTTPS on Apache (XAMPP / Linux)

If you use Apache, the path depends on the system. On Linux certbot does almost everything on its own; on XAMPP (Windows) the configuration is more manual.

Step 1 (Linux) — Issue with certbot

# Debian/Ubuntu with Apache
sudo apt update && sudo apt install certbot python3-certbot-apache -y
sudo certbot --apache -d myserver.com -d www.myserver.com

certbot asks for your email, validates the domain, writes the SSL VirtualHost and offers to redirect HTTP to HTTPS automatically — accept that option. Renewal is already scheduled via a systemd timer or cron.

Step 2 (XAMPP/Windows) — Enable the SSL module

In XAMPP, SSL is already compiled in. In httpd.conf, confirm that these lines are uncommented:

LoadModule ssl_module modules/mod_ssl.so
Include conf/extra/httpd-ssl.conf

Then, in httpd-ssl.conf, point to the certificate files (which you received from the CA or generated):

<VirtualHost _default_:443>
    DocumentRoot "C:/xampp/htdocs"
    ServerName myserver.com:443
    SSLEngine on
    SSLCertificateFile      "conf/ssl.crt/myserver.crt"
    SSLCertificateKeyFile   "conf/ssl.key/myserver.key"
    SSLCertificateChainFile "conf/ssl.crt/chain.crt"
</VirtualHost>

Step 3 — Force HTTPS via .htaccess

In the site root (htdocs), with mod_rewrite active:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [L,R=301]

Restart Apache from the XAMPP panel (or sudo systemctl restart apache2 on Linux) and test https://myserver.com.

Automatic renewal — the step no one can skip

The Let's Encrypt certificate expires in 90 days. If it expires, the entire site starts showing a security error and the players vanish. Automatic renewal is already configured by win-acme and by certbot, but you must verify that it works:

# Windows: check the win-acme scheduled task
Get-ScheduledTask | Where-Object { $_.TaskName -like "*win-acme*" }

# Linux: test the renewal in dry-run mode (changes nothing)
sudo certbot renew --dry-run

If --dry-run finishes without an error, the real renewal will work. Put a quarterly reminder on your calendar just to check the padlock, to be safe.

Fixing mixed content

The most common error after enabling HTTPS: the padlock appears "broken" or the console shows mixed content warnings. This happens when an https:// page loads resources over http:// — images, ranking banners, CSS or scripts. The browser blocks some of these resources and complains.

Solution: switch all internal URLs to HTTPS or, better, to relative paths:

<!-- Wrong: forces http inside an https page -->
<img src="http://myserver.com/img/logo.png">

<!-- Right: relative path, inherits the page's protocol -->
<img src="/img/logo.png">

To find the occurrences quickly, use your editor's search for http:// across all site files and adjust them. Don't forget to also check the configuration fields saved in the database (banner URLs, panel links).

Common errors and fixes

Hardening the configuration (optional, recommended)

Once HTTPS has been stable for a few days, enable HSTS so the browser never tries HTTP again on your domain. On IIS, add the header in web.config; on Apache, in the SSL VirtualHost:

# Apache — inside the VirtualHost 443
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Careful: only enable HSTS when you are sure that everything works over HTTPS, including subdomains. Once the browser memorizes the HSTS, it refuses any HTTP access to that domain for the duration of max-age. Start with a smaller value (for example, a few hours) while you test.

Launch checklist

• Domain with an A record pointed and propagated to the server's IP
• Ports 80 and 443 open in the OS and provider firewall
• Valid certificate from a recognized CA installed (not self-signed)
• HTTPS binding on port 443 configured (IIS) or VirtualHost 443 (Apache)
• 301 redirect from HTTP to HTTPS active
• Automatic renewal verified (win-acme or certbot renew --dry-run)
• No mixed-content warning in the browser console
• Login and registration tested and working under HTTPS
• Internal and database URLs converted to https/relative
• HSTS evaluated and enabled after a stabilization period
• Quarterly reminder created to check the padlock

With HTTPS active, forced and with automatic renewal, your server's website starts genuinely protecting players' credentials and gains the credibility the padlock conveys. It is a small step in effort and an enormous one in trust.

Frequently asked questions