Panellicense

Install a Let's Encrypt SSL certificate on R1Soft Server Backup Manager

Replace the self-signed certificate on the R1Soft SBM web UI (port 8443) with a Let's Encrypt cert using acme.sh, a PKCS12 keystore, and a Tomcat connector reload.

7 min readUpdated 2026-05-18r1soft · ssl · tls · letsencrypt
schema: HowToschema: FAQPage

R1Soft Server Backup Manager (SBM) ships with a self-signed certificate on its web UI at port 8443. That is fine for the first boot and a fast way to lose your team's trust three months later, when half of them have clicked through browser warnings so many times that nobody notices when the cert actually changes. A real certificate also lets you wire the SBM into single sign-on flows, monitoring agents, and the R1Soft API without TLS verification disabled.

This guide swaps the self-signed cert for a Let's Encrypt certificate using acme.sh, converts it into the PKCS12 keystore Tomcat expects, and reloads the SBM's HTTPS connector without losing in-flight backups. End-to-end on a fresh SBM: about 15 minutes.

What you replace and where

The SBM is a Tomcat application. Its TLS settings live in /usr/sbin/r1soft/conf/server.xml, and the default keystore is a Java keystore at /usr/sbin/r1soft/conf/.keystore with the well-known password password. Three things change in this procedure:

  • A new PKCS12 keystore at /usr/sbin/r1soft/conf/sbm.p12 containing the Let's Encrypt cert and chain
  • The <Connector port="8443" ...> block in server.xml pointed at the new keystore
  • A weekly cron that renews the cert and rebuilds the keystore in place

The HTTP connector on port 8084 is unchanged. If you have it enabled, disable it after TLS works — there is no reason to keep it open on a production SBM.

