Install Let’s Encrypt SSL on Ubuntu with OpenLiteSpeed and Auto-Renewal

Quick answer: For an existing OpenLiteSpeed site, use Certbot’s webroot authenticator so the site stays online, point OpenLiteSpeed to Let’s Encrypt’s fullchain.pem and privkey.pem, then add a Certbot deploy hook that gracefully restarts OpenLiteSpeed after a successful renewal. You need a public DNS record, an HTTP listener on port 80, an HTTPS listener on port 443, and the correct document root.

This route obtains a certificate but does not automatically edit OpenLiteSpeed’s configuration. OpenLiteSpeed also includes a native ACME feature that can issue and renew certificates from the server itself; choose one certificate-management method for each site rather than configuring both for the same certificate.

What you will complete

• Install the current Certbot snap on Ubuntu.
• Request a certificate for example.com and, optionally, www.example.com.
• Configure OpenLiteSpeed to use the certificate and private key.
• Redirect ordinary HTTP requests to HTTPS.
• Make renewal reload OpenLiteSpeed without manual intervention.
• Verify the certificate, renewal timer, HTTP challenge path, and rollback path.

Prerequisites and values to replace

Use a shell on the Ubuntu server, either through SSH or the provider’s console. Replace every placeholder in the commands below before running them.

• example.com: your domain name.
• www.example.com: an optional second hostname that resolves to the same server.
• admin@example.com: an email address for Certbot account notices.
• /var/www/example.com: the document root actually used by the OpenLiteSpeed virtual host.

Before continuing, confirm that the domain’s A or AAAA record points to this server, the site is reachable over HTTP, and the server can receive inbound TCP connections on ports 80 and 443. HTTP-01 validation places a temporary token under /.well-known/acme-challenge/ and can only use port 80 (according to letsencrypt.org).

Find the OpenLiteSpeed document root in WebAdmin under Virtual Hosts → your virtual host → General → Document Root. If you use a hosting panel, use the panel’s displayed document root instead of guessing it.

Install Certbot on Ubuntu

Run these commands in the Ubuntu shell. The Snap package is the recommended Certbot installation method in the Ubuntu documentation (according to ubuntu.com).

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/local/bin/certbot

If the last command reports that the link already exists, inspect it instead of replacing it:

ls -l /usr/local/bin/certbot
certbot --version

Do not install the obsolete certbot-auto. If an older Ubuntu package is installed and you deliberately want Certbot to be managed by Snap, remove only the old package after checking what depends on it:

apt-cache policy certbot
sudo apt remove certbot

Choose the validation method

For a public OpenLiteSpeed website, the webroot method is normally the least disruptive because it keeps the web server running. Certbot writes a temporary file into the site’s document root, and Let’s Encrypt retrieves it through HTTP.

Recommended: webroot validation

First test that OpenLiteSpeed serves files from the expected document root:

sudo mkdir -p /var/www/example.com/.well-known/acme-challenge
printf 'acme-test\n' | sudo tee /var/www/example.com/.well-known/acme-challenge/test.txt
curl -i http://example.com/.well-known/acme-challenge/test.txt

Expected result: an HTTP 200 response containing acme-test. If the response is 301, 403, or 404, fix the OpenLiteSpeed virtual-host mapping, rewrite rules, permissions, or firewall before requesting the certificate.

Request the certificate. Run one command with each domain that should appear on the certificate:

sudo certbot certonly --webroot \
  -w /var/www/example.com \
  -d example.com \
  -d www.example.com \
  --email admin@example.com \
  --agree-tos \
  --no-eff-email

For a site that does not use www, omit -d www.example.com. A successful request reports the certificate and key locations, normally under:

/etc/letsencrypt/live/example.com/fullchain.pem
/etc/letsencrypt/live/example.com/privkey.pem

The privkey.pem file is sensitive. Do not publish it, paste it into a ticket, or make it downloadable from the website.

Alternative: standalone validation

Use standalone mode only when you can briefly stop every service using port 80. Stop OpenLiteSpeed, request the certificate, and start it again:

