Acme.sh error with alpn mode

Help
1

Debian buster mail server with iptables firewall, port 4242 opened and checked with netcat, last version of acme.sh with the command:

acme.sh  --issue  -d mail.fabioferrero.it  --alpn --tlsport 4242   --listen-v4

I cannot got the certificate verification, I attach the debug log.acme.err.log.txt (88.8 KB)
What's wrong?

Thanks...

2

This sounds like an issue that should be reported through the acme.sh support channels, which really aren't here. The issue tracker for acme.sh is at:

2 Likes
3

The Let's Encrypt API server gives you this error message:

Timeout during connect (likely firewall problem)

When trying to connect to mail.fabioferrero.it, which LE resolved to 217.61.59.235. TLS-ALPN-01 challenges are always validated on port 443.

I see that you're using a different port in acme.sh (4242). This is fine, as long as you have some forwarding in place that forwards port 443 to your internal port (4242). Please double check that you have such a forwarding in place, or configure acme.sh to listen on port 443.

1 Like
4 
When trying to connect to mail.fabioferrero.it, which LE resolved to 217.61.59.235. TLS-ALPN-01 challenges are always validated on port 443.

Oh, thanks, but I don't remember reading this in the documentation. I'll try as soon as possible!

2 Likes
5

I've opened port 443 and now works well!

Thanks.

ps. will be convenient to have authorization fully works on different port than 80 and 443.

2 Likes
6

The acme.sh documentation can be rather poor, yeah.

This is mostly a legal thing. RFC 8737 states for the TLS-ALPN-01 challenge:

The ACME server initiates a TLS connection to the chosen IP address.  This connection MUST use TCP port 443.

Similar statement exist in RFC 8555 for the HTTP-01 challenge (must use port 80).

Back when ACME was standarized, there were discussions whether to allow other ports to 80 and 443. These suggestions did not make it into the standards/requirements however. Unless the rules are changed, Let's Encrypt can't do anything.

The only way to not use port 80 or 443 is to use the DNS-01 challenge.

2 Likes
7

In addition to the above: these restrictions aren't thought up by Let's Encrypt nor by the RFCs themselves, but are mandated by the CA/Browser Forum Baseline Requirements.

2 Likes
8

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