Port defaults to 2015 when using tls self_signed

[francislavoie]

1. What version of Caddy are you using (caddy -version)?

0.10.2

2. What are you trying to do?

Use Caddy with tls self_signed, just the domain as the address

3. What is your entire Caddyfile?

example.com {
    ...
    tls self_signed
}

4. How did you run Caddy (give the full command and describe the execution environment)?

Dockerized

5. Please paste any relevant HTTP request(s) here.

N/A

6. What did you expect to see?

Caddy listening on ports 80 and 443

7. What did you see instead (give full error messages and/or log)?

Caddy listens only on port 2015

8. How can someone who is starting from scratch reproduce the bug as minimally as possible?

See Caddyfile above

---

In the docs, there's this line:

The default port is 2015 (unless the site qualifies for automatic HTTPS, in which case it's changed to 443).

The workaround is to prepend the hostname with https://.

I would argue that Caddy should consider self_signed as "automatic HTTPS", for the purposes of port assignments, if no port is specified. I'm pretty sure the same behaviour can be observed when using an existing cert and key. I think it's inconsistent/confusing behaviour that it works like this. Is there a specific reason why it only defaults to 80 and 443 on automatic TLS and not on other modes?

[mholt]

I figure the simplest description of "automatic" is ... automatic: it just works, you don't do anything. Once you start configuring it, it's not automatic. If you are configuring it, you "must" know what you're doing, so we hand the reins over to the user. This is simpler than drawing a line halfway in the spectrum and saying, "this and this and this is automatic, but this and this and this isn't."

If you touch it, it's not automatic anymore.

Nice question!

[francislavoie]

Fair enough re: definition of automatic, but is there a reason why other TLS modes don't default to port 80->443 if https:// is not included? I just think that's a poor default if TLS is on at all. That's more what I have a problem with, not so much the definition of automatic.

[mholt]

is there a reason why other TLS modes don't default to port 80->443 if https:// is not included?

Some people don't want to run TLS on port 443. Or 2015. We have to choose a port, though, so might as well just keep it simple and say the default port is 2015.

[francislavoie]

I'm gonna leave my original message intact below, just because I'd feel bad deleting it all after having typed it up 😛

I figured out that the -port cli arg lets me do exactly what I wanted, replace the default port from 2015 to 443. I think this could be better documented here, so I'll probably make a PR for that later.

---

Alright. Regarding your following point:

If you are configuring it, you "must" know what you're doing, so we hand the reins over to the user.

That's what I think when I expect the default to be 443. That's the default HTTPS port, I feel like it makes more sense to default to the "default", and let users who actually want a different port to just pick it in that case.

A bit of an aside, is there a reason for the default port being 2015 and not 80? I don't see any mention of that in the docs, I feel like that could use some explanation somewhere.

Wait - never mind, disregard the above question, I think I guessed the answer: 2015 is default because usually low ports can't be bound if the user doesn't have root. Follow-up to that, could we default to 80/443 if Caddy does have the low ports capability?

To clarify a bit more why I'm bringing this up - I use environment variables to configure my application. Caddy runs in Docker, I expose ports 80 and 443 in Docker. I allow configuration of TLS via import, if you remember. I just have the expectation that Caddy will bind to ports 80/443 regardless of the TLS config.

Another possible idea, a command line arg to force it to default to 80/443 unless specified otherwise?

[Zakay]

I totally expected Caddy to listen for both 80, 443 when using self signed. I was migrating from nginx to caddy on our local dev-env but this just made it not "automatic" and not "just works". I have it running on docker too.

[frankh]

Even worse, caddy defaults to :2015 if given a valid certificate manually (using tls /path/to/cert.crt /path/to/key.key). This is completely unexpected, and a pain to work around (You have to split the blocks to http:// and https:// and manually set up the http -> https redirect)

https should always default to 443

[zx1986]

Why this issue closed ...

[elcore]

Why this issue closed ...

Once you start configuring it, it's not automatic. If you are configuring it, you "must" know what you're doing, so we hand the reins over to the user.

That's the reason, you'll have to manage Caddy yourself.

[Zakay]

Sure, but you kinda can't avoid configuring it! As soon as you start creating your first caddy configuration file. Anyway this mess could be avoided if the autoredirect was easier to add as an option. One configuration key and sane default values would make it so much better.

For them being we went back to nginx due to the way issues are handled in this project.

Hopefully that gets resolved as the project mission is nice!

[mholt]

@Zakay

Sure, but you kinda can't avoid configuring it!

I was referring to the HTTPS-related configuration, such as the site's TLS settings. I suspect the vast majority of users never have to touch that configuration (although telemetry will tell us for sure).

For them being we went back to nginx due to the way issues are handled in this project.

What would you like to see different about it?

[frankh]

@mholt imo the problem is really this:

With auto https (letsencrypt etc), it's super easy to set up a site properly with http redirection

Without it, it's a nightmare, you need 2 separate website blocks, a manual redirect, all the ports set manually.

imo this block:

example.com {
  tls /cert /key # ( or tls self_signed)
  root /path
}

Should "just work" as expected, as if the tls command wasn't there (that is, bind to 80/443 if possible and redirect http to https)

[ubruhin]

@mholt The current behavior is really annoying, why should the use of self-signed certificates disable the automatic HTTP->HTTPS redirection?

Consider following scenario: You manage a webserver and use a separate staging server to test the configuration before deploying it to the production server. The production server is accessible from the internet, but the staging server not (could be a local virtual machine). So for the production server, Caddy should obtain certificates from Lets Encrypt, but on the staging server it must use a self-signed certificate.

This setup is currently not possible with Caddy, because as soon as you add tls self_signed to the Caddyfile, HTTPS->HTTP redirection is disabled and port is changed to 2015! So the behavior of production and staging setup is completely different, just because of the tls self_signed statement.

[Zakay]

@mholt

I was referring to the HTTPS-related configuration, such as the site's TLS settings. I suspect the vast majority of users never have to touch that configuration (although telemetry will tell us for sure).
And I was referring to the kind of thinking regarding this matter. Changing the delivery method of certification should not affect other features and default settings such as auto-redirect and port config.

What would you like to see different about it?

For on thing: Things like these, the expected behaviour is very far from what you get. Like this cert thing. Doing something totally unexpected should require good motivation from the person suggesting it. Instead people are being asked to motivate and give examples on why they want something to work as expected. Default behaviour is port being 443,

Secondly: When we experience issues with php-fpm and caddy, things weren't investigated by the team at caddy. Motivation behind it was something along "we don't use php". And of course I get it, if you don't have any production environment with php, its going to be difficult for you to reproduce the error. But I would have loved if I got debug binaries or anything to help us find the issue and solve it. I would gladly help, as I love the core ideas of this project. I still do, but currently can't use it.

[dusty]

Here is how I do it with custom ssl. Specify both ports in the hostname part, then add that redir if they aren't on ssl. That way you don't have to do two blocks.

*.example.com:80, *.example.com:443 {
  root /app/html
  errors stderr
  log stdout
  cors
  gzip
  redir 301 {
    if {scheme} not https
    / https://{host}{uri}
  }
  tls {
    load /app/ssl
  }
  proxy / api {
    transparent
    except /app
  }
}

[frankh]

thanks @dusty, certainly better than how i've been doing it but I still think that it should be the default

[dbpolito]

I agree here, default http -> https should be kept on auto_signed, here is how i'm doing:

0.0.0.0:80, 0.0.0.0:443

redir 301 {
    if {scheme} not https
    / https://{host}{uri}
}

tls self_signed
root /data/public
index index.php
gzip

fastcgi / app:9000 php

rewrite {
    to {path} {path}/ /index.php?{query}
}

log stdout
errors stdout

[virtualdxs]

@mholt Please reconsider this. I like how simple it is to just have it do the redirect and everything. I don't like having to manually set that up.

[ctaoist]

@mholt
Please reconsider this. I like how simple it is to just have it do the redirect and everything. I don't like having to manually set that up.