What is the requirement of Port 443 for?

[polarathene]

I know that port 443 is for serving HTTPS requests and proxying those via nginx-proxy to other container ports as HTTP traffic. acme-companion however states that this port is a requirement without explanation as to why?

I understand most users probably use this to provision certificates for web services, but what about container setups where no HTTPS traffic is served, but secure TLS connections over other ports are handled? (by those containers directly, eg mail server and IoT services)

Am I right to assume that port 443 is not necessary on nginx-proxy if no HTTPS traffic is served? I had a look through the provisioning scripts and acme.sh only seems to support being called by --webroot (HTTP-01), no DNS or HTTPS/443 (TLS-ALPN-01) challenges.

I know that nginx-proxy paired with acme-companion for managing cert provisioning/renewals is unorthodox, but due to it's popularity I am documenting it as one of the approaches. I just want to clearly state if port 443 is only useful to those following the guide, if they use nginx-proxy for other services that handle HTTP traffic.

[buchdag]

Hi.

The ACME domain validation challenge specs are governed by the CA/Browser forum's ballots.

The ballot that governs Let’s Encrypt’s HTTP-01 validation is Ballot 169, which explicitly states the following.

Confirming the Applicant’s control over the requested FQDN by confirming one of the following under the “/.well-known/pki-validation” directory, or another path registered with IANA for the purpose of Domain Validation, on the Authorization Domain Name that is accessible by the CA via HTTP/HTTPS over an Authorized Port:

• The presence of Required Website Content contained in the content of a file or on a web page in the form of a meta tag. The entire Required Website Content MUST NOT appear in the request used to retrieve the file or web page, or

• The presence of the Request Token or Request Value contained in the content of a file or on a webpage in the form of a meta tag where the Request Token or Random Value MUST NOT appear in the request.

The aforementioned authorized Port are defined as follow:

Authorized Port: One of the following ports: 80 (http), 443 (http), 115 (sftp), 25 (smtp), 22 (ssh).

As for the ACME specification for HTTP-01, they state the following:

The server SHOULD follow redirects when dereferencing the URL.

So ACME HTTP-01 most probably does follow redirections (to the best of my knowledge Let's Encrypt implementation does), and this redirection can only be to port 443. The requirement was made in the docs to avoid being flooded by issues from people who use a non standard HTTPS port and experience authorization failure because of this.

If you never actually serve HTTPS traffic (which mean you MUST generate ALL your certificate through the standalone certificate feature) then yes I guess you can ignore the port 443 requirement. But if you use the LETSENCRYPT_HOST variable on a running container to get a certificate with a closed / filtered port 443 on the host, in the current way nginx-proxy and acme-companion interact with one another you'll be at risk of getting authorization errors. I don't have the exact chain of events in mind so I can't tell you if you'll most likely experience them on first issuance or on renewal.

[polarathene]

I'm pretty sure that I provisioned a cert via LETSENCRYPT_HOST with only port 80 open via the HTTP-01 challenge, although I only tested on the staging endpoint. Handling 80=>443 redirections makes sense for when nginx-proxy is used to serve web traffic though.

Cheers for the detailed response!

[buchdag]

I'm fairly certain that having a closed port 443 / HTTPS on another port than 443 won't be an issue on first issuance of a given certificate because at this point it should happen entirely over port 80, I'm more concerned about renewals. That's when the nginx-proxy redirection to HTTPS will kick in because of the pre existing certificate (wether you actually use it or not, if you use LETSENCRYPT_HOST without further setting, this redirection WILL exist) , the authorization process will follow it, encounter either a closed or non authorized port, then fail.

[buchdag]

If you use nginx-proxy + acme-companion to obtain certificates for non HTTP / HTTPS services, I strongly encourage you to look at the standalone certificate feature if you're not already using it.

LETSENCRYPT_HOST is meant for HTTP/HTTPS services that will be automatically proxied through nginx-proxy and only for them.

[buchdag]

I modified the docs to point to this discussion for port 443 requirement and Let's Encrypt explanations for port 80 requirement.