# Extends protocol to define a specific port for HTTP-01 and/or TLS-ALPN-01? **URL:** \ **Category:** Feature Requests\ **Created:** [June 4, 2023, 1:19am UTC](https://community.letsencrypt.org/t/extends-protocol-to-define-a-specific-port-for-http-01-and-or-tls-alpn-01/199454 "2023-06-04T01:19:44Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![CDuv](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/cduv/32/70914_2.png) [@CDuv](https://community.letsencrypt.org/u/CDuv)\ **Post date:** [June 4, 2023, 1:19am UTC](https://community.letsencrypt.org/t/extends-protocol-to-define-a-specific-port-for-http-01-and-or-tls-alpn-01/199454/1 "2023-06-04T01:19:44Z")
Hi I am wondering if there is a project to allow doing HTTP-01 and TLS-ALPN-01 challenges on a port other than the 80 (http) and 443 (https) defaults? There are issues with using theses default ports in some cases (shared hosting, port already is use by a running web server, …). So something like a new challenge, similar to HTTP-01 and TLS-ALPN-01 but using a well-known IANA-assigned port (say "2263", "ACME" on a phone :P) the ACME servers would contact to check challenges over HTTP or HTTPS (instead of 80/443) could be a good alternative (I guess). Is it something viable? Was it experimented in the past and abandoned? ---
**Author:** ![orangepizza](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/orangepizza/32/19597_2.png) [@orangepizza](https://community.letsencrypt.org/u/orangepizza)\ **Post date:** [June 4, 2023, 1:38am UTC](https://community.letsencrypt.org/t/extends-protocol-to-define-a-specific-port-for-http-01-and-or-tls-alpn-01/199454/2 "2023-06-04T01:38:25Z")
> Authorized Ports: One of the following ports: 80 (http), 443 (https), 25 (smtp), 22 (ssh) > **[CA-Browser-Forum-BR-v2.0.0.pdf](https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-v2.0.0.pdf)** > > 362.56 KB ---
**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\ **Post date:** [June 4, 2023, 2:21am UTC](https://community.letsencrypt.org/t/extends-protocol-to-define-a-specific-port-for-http-01-and-or-tls-alpn-01/199454/3 "2023-06-04T02:21:17Z")
> [@CDuv](#): > > shared hosting, port already is use by a running web server Quite intentionally so. Imagine being a shared hosting customer, and all of a sudden, one of the other customers on the server spins up a webserver on port 45000 and obtain a certificate for your domain. Oops. ---
**Author:** ![schoen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/schoen/32/79_2.png) [@schoen](https://community.letsencrypt.org/u/schoen)\ **Post date:** [June 4, 2023, 3:12am UTC](https://community.letsencrypt.org/t/extends-protocol-to-define-a-specific-port-for-http-01-and-or-tls-alpn-01/199454/4 "2023-06-04T03:12:19Z")
This approach goes back in some sense to the [well-known ports](https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers#Well-known_ports) concept (where remote systems could use the port number to determine whether a process was being run by a machine's administrator, or by a regular user, in order to decide whether that process could be considered to "speak for" the machine). But of course the authorized port concept has taken the concept further and been stricter about it, while still having the same basic goal. ---
**Author:** ![MikeMcQ](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mikemcq/32/52772_2.png) [@MikeMcQ](https://community.letsencrypt.org/u/MikeMcQ)\ **Post date:** [June 4, 2023, 3:29am UTC](https://community.letsencrypt.org/t/extends-protocol-to-define-a-specific-port-for-http-01-and-or-tls-alpn-01/199454/5 "2023-06-04T03:29:25Z")
For those unusual cases there is always the DNS Challenge With a good DNS provider it is fairly straight-forward although usually a little more involved to automate. ---
**Author:** ![CDuv](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/cduv/32/70914_2.png) [@CDuv](https://community.letsencrypt.org/u/CDuv)\ **Post date:** [June 4, 2023, 12:30pm UTC](https://community.letsencrypt.org/t/extends-protocol-to-define-a-specific-port-for-http-01-and-or-tls-alpn-01/199454/6 "2023-06-04T12:30:49Z")
> [@\_az](#): > > Imagine being a shared hosting customer, and all of a sudden, one of the other customers on the server spins up a webserver on port 45000 and obtain a certificate for your domain. Oops. I guess shared hosting provider could block this **well-known port** to disallow any use of ACME client with this kind of challenge because it's not compatible with it's service. > [@schoen](#): > > This approach goes back in some sense to the well-known ports concept… It was my thought exactly: we have ports for each specific usages (Whois, DHCP, WoL, time, SNMP, BGMP, …), why not for ACME/certificate usages? > [@MikeMcQ](#): > > For those unusual cases there is always the DNS Challenge Yes, but the DNS challenge has it's own issues too, like: latency, compatibility, etc. ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [June 4, 2023, 3:11pm UTC](https://community.letsencrypt.org/t/extends-protocol-to-define-a-specific-port-for-http-01-and-or-tls-alpn-01/199454/7 "2023-06-04T15:11:51Z")
> [@CDuv](#): > > I guess shared hosting provider could block this **well-known port** to disallow any use of ACME client with this kind of challenge because it's not compatible with it's service. It's too much of a risk to leave such a thing to the (shared) hosting providers. I can't see into the future, but I don't see the CA/Browser Forum changing this Baseline Requirement changing anytime soon. And as said before, Let's Encrypt has to abide to these requirements. ---
**Author:** ![schoen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/schoen/32/79_2.png) [@schoen](https://community.letsencrypt.org/u/schoen)\ **Post date:** [June 4, 2023, 11:25pm UTC](https://community.letsencrypt.org/t/extends-protocol-to-define-a-specific-port-for-http-01-and-or-tls-alpn-01/199454/8 "2023-06-04T23:25:52Z")
Specifically, it would be hard to introduce now because it would be hard to get all of the shared hosting providers to be aware of what it is and what it means. Let's Encrypt has already disabled or replaced _two_ different existing or proposed proof-of-control challenge methods because of shared hosting providers' empirical behavior (that created a possibility that one customer could pass a challenge for another customer's domain). And since false positive certificate issuance is considered drastically worse than false negative certificate denial, the motivation to get hosting providers to change their behaviors is kind of lacking (both for Let's Encrypt and for the CA/B Forum, I expect). Since I'm doing a consulting project related to an attempt to update old Internet standards in a non-fully-backwards-compatible way, I can feel the sadness in the fact that it's challenging to get all of the Internet sites to pay attention to present-day conversations about new proposed standards and best practices! It's really annoying and unfortunate sometimes. Although I think in the certificate issuance case, Let's Encrypt's current options ultimately work decently for a _huge_ portion of the web sites that want certificates. ---
**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\ **Post date:** [June 5, 2023, 4:41pm UTC](https://community.letsencrypt.org/t/extends-protocol-to-define-a-specific-port-for-http-01-and-or-tls-alpn-01/199454/9 "2023-06-05T16:41:19Z")
> [@CDuv](#): > > Is it something viable? Not really. I have suggested this many times in the past. You can see an entire discussion about this on the following thread, which started on a port25 challenge: [Http challange on port 25? - #13 by orangepizza](https://community.letsencrypt.org/t/http-challange-on-port-25/192385/13) There are few other threads this has come up on, but that thread covers almost every concept. I am 100% behind the idea of an RFC defining a dedicated port for an "acme-challenge", as that would handle the problems you suggested. This would require the port to be reserved/privileged, so only server administrators could obtain the certificate. The big issue is that the "well-known" reserved/privileged ports are not consistent across operating systems and operating system versions. There are a handful of random operating system versions where ports \<1024 do not require admin privileges for binding. There are **very few** ports under 1024 which are commonly privileged across most systems. @_az has been working on a great idea introduced in this post - [Using nfqueue on Linux as a novel, webserver-agnostic HTTP authenticator](https://community.letsencrypt.org/t/using-nfqueue-on-linux-as-a-novel-webserver-agnostic-http-authenticator/192625) - which uses nfqueue to bypass port80 traffic to get around the issue of port80 being already used. ---
**Author:** ![CDuv](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/cduv/32/70914_2.png) [@CDuv](https://community.letsencrypt.org/u/CDuv)\ **Post date:** [June 21, 2023, 10:51pm UTC](https://community.letsencrypt.org/t/extends-protocol-to-define-a-specific-port-for-http-01-and-or-tls-alpn-01/199454/10 "2023-06-21T22:51:16Z")
Thanks @jvanasco for the history: it was this kind of stuff I was sure someone already had thought about and I failed to find. The _nfqueue hack_ seems a good alternative in my use case, and another tool in the ACME toolbox in general 👍 ---
**Author:** ![mholt](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mholt/32/70171_2.png) [@mholt](https://community.letsencrypt.org/u/mholt)\ **Post date:** [June 21, 2023, 10:59pm UTC](https://community.letsencrypt.org/t/extends-protocol-to-define-a-specific-port-for-http-01-and-or-tls-alpn-01/199454/11 "2023-06-21T22:59:04Z")
> [@CDuv](#): > > There are issues with using theses default ports in some cases (shared hosting, port already is use by a running web server, …). For reasons mentioned above, the best solution here is to use a server with the ACME client integrated natively into it so that port contention is not a problem. 💯 ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [July 21, 2023, 10:59pm UTC](https://community.letsencrypt.org/t/extends-protocol-to-define-a-specific-port-for-http-01-and-or-tls-alpn-01/199454/12 "2023-07-21T22:59:11Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.