How to do the challenge with a different port?

I’m trying to run caddy on a server which only has one port forwarded from the outside (let’s say port 8033). I want to run an https site there, however I’m having issues getting the acme challenge working:

What I do currently:

My caddy args:

caddy -agree=true -https-port 8033 -disable-http-challenge

From what I understand, -https-port would change the SNI challege port with -disable-http-challenge on (which forces https challenge).

My Caddyfile:

https://sub.domain.tld:8033 {
    root /var/www

But with this setup I’m stuck at

acme: Trying to solve TLS-SNI-01

Anything I’m missing?

Which port are you forwarding to 8033?

Hey Matt, I’m transfering 8033 on router → 8033 on machine

You need to transfer 443 → 8033. :wink:

Sorry if my question wasn’t clear, I’m trying to change the acme port to be 8033

I’m basically looking for the equivalent of:

Port Usage

By default lego assumes it is able to bind to ports 80 and 443 to solve challenges. 
If this is not possible in your environment, you can use the --http and --tls options to instruct lego to listen on that interface:port for any incoming challenges.

in lego:

Hi @arandorap, from what I’m understanding you want to run a HTTPS site publically on port 8033 and have LetsEncrypt issue the ACME challenge to that port.

This isn’t possible. LetsEncrypt must validate your website on port 80 or 443. Alternately, you can use DNS to validate ownership.

Alternately, if you have port 443 available at the edge of your network, but must pass it to port 8033 on your Caddy host inside the network, the Caddy equivalents that you’re looking for are the -http-port [number] and -https-port [number] flags, and this should work as long as you’ve forwarded traffic from [your-website]:443 → [caddy-host]:8033 as @matt mentioned.

@Whitestrake okay so I guess this isn’t implemented in caddy. I think I remember that last time I had to use lego for the cert management, and tell caddy where the certs were

@arandorap, unless I’m mistaken, those flags I gave you are indeed equivalent to xenolf/lego's options. lego shouldn’t be able to tell LetsEncrypt to use a different public port, because LetsEncrypt itself does not allow domain validation for non standard ports.

To clarify further, both xenolf/lego and Caddy’s flags do effectively the same thing - they set the server to listen to the specified port for that class of traffic. Neither have the capability to instruct LetsEncrypt to change which port to issue a challenge to. For consideration, from the ACME draft specification, emphasis mine:

8.3. HTTP Challenge

Given a challenge/response pair, the server verifies the client’s control of the domain by verifying that the resource was provisioned as expected.
3. Dereference the URL using an HTTP GET request. This request MUST be sent to TCP port 80 on the HTTP server.

8.4. TLS with Server Name Indication (TLS SNI) Challenge

Given a challenge/response pair, the ACME server verifies the client’s control of the domain by verifying that the TLS server was configured appropriately, using these steps:
2. Open a TLS connection to the domain name being validated, presenting SAN A in the SNI field. This connection MUST be sent to TCP port 443 on the TLS server.

Oh darn, you’re right – I guess when I tried it, port 443 wasn’t blocked.

In this case maybe it’s better that I have one machine respond to 443 which would generate the cert for the subdomain and then distribute it internally

If you can have that one machine forwarding traffic from 443 to your Caddy host instead, you’re golden - just disable the HTTP challenge with -disable-http-challenge to force LetsEncrypt to use TLS-SNI.

The benefits:

  • Don’t need to use tls subdirectives to import the right key/cert for each site
  • Don’t need to worry about naming/dir structure/perms when (re)distributing
  • Don’t need to worry about manually refreshing and redistributing later on

That’s exactly what I’ll do, thanks for the advice!

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