Tls alpn challenge on non-standard https port (8080)

[kristoiv]

Is it right that tls-alpn-01 only supports port 443?

I’ve been running my https services using eg. port 8080. However the challenges sent from letsencrypt go straight to port 443 now.

I’m using the current head of golang.org/x/crypto/acme as my client library. My requests that start the certificate issuance come in on https://mydomain.com:8585 (which makes GetCertificate to be called, and letsencrypt is asked to issue a certificate), but letsencrypts challenges come in to https://mydomain.com:443.

Is this a client bug or is 443 non-optional?

[mnordhoff]

It’s non-optional. CAs are only allowed to use a few different ports for validation.

If you can’t arrange the necessary port forwarding or something, you’re stuck with DNS validation.

[kristoiv]

Thanks mnordhoff. Do you have any documentation on this? What other ports are available? I primarily just need there to be two different ones cause of architecture/technical debt -reasons.

[mnordhoff]

The ACME standard (and TLS-ALPN-01 draft) and Let’s Encrypt just use the standard DNS, HTTP and HTTPS ports – 53, 80 and 443.

(I’m not sure it explicitly says to make DNS queries using port 53, but it’s implied at least.)

The Baseline Requirements also allow CAs to use the standard SSH and mail ports, but Let’s Encrypt doesn’t do anything with them.

[schoen]

The reason for this in the BRs is partly the challenge in figuring out who speaks for whom in shared hosting enviroments. Many shared hosting environments would allow any customer to bind ports >1023, which would then apply to every name pointed at the same server. The BRs are basically relying on traditions about semantics of particular ports in order to prevent one shared hosting customer from obtaining a certificate for another customer’s domain name—which has also been a significant source of concern for Let’s Encrypt in designing the challenge methods.