Now that TLS-SNI deprecated, how to to "authenticate" via port 443?

Help
1

Now that TLS-SNI is deprecated, is there any way for certbot to authenticate via port 443?
Unfortunately for this particular box, port 80 is blocked.
According to the certbot documentation and meetings where votes were taken, port 443 is supported for authentication…

So curious where this is for now…

Using certbot 0.28.0 I’m getting and running:

sudo certbot certonly --standalone --preferred-challenges tls-sni -d foo.erwin.org`

It produced this output:

Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.

My web server is (include version): apache

The operating system my web server runs on is (include version): Linux (Ubuntu 18.04)

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

2

Unless your hostnames are on the TLS-SNI whitelist (which will go away in a month), no.

Certbot also supports DNS validation with some DNS services.

Some ACME clients support the newer port 443 TLS-ALPN-01 challenge type.

1 Like
3

Could you tell us more about why port 80 is blocked? Is it blocked by your ISP, (and if so, which ISP and region?) or by your own firewall rules?

2 Likes
4

Thank you for that tip @mnordhoff :+1:

I went with acme.sh and got this certificate issued even though port 80 is blocked... (issued via 443)
For anyone else who runs into this, I highly recommend giving acme.sh a shot.

acme.sh --issue --alpn --standalone -d foo.erwin.org

Of course for regular hosting I use actual data centers like Rackspace or Amazon, but for this particular box it's just on an ISP connection... From Viettel Telecom in Ho Chi Minh, Vietnam.

When running nmap on port 80 it shows as filtered while all other ports I've tested just show as open.

Filtered:
Nmap cannot determine whether the port is open because packet filtering prevents its probes from reaching the port. The filtering could be from a dedicated firewall device, router rules, or host-based firewall software. These ports frustrate attackers because they provide so little information. Sometimes they respond with ICMP error messages such as type 3 code 13 (destination unreachable: communication administratively prohibited), but filters that simply drop probes without responding are far more common. This forces Nmap to retry several times just in case the probe was dropped due to network congestion rather than filtering. This slows down the scan dramatically.

3 Likes
5

Awesome, thanks for the additional information!

6

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