I am doing exactly what you’re describing with the exception of nginx proxy manager. I personally could not get it working for me and prefer the control of manually configurating the proxy. Sometimes to my own stress.

I run home assistant and expose it to a non standard port. I use certbot to refresh my ssl cert and have never had issues.

How are you doing your verification? If you are using HTTP acme challenge then yes you must have the standard 80 port open for the verification to occur.

If you are using DNS verification, it does not require any port to open as your verification is done at the DNS provider.

I have Cloudflare DNS and do DNS verification.

Just did a quick test, the certs do not bind to the port, only the domain/fqdn. So in short your reverse proxy/application is doing something wrong. Do you have the cert files? Can you test them inside a ubuntu:24.04 docker with the script bellow? (you’ll need to copy two cert files). That does TLS and is the application all in one script, but it could be two scripts one acting as the reverse proxy or whatever, doesn’t make a difference from the point of view of the client.

Lets Encrypt doesn’t do anything in port 80/443 unless you’re using the http challlenge AFAIK. And once you have the certs, they aren’t really involved in the connection, thus that can’t be the issue. Test by using curl against the script below, or your own infrastructure (each step/chain of it, the reverse proxy, the application ip, etc.)

But in short I think your reverse proxy configuration is just wrong, or you’re accessing it the wrong way on the client side. For example, using https://example.com/ instead of https://example.com:5050/.

# docker run --rm --net host -it ubuntu:24.04
# then install python3 and run this
import http.server
import ssl

PORT = 5201  # Change to your desired port
CERT_FILE = "/fullchain.pem"  # Path to your certificate file
KEY_FILE = "/key.pem"    # Path to your private key file

# Create a basic HTTP request handler
class SimpleHTTPRequestHandler(http.server.SimpleHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.send_header("Content-type", "text/html")
        self.end_headers()
        self.wfile.write(b"<h1>Welcome to the secure static server!</h1>")

# Set up the HTTP server
httpd = http.server.HTTPServer(("0.0.0.0", PORT), SimpleHTTPRequestHandler)

# Set up SSL context
ssl_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
ssl_context.load_cert_chain(certfile=CERT_FILE, keyfile=KEY_FILE)

# Wrap the server socket with SSL
httpd.socket = ssl_context.wrap_socket(httpd.socket, server_side=True)

print(f"Serving HTTPS on port {PORT}")
httpd.serve_forever()

I assume, you use certbot for certificate management. In its documentation the option --http-01-port is stated which defaults to 80, the http port, which shall be reachable for the certificate generation procedure. Hence, I assume, this should be specified according to your needs.

I’ve got a similar set up and everything works. So, I can confirm that your assumptions are sound.

My solution is kubernetes based, so I use cert-Manager to issue/create the Let’s Encrypt (using DNS as the verification mechanism), when gets fed into a Traefik Reverse Proxy. Traefik is running on a non-standard port, which I can access from the outside world.

I’d suggest tearing your current system down and verify everything is configured correctly.

For example :

• Take a look at the SSL cert. Is it generated properly?
• Look at the reverse proxy. Is it using the proper SSL cert and is it properly formatted? (I’ve found curl - -verbose - - insecure https://... to be helpful)
• Maybe add a static file (ie: robots.txt) to nginx. This would allow you to see if the problem is between the outside world and nginx or between nginx and your service.
• You can also use the “snake oil” cert, in a pinch. It’s an insecure SSL cert, but it would allow you to confirm that your nginx is properly configured and it would confirm that the issue is with the Lets Encrypt cert (or that process/payload).

… and not to rob you of this experience, but you might want to look into Cloudflare Tunnels. It allows you to run services within your network, but are exposed/accessible directly from Cloudflare. It’s entirely secure (actually more so than your proposed system) and you don’t need to mess around with SSL.

TLS is not picky, as long as you’ve got your certificate you can use it pretty much on whatever port with whatever content. It doesn’t even have to be http

i was under the impression ssl is port-agnostic except in configuration where you apply it to a service on a port.

80/443 are just defaults… configure it right, and it shouldnt matter what port you need it on