sudo systemctl stop lsws
sudo certbot certonly --standalone \
  -d example.com \
  -d www.example.com \
  --email admin@example.com \
  --agree-tos \
  --no-eff-email
sudo systemctl start lsws

This method is unsuitable for unattended renewal unless the renewal configuration includes pre- and post-hooks that stop and start OpenLiteSpeed. For an always-on website, prefer webroot validation or OpenLiteSpeed’s native ACME feature.

Configure the certificate in OpenLiteSpeed

Open the OpenLiteSpeed WebAdmin console, commonly at https://SERVER_IP:7080, then select the virtual host that serves your domain.

1. Open Virtual Hosts → your virtual host → SSL.
2. Set Private Key File to /etc/letsencrypt/live/example.com/privkey.pem.
3. Set Certificate File to /etc/letsencrypt/live/example.com/fullchain.pem.
4. Set the certificate chain option to Yes or Chained Certificate: Yes, depending on the WebAdmin version.
5. Save the configuration and perform a graceful restart.

OpenLiteSpeed’s documented manual configuration uses the Let’s Encrypt fullchain.pem and privkey.pem paths, with the certificate chain enabled (according to docs.openlitespeed.org).

sudo systemctl restart lsws

The command above is OpenLiteSpeed’s documented service restart command. Check the configuration and service status if the restart fails:

sudo /usr/local/lsws/bin/openlitespeed -t
sudo systemctl status lsws --no-pager

Confirm the HTTPS listener and redirect HTTP

OpenLiteSpeed must have a listener on port 443 mapped to the virtual host. In WebAdmin, check Listeners → the HTTPS listener:

• Port: 443
• Secure: Yes
• Virtual Host Mappings: include example.com and any aliases such as www.example.com

Keep an HTTP listener on port 80 if you use HTTP-01 validation. Configure the port-80 virtual host to redirect to the HTTPS hostname. In the virtual host’s Rewrite settings, enable rewriting and add a rule equivalent to:

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

Apply the rule only to the HTTP virtual host. Do not add the same redirect to the HTTPS virtual host, or the site may redirect to itself. Keeping port 80 available for redirects is also recommended for general web servers and helps HTTP-01 validation continue to work (according to letsencrypt.org).

Restart OpenLiteSpeed after changing listener or rewrite settings:

sudo systemctl restart lsws

Configure automatic renewal and reload OpenLiteSpeed

Certbot installations normally include a scheduled renewal task. Certbot reuses the authenticator and options saved for the certificate, but renewing the files is not the same as making a running web server reload them. Add a deploy hook so OpenLiteSpeed reads the renewed certificate after a successful renewal (according to eff-certbot.readthedocs.io).

Create the hook in the root shell:

sudo install -d -m 755 /etc/letsencrypt/renewal-hooks/deploy
sudo tee /etc/letsencrypt/renewal-hooks/deploy/restart-openlitespeed.sh > /dev/null <<'EOF'
#!/bin/sh
systemctl reload lsws 2>/dev/null || systemctl restart lsws
EOF
sudo chmod 755 /etc/letsencrypt/renewal-hooks/deploy/restart-openlitespeed.sh

The hook first attempts a reload and falls back to a restart if the service does not support the requested reload operation. If your server uses a custom service name, replace lsws with that service name.

Check that Certbot has a scheduled task and that the hook is executable:

systemctl list-timers --all | grep -i certbot || true
sudo ls -l /etc/letsencrypt/renewal-hooks/deploy/restart-openlitespeed.sh
sudo certbot certificates

Test renewal before relying on it

Run a staging renewal test. The --dry-run option checks the renewal process without replacing the live certificate (according to eff-certbot.readthedocs.io).

sudo certbot renew --dry-run

Expected result: Certbot completes the renewal simulation without an error and runs the deploy hook. A dry run is not proof that future renewal will always succeed; DNS, firewall, document-root, and OpenLiteSpeed configuration changes can still affect it.

Inspect the saved renewal configuration without editing it first:

sudo sed -n '1,220p' /etc/letsencrypt/renewal/example.com.conf