Prerequisites

  • A DNS A record for the SBM (e.g. backups.example.com) pointing at the SBM's public IP
  • TCP/80 reachable from the public internet for HTTP-01 challenges, or working DNS API credentials for DNS-01
  • Root on the SBM and a valid R1Soft license on the box
  • SBM version 6.16 or newer (older versions ship a Tomcat 8 that doesn't read PKCS12 keystores correctly — upgrade first)

Step 1 — Issue the certificate with acme.sh

acme.sh is preferable to certbot here because it doesn't pull in Python, doesn't fight SELinux, and handles the PKCS12 conversion in one command.

curl https://get.acme.sh | sh -s email=ops@example.com
source ~/.bashrc

acme.sh --issue -d backups.example.com --standalone --httpport 80

If port 80 is occupied (CSF, nginx, anything), use a DNS API plugin instead:

export CF_Token="your-cloudflare-api-token"
acme.sh --issue --dns dns_cf -d backups.example.com

On success the cert lands in ~/.acme.sh/backups.example.com_ecc/. ECC is acme.sh's default since 3.0; RSA works too if you append --keylength 2048, but Tomcat 9+ handles ECC fine and the handshake is faster.

Step 2 — Build the PKCS12 keystore

Tomcat reads PKCS12 natively. Build it directly from acme.sh output:

acme.sh --install-cert -d backups.example.com --ecc \
  --pfx-file /usr/sbin/r1soft/conf/sbm.p12 \
  --pfx-password 'changeme-strong-password'

chown root:root /usr/sbin/r1soft/conf/sbm.p12
chmod 600 /usr/sbin/r1soft/conf/sbm.p12

Verify the keystore has a key entry and the full chain:

keytool -list -v -keystore /usr/sbin/r1soft/conf/sbm.p12 \
  -storepass 'changeme-strong-password' -storetype PKCS12 \
  | grep -E 'Alias|Entry type|Owner|Issuer'

You should see one PrivateKeyEntry whose Owner is your hostname and whose Issuer is Let's Encrypt's intermediate. If Entry type is trustedCertEntry you only imported the cert, not the key — re-run the install command with --pfx-file.

Step 3 — Point Tomcat at the new keystore

Edit /usr/sbin/r1soft/conf/server.xml and find the connector on 8443. It looks like this on a stock install:

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
           maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
           keystoreFile="conf/.keystore" keystorePass="password"
           clientAuth="false" sslProtocol="TLS"/>

Replace it with a modern connector that reads the PKCS12 keystore and disables old protocols:

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
           maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
           keystoreFile="/usr/sbin/r1soft/conf/sbm.p12"
           keystorePass="changeme-strong-password"
           keystoreType="PKCS12"
           clientAuth="false"
           sslEnabledProtocols="TLSv1.2,TLSv1.3"
           ciphers="TLS_AES_128_GCM_SHA256,TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384"/>

The cipher list is the Mozilla intermediate compatibility set trimmed to GCM and ChaCha20. Drop CBC ciphers — they buy nothing and Qualys SSL Labs will mark them down.

Step 4 — Restart the SBM cleanly

The cdp-server restart drops the web UI for about 20 seconds and pauses agent traffic for a few more. It does not lose recovery points in flight — block transfers resume from the last acknowledged offset.

systemctl restart cdp-server
journalctl -u cdp-server -n 50 --no-pager | grep -i 'ssl\|connector\|started'

You want to see something like Initializing ProtocolHandler ["https-jsse-nio-8443"] followed by Server startup in X ms. If you see java.io.IOException: keystore password was incorrect, the keystorePass in server.xml doesn't match the --pfx-password you set. Fix and restart.

Test from outside the box:

curl -vI https://backups.example.com:8443/ 2>&1 | grep -E 'subject|issuer|HTTP/'

The subject CN should be your hostname; the issuer should be R3 or E5 (Let's Encrypt intermediates as of 2026); the HTTP response should be a 302 or 200.

Step 5 — Automate renewal

Let's Encrypt certs are valid for 90 days. acme.sh runs daily via cron after the install script. You only need to hook the post-renew step to rebuild the keystore and reload Tomcat.

Edit the renewal hook in ~/.acme.sh/account.conf or pass it on next renewal:

acme.sh --install-cert -d backups.example.com --ecc \
  --pfx-file /usr/sbin/r1soft/conf/sbm.p12 \
  --pfx-password 'changeme-strong-password' \
  --reloadcmd 'systemctl restart cdp-server'

This persists the reload command in acme.sh's state. Every 60 days, the renewal runs unattended, rebuilds the keystore, and restarts the SBM. The 20-second outage falls in whatever maintenance window you configure — schedule the renewal hook outside your backup-heavy windows.

Common gotchas

  • Tomcat won't start with keystoreType="PKCS12" on SBM 6.15 and older. Upgrade to 6.16+ or use a JKS keystore built with keytool -importkeystore.
  • The cert renews but Tomcat keeps serving the old one. The reloadcmd didn't fire. Check ~/.acme.sh/backups.example.com_ecc/backups.example.com.conf for the Le_RenewHook line.
  • Agent connections break after the cert change. Agents speak to the SBM on TCP/1167 with their own mutual-auth scheme — they don't care about the web UI cert. If agents drop after the swap, you likely also changed the SBM hostname; rebind agents to the new hostname under Servers → edit → Hostname.
  • Replication target SBM rejects the new cert. Disk Safe Replication validates the target's TLS cert by default. If the secondary still has a self-signed cert, replication will fail with a chain validation error — fix both ends.

FAQ

What port does R1Soft Server Backup Manager use for HTTPS?+
Port 8443 by default. The HTTP fallback on port 8084 is deprecated and should be disabled in production. Agent traffic is separate — TCP/1167 with mutual TLS that doesn't use the web UI certificate.
Can I use certbot instead of acme.sh for R1Soft SBM?+
Yes, but you'll need an extra step to convert PEM output to PKCS12 with openssl. acme.sh's --pfx-file flag does this in one command, which makes the renewal hook simpler.
Where is the R1Soft Tomcat keystore?+
The default Java keystore is at /usr/sbin/r1soft/conf/.keystore with password 'password'. After the migration in this guide, the PKCS12 keystore lives at /usr/sbin/r1soft/conf/sbm.p12 and is referenced from server.xml.
Does restarting cdp-server kill running backups?+
It pauses agent traffic for about 30 seconds. Block transfers resume from the last acknowledged offset — recovery points in flight don't restart. Avoid the restart during a full sweep on a multi-TB safe; do it between schedule windows.
How long are Let's Encrypt certs valid for the R1Soft SBM?+
90 days, same as any Let's Encrypt cert. acme.sh renews at the 60-day mark by default. With the --reloadcmd hook in place the SBM picks up the new cert automatically — no manual intervention.

Next steps

Related articles

All tutorials & how-tos →
how to
Set up JetBackup 5 deduplication backups to cut storage cost
JetBackup 5.4 added a deduplication backup structure that fingerprints data in chunks and stores each unique chunk once — here's how it works, where it pays off, and how to turn it on.
6 min read
how to
Plesk 360 setup guide for centralized licenses and monitoring
Plesk 360 is the SaaS control plane for everyone running more than one Plesk box — license management, uptime monitoring, and SSO into every panel from one dashboard.
7 min read
how to
Use the Plesk REST API with reseller and customer accounts
Plesk Obsidian 18.0.79 opens the REST API to reseller and customer accounts and adds file, log, and impersonation endpoints — how to authenticate and use them.
7 min read
Switch in an afternoon

Switch from your current reseller — free.

We migrate active cPanel, Plesk, LiteSpeed and CloudLinux licenses from any reseller. We prorate the first month so you never pay twice, and your customers see zero downtime during the swap.