TLS-SNI-01 challenge on custom port?


#1

Please fill out the fields below so we can help you better.

My domain is: internal.phenom-world.com

I ran this command: sudo letsencrypt --apache --tls-sni-01-port 4343 -d internal.phenom-world.com

It produced this output: Detail: Incorrect validation certificate for TLS-SNI-01 challenge.
Requested bc73b5a206b320d5eaf112b260b4a2f3.de805ebe7cec2b53b847378e
fce3e971.acme.invalid from 88.159.5.253:443. Received certificate
containing ‘remote.phenom-world.com, www.remote.phenom-world.com

My operating system is (include version): Ubuntu 16.04

My web server is (include version): Apache 2.6

My hosting provider, if applicable, is: N/A

I can login to a root shell on my machine (yes or no, or I don’t know): yes

================

I already read the posting titled “TLS-SNI-01 challenge failed due to not able to listen on port 443”. In my case, I’m using an internal server on a vm which is accessible from the outside on the custom port 4343. If I understand correctly, Let’s Encrypt tries to talk to my server but uses port 443 so it will get the “real” server (and not my vm), which knows nothing about what we’re trying to do.

I specified --tls-sni-01-port 4343 - this doesn’t work?


#2

--tls-sni-01-port is a client-only flag, it does not affect the validation server. Validation will always be performed on port 443 for TLS-SNI-01. The flag is useful if (as an example) you want to use a different port locally and then have your firewall forward your external port 443 to that internal port.

If you’re unable to use both port 80 and 443, you’ll need to look into the DNS-01 challenge.


#3

The port parameter you’ve set is for load balancers or protocol adaptors at the edge which can reflect an internal high port to an external low port. If you had a device (or software) which was between you and the Internet reflecting your internal port 4343 as the port 443 on another IP address for example then this feature would be suitable for you.

Let’s Encrypt doesn’t allow you to use other ports to verify. The Baseline Requirements (rules shared by Public CAs including those operated by governments, commercial providers and Let’s Encrypt) were recently updated to explicitly forbid this sort of verification for all CAs (from April 2017), and more recently still we had incidents including with WoSign (which you might have seen in the news) in which certificates were miss-issued based on an ordinary user of a machine being able to obtain certificates for that machine by simply starting a server on a high numbered port.

You might consider whether DNS-01 is better for the problem you have, or whether you can re-use whichever certificate protects the service on port 443 already.


#4

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.