SSL Configuration and Reverse Proxy Challenges in OneUptime Docker-Compose Setup

[torstenhoegel]

Describe the bug
The current OneUptime Docker-Compose setup assumes SSL is managed externally. I have configured SSL using NGINX with Certbot on the host instance. The issue arises when trying to set up the status page host. Despite configuring an A record and setting up NGINX to proxy traffic to the container, the status page fails to work correctly. The container expects SSL connections even on port 443, but the dashboard process does not handle SSL, leading to proxying issues.

The following NGINX configuration is used for the status page:

server {
    listen 443 ssl;
    server_name <redactedDomain>;

    # SSL Certificates for Nginx
    ssl_certificate /etc/letsencrypt/live/<redactedDomain>/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/<redactedDomain>/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    location / {
        proxy_pass https://localhost:4035; # Route to OneUptime's container port
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_ssl_verify off;
    }

    # Optional: Custom error handling
    error_page 502 /502.html;
    location = /502.html {
        root /usr/share/nginx/html;
        internal;
    }
}

# Catch-All Block
server {
    listen 443 ssl default_server;
    server_name _;

    ssl_certificate /etc/letsencrypt/live/<redactedDomain>/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/<redactedDomain>/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    location / {
        proxy_pass https://localhost:4035;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_ssl_verify off;
    }
}

server {
    listen 80 default_server;
    server_name _;

    return 301 https://$host$request_uri;
}

When the system runs, the ingress container logs the following error:

2024/11/27 15:28:36 [error] 28#28: *5685 cannot load certificate "/etc/nginx/certs/StatusPageCerts/.crt": BIO_new_file() failed (SSL: error:80000002:system library::No such file or directory:calling fopen(/etc/nginx/certs/StatusPageCerts/.crt, r) error:10000080:BIO routines::no such file) while SSL handshaking, client: 172.19.0.1, server: 0.0.0.0:7850

It appears the container expects SSL certificates to be handled internally or placed in a specific directory (/etc/nginx/certs/StatusPageCerts), but this is not documented, nor is it clear how to integrate external SSL handling with the container setup.

To Reproduce
Steps to reproduce the behavior:
1. Deploy OneUptime using Docker-Compose.
2. Configure an A record to point to the instance running the status page.
3. Set up NGINX with SSL termination and proxy traffic to the container.
4. Attempt to access the status page and observe the error.

Expected behavior
The status page should work seamlessly with externally terminated SSL (via NGINX). Alternatively, the container should be capable of handling SSL termination itself without requiring complex workarounds.

Screenshots
N/A

Desktop
• OS: Ubuntu 22.04
• Browser: not relevant
• Version: not relevant

Deployment Type
Self-hosted

Additional context
• Documentation on SSL handling within the container and integrating with reverse proxies is unclear.
• The expectation that SSL is managed externally conflicts with the container’s behavior and logs.
• A clear guide for deploying with external SSL termination and reverse proxies (e.g., NGINX, Traefik) would resolve these issues.

[torstenhoegel]

@simlarsen would you mind to elaborate on this?

[simlarsen]

Looking into this. Should have an update on this soon.

[torstenhoegel]

Sounds great! Really looking forward to that

[torstenhoegel]

@simlarsen any updates on this?