Skip to content

Feature Request: RCON WebUI SSL/TLS Support #65

@Ralnoc

Description

@Ralnoc

Summary

The RCON WebUI currently does not provide built-in support for SSL/TLS.
This requires users to expose the interface over plain HTTP or deploy an
external reverse proxy for secure access.

To improve usability and security, the Docker image should support
native SSL/TLS configuration for the WebUI.

This feature should allow users to either:

  1. Automatically generate and manage certificates using Let's
    Encrypt
    .
  2. Provide their own custom SSL certificates mounted into the
    container.

Supporting both options will allow secure access to the RCON WebUI while
maintaining flexibility for different deployment environments.


Expected Functionality

The Docker image should support two SSL configuration modes.


Option 1: Let's Encrypt Certificate Support

Allow the container to automatically request and manage SSL certificates
using the Let's Encrypt API.

Requirements

The implementation should support:

  • Automatic certificate creation
    • Request certificates from Let's Encrypt for a specified domain.
  • Domain configuration
    • Users must be able to specify the domain name the certificate
      will be issued for (e.g. via environment variable).
  • Safe certificate storage
    • Certificates must be stored in a persistent location (volume or
      mounted path) so they survive container restarts.
  • Certificate renewal
    • Certificates should automatically renew before expiration.

Example Environment Variables

RCON_SSL_PROVIDER=letsencrypt
RCON_SSL_DOMAIN=rcon.example.com
RCON_SSL_EMAIL=admin@example.com
RCON_SSL_STORAGE=/data/certs

Option 2: User-Provided Certificates

Users should also be able to provide their own certificates instead of
using Let's Encrypt.

Requirements

  • The container should allow mounting a directory containing:
    • cert.pem
    • key.pem
  • The certificate path should be configurable via environment
    variables.

Example

RCON_SSL_PROVIDER=custom
RCON_SSL_CERT_PATH=/certs/cert.pem
RCON_SSL_KEY_PATH=/certs/key.pem

Example Docker volume mount:

-v ./certs:/certs

Proposed Implementation: Caddy for SSL Management

To simplify HTTPS support for the RCON WebUI, the Docker image could
integrate Caddy as a lightweight reverse proxy responsible for TLS
termination and certificate management.

Caddy is particularly well suited for standalone services because it
provides automatic HTTPS by default, including certificate issuance,
renewal, and storage. This significantly reduces operational complexity
compared to manually configuring TLS.


Automatic SSL Certificates (Let's Encrypt)

Caddy includes native support for Let's Encrypt through the ACME
protocol
. When configured with a domain name, Caddy will automatically
perform the full certificate lifecycle.

Certificate Creation

When the container starts:

  1. Caddy detects the configured domain.
  2. It performs the ACME challenge (typically HTTP-01).
  3. A TLS certificate is requested from Let's Encrypt.
  4. The certificate is installed automatically and HTTPS is enabled.

No external tools such as Certbot are required.

Automatic Renewal

Let's Encrypt certificates are valid for 90 days. Caddy
automatically:

  • Tracks expiration
  • Renews certificates before they expire
  • Reloads them without service interruption

This process requires no user intervention.

Safe Certificate Storage

Caddy stores certificates and ACME account data in its internal data
directory
.

Typical path inside a container:

/data/caddy

This directory can be mounted as a persistent Docker volume,
ensuring certificates survive container restarts or upgrades.

Example:

-v ./caddy-data:/data

Stored assets include:

  • TLS certificates
  • private keys
  • ACME account registration
  • renewal metadata

Domain Configuration

Users simply specify the domain name used to access the WebUI.

Example environment variable:

RCON_DOMAIN=rcon.example.com

Caddy will automatically request the certificate for that domain.


Support for User-Provided Certificates

In addition to automatic certificates, Caddy fully supports manually
provided TLS certificates
.

This is useful when users:

  • Already manage certificates externally
  • Use internal certificate authorities
  • Use wildcard certificates
  • Use certificates issued by another provider

Manual Certificate Configuration

Users can mount a directory containing their certificates into the
container.

Example:

-v ./certs:/certs

Files expected:

/certs/cert.pem
/certs/key.pem

Caddy can then be configured to use those files instead of requesting a
certificate.

Example conceptual configuration:

tls /certs/cert.pem /certs/key.pem

Benefits of Manual Certificate Support

This allows the container to work in environments where:

  • outbound internet access is restricted
  • internal PKI systems are required
  • Let's Encrypt validation cannot be performed
  • custom wildcard certificates are preferred

Benefits of Using Caddy

Integrating Caddy into the Docker image would provide several
advantages:

Simplified HTTPS

Users can enable HTTPS simply by specifying a domain name. No reverse
proxy configuration or certificate tooling is required.

Automatic Security Best Practices

Caddy automatically configures:

  • modern TLS versions
  • secure cipher suites
  • HTTP → HTTPS redirects
  • OCSP stapling

Reduced Maintenance

The container does not need additional tooling such as:

  • Certbot
  • cron jobs
  • manual certificate renewal scripts

Flexible Deployment

Users can choose between:

  • Automatic certificates (Let's Encrypt)
  • Manually provided certificates

This ensures compatibility across home servers, cloud environments, and
restricted networks.


Example Architecture

Internet
    │
    ▼
Caddy (TLS Termination)
    │
    ▼
RCON WebUI (HTTP)

Caddy manages:

  • TLS certificates
  • HTTPS access
  • HTTP → HTTPS redirect

The RCON WebUI continues running on plain HTTP internally.


Additional Considerations

  • SSL support should remain optional to maintain backwards
    compatibility.
  • The container should fall back to HTTP if SSL is not configured.
  • Documentation should include examples for both SSL modes.

Metadata

Metadata

Assignees

No one assigned

    Labels

    ConfirmedIssue has been confirmed to be an existing bug or anti-pattern to expected behaviorPending PrioritizationNeeds to be prioritized and scheduled for completion
    No fields configured for Feature.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions