Hi @willmanley,
This issue has been discussed quite a bit before, for example at
Support for ports other than 80 and 443 Feature Requests
H…
Port 80 and 443 Blocked By ISP - How to authenticate domain?
P…
Generate certificate 8443 instead of 443 Help
H…
You said
willmanley:
The basic method work well for the majority but surely advanced system admins should have an advanced method for doing a simple override like this.
This makes it sound like you think that the port limitation is only enforced by client software, but in fact it's a CA-side policy inspired by several factors. The CA policy issue was discussed at
github.com/letsencrypt/acme-spec
Issue: allow ports other than 443.
opened by dnozay
on 2014-11-27
closed by bifurcation
on 2015-11-13
enhancement
and may still be under discussion in the IETF ACME working group. The security reasons mentioned include shared hosting environments where non-administrators are allowed to run services on ports other than 80 and 443 (almost always only >1023 on Unix systems), and protocol-in-protocol attacks where someone might be able to trick a server for some other kind of service into behaving sufficiently like an ACME client in order to make it pass the challenge. Thus, the CA is not willing to permit this lightly.
What's more, folks at the CA/Browser Forum have also insisted that new verification methods can't be added by a CA without prior discussion there, and have effectively also included the port numbers as one of the aspects requiring prior approval.
See section 3.2.2.4 of https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf, which defines all of the validation methods that CAs are permitted to use. If Let's Encrypt made a unilateral decision to add new validation methods, it might be considered to violate the Baseline Requirements.
So there are a lot of people, almost all of them outside of this forum, who would have to be convinced before challenges to other ports would be permitted.