Nexapp - Certificates and reverse proxy

Certificates and Reverse Proxy

This section explains how NexappOS manages SSL/TLS certificates and how to publish internal web services securely using the built-in reverse proxy.

Reverse Proxy

NexappOS includes an integrated reverse proxy based on Nginx. A reverse proxy (also called proxy pass) sits in front of one or more web servers and forwards client requests to the correct destination.

In practice, a reverse proxy works like a traffic controller for web services: - clients connect to NexappOS - NexappOS forwards the request to the internal server - the response is returned back to the client

Reverse proxies are commonly used to: - improve performance (caching static content, reducing load) - increase reliability (fronting multiple servers) - enhance security by terminating TLS on the gateway

Note
Reverse proxy is available only on TCP port 443 (HTTPS).
Port 80 (HTTP) is not supported.

Configure a Reverse Proxy Rule

Open Services → Reverse Proxy and click Add reverse proxy.
Then configure the following fields:

• Type
  Choose one:

  • Domain: match requests by fully qualified domain name (FQDN).
    Example: portal.example.com
    When using Domain mode, select an associated certificate.
  • Path: match requests by URL path starting with /.
    Example: /resource-path

• Destination URL
  Define where NexappOS forwards incoming requests.
  Example:
  http://internal-server:8080/app

• Allowed networks
  Limit access to specific IPv4/IPv6 networks in CIDR format.
  Examples:

  • 192.168.10.0/24
  • 2001:db8::/32
    If left empty, the service is reachable from anywhere.

• Description (optional)
  Add a clear label for administration and future reference.

Additional Behavior

• Forwarded headers
  NexappOS always passes these headers to the destination server:

  • X-Forwarded-Proto
  • X-Forwarded-For
  • X-Real-IP

• HTTPS destination validation
  If your destination uses HTTPS, NexappOS does not validate the upstream certificate.
  This avoids failures caused by misconfigured internal servers.

• WebSocket support
  All reverse proxy rules automatically support WebSockets.

Certificates

The Certificates page is the central place to manage all SSL/TLS certificates used by NexappOS services.

At first boot, NexappOS generates a self-signed certificate automatically. This ensures secure access out of the box, even before importing a trusted certificate.

From this page you can: - upload custom certificates - request publicly trusted certificates via Let’s Encrypt - switch the default certificate

All certificates are listed with the default one highlighted.
To set a different default certificate, click:

• Set as default

The default certificate is used automatically by: - the web interface (port 9090) - HTTPS access on port 443 - any custom UI port if configured

Let’s Encrypt Certificates

Let’s Encrypt is a free, automated Certificate Authority that provides trusted SSL/TLS certificates for public domains. Certificates issued here: - secure browser access with valid HTTPS - renew automatically (every 60 days in NexappOS)

Request a Let’s Encrypt Certificate

1. Go to System → Certificates
2. Click Add Let’s Encrypt certificate
3. Enter:
   • Name (meaningful label)
   • Domain(s) (one or more FQDNs)
4. Click Save

The certificate status will show Pending during validation and issuance.

Validation Methods

Let’s Encrypt validation can run in two modes:

Standalone Mode (HTTP Validation)

In this mode NexappOS temporarily opens port 80 to prove domain ownership.

Requirements: - NexappOS must be reachable from the internet on port 80 - the domain must resolve publicly to the NexappOS public IP - port 80 must not already be forwarded to another server

Process: - NexappOS binds to port 80 briefly - serves the ACME challenge - closes port 80 automatically after validation

DNS Validation

DNS validation proves ownership by adding a TXT record.

Use this mode when: - you cannot expose port 80 publicly - you need wildcard certificates - your DNS provider supports API automation

Steps: 1. Select DNS validation 2. Choose your DNS provider 3. Enter the required API key/secret
4. Save and wait for issuance

DNS validation is the only supported method for wildcard domains.

Debug Let’s Encrypt

If issuance fails, you can enable debug output:

```bash uci set acme.@acme[0].debug=1 /etc/init.d/acme start