Letsencrypt behind NAT different port

Hello. I apologize if this has been asked before but I could not find anything related to this situation. I have a self hosted mattermost server I am trying to get installed. All is working quite well and I am running it under NGINX. This service lives behind a firewall with only one static IP. Port 443 is dedicated to an inhouse mail server. Therefore, I am having issues getting the letsencrypt certificate to validate. I believe once I have the certificate I can likely use different ports for “https”. Is it even possible to get a letsencrypt certificate in this scenario where port 443 can not be port forwarded to the server behind the firewall?

mattermost installation indicates to try the following:
stop nginx and make sure nothing is listening on 443
and then issue the command: ./letsencrypt-auto certonly --standalone

However, I receive the following error:

  • The following errors were reported by the server:
    Type: unauthorized
    Detail: Incorrect validation certificate for tls-sni-01 challenge.

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A/AAAA record(s) for that domain
    contain(s) the right IP address.

Any thoughts on this? This server behind NAT issue come up for us before.

The CA/B forum, which makes the rules about certificates and such, demand the verification of the domain to use either port 80 or 443 when using webserver-based verification.

As such, you’re very limited with only a few options:

  • Using port 80 (--preferred-challenges=http) or 443 (--preferred-challenges=tls-sni) directly;
  • Redirect port 80 or 443 to another port (boulder follows redirects to other ports, but webbased verification always begins with a connection to either port 80 or 443);
  • Use the dns-01 challenge and “bypass” webserver verification alltogether.

The certbot repository on github has multiple DNS provider plugins. But I don’t know if those plugins are included in the “normal” distribution of certbot.

@schoen
can i use this as a direct parameter while running certbot .
–preferred-challenges tls-sni-01 --tls-sni-01-port some_port

Last I heard, redirects can only go to 80 or 443.

IIRC, there was a bug that Boulder would follow redirects to any port, but the firewall only allowed 80 and 443 anyway. And it was fixed by making Boulder reject other ports itself.

Probably, but Let's Encrypt will still connect to port 443. --tls-sni-01-port is useful when you're, say, using port forwarding to redirect external port 443 to local port 8443 or something. Certbot will then listen on the specified port (e.g. 8443) but Let's Encrypt will still connect to 443.

2 Likes

Ah, I thought the initial connection had to be to port 80 or 443, but consequent redirects could be any port you'd like. Didn't know it was a bug :grin:

That's correct :+1: - only redirects to 80/443 work.

2 Likes

Thanks very much for the response. So I does not seem this will work using the default settings since let’s encrypt will attempt to come in via 443 to verify and there is a different server on that port redirect.

So if I " Use the dns-01 challenge and “bypass” webserver verification alltogether." will this also work for certificate renewals? Is there any downsides to using this method?

Thanks again

If port 80 is available, you might use the webroot plugin.

Yes, also works for renewals. You'd have to use the dns-01 challenge again during renewal, so if you'd have to update your DNS manually, that's a big downside obviously. If you can automate the dns-01 challenge, there's not really any downside.

I think I was the source of this misinformation a couple of months ago, because I used to think it could be any port until someone from the infrastructure side corrected me on the forum.

Also, the initial redirect can only be from port 80 because the TLS-SNI-01 verification on port 443 doesn't use HTTP and doesn't follow redirects.

2 Likes

Ah, that’s very much true indeed, stupid of me :slight_smile:

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