Do not routinely edit files under /etc/letsencrypt/renewal/ by hand. If the document root changes, use Certbot’s certificate-specific options, test with --dry-run, and only then perform a live renewal.

Verify the complete HTTPS setup

Run these checks from the server or another machine that can reach the public site:

curl -I http://example.com
curl -I https://example.com
sudo ss -ltnp | grep -E ':(80|443)\b'
sudo certbot certificates

• http://example.com should return a redirect to the HTTPS URL.
• https://example.com should return a successful response without a certificate warning.
• The socket check should show OpenLiteSpeed listening on the ports that your configuration uses.
• certbot certificates should show the certificate name, domains, and expiry date.

In a browser, open the HTTPS URL and inspect the certificate details. Confirm that the certificate covers every hostname visitors use and that the browser connects to the intended server IP.

Common failures and safe fixes

HTTP-01 validation fails

Check DNS, port 80, the HTTP listener, and the challenge file directly:

curl -i http://example.com/.well-known/acme-challenge/test.txt
sudo ufw status verbose
sudo ss -ltnp | grep ':80\b'

A 404 usually means the webroot is wrong or the request reaches another virtual host. A 403 commonly indicates permissions or an access rule blocking hidden directories. A timeout usually points to DNS, cloud-firewall, host-firewall, or listener problems.

The certificate renewed but the browser shows the old certificate

Check the certificate files and reload OpenLiteSpeed:

sudo ls -l /etc/letsencrypt/live/example.com/
sudo systemctl restart lsws
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

If the files have a new expiry date but the browser does not, verify that the HTTPS listener points to the live paths, not an old copied certificate under /usr/local/lsws/ or another directory.

The deploy hook fails

Run the hook manually and inspect the service:

sudo /etc/letsencrypt/renewal-hooks/deploy/restart-openlitespeed.sh
sudo systemctl status lsws --no-pager
sudo tail -n 100 /usr/local/lsws/logs/error.log

Correct the service name, executable permission, or OpenLiteSpeed configuration error, then repeat sudo certbot renew --dry-run.

Rollback plan

If the new OpenLiteSpeed configuration prevents the service from starting, restore the previous certificate paths or temporarily disable the changed listener mapping in WebAdmin, validate the configuration, and restart the service:

sudo cp -a /usr/local/lsws/conf /usr/local/lsws/conf.backup-before-letsencrypt
sudo /usr/local/lsws/bin/openlitespeed -t
sudo systemctl restart lsws

If you created the deploy hook and need to stop automatic reloads while investigating, rename it rather than deleting it:

sudo mv /etc/letsencrypt/renewal-hooks/deploy/restart-openlitespeed.sh \
  /etc/letsencrypt/renewal-hooks/deploy/restart-openlitespeed.sh.disabled

Do not delete the live certificate or private key while diagnosing the issue. Once the listener, certificate paths, and hook are corrected, restore the hook name and run the dry-run renewal test again.

When to use OpenLiteSpeed’s native ACME instead

For a new OpenLiteSpeed-only deployment, native ACME may reduce manual certificate-path management. It requires OpenLiteSpeed to run as root, public access to the validation ports, and configuration of the ACME facility in WebAdmin. OpenLiteSpeed documents daily checks and renewal when a certificate is within 30 days of expiration (according to docs.openlitespeed.org).

Use either native ACME or Certbot for a particular certificate. If you switch methods, record the existing certificate name and configuration first, remove the old renewal path only after the new method has passed its verification test, and keep a rollback copy of the OpenLiteSpeed configuration.

Reference source

• Obtain TLS certificates— Ubuntu Server documentation.
• Get Certbot— Certbot documentation.
• User Guide— Certbot documentation.
• certbot — Certbot 5.8.0 documentation— Certbot documentation.
• Challenge Types— Let’s Encrypt.
• Best Practice – Keep Port 80 Open— Let’s Encrypt.
• Configuration— OpenLiteSpeed Documentation.
• Automatic SSL Certificates (ACME)— OpenLiteSpeed Documentation.