Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Regression? Host listening on :2015 with tls defined #651

Closed
zacheryph opened this issue Mar 1, 2016 · 7 comments
Closed

Regression? Host listening on :2015 with tls defined #651

zacheryph opened this issue Mar 1, 2016 · 7 comments

Comments

@zacheryph
Copy link

I have a caddy server with a few domains on it. Two of them use Lets Encrypt, one is using certs (until they expire and I can use lets encrypt on it.) This host has tls certfile.pem keyfile.pem. Caddy v0.8.1 starts up fine with this host listening on :80 and :443. However when I upgraded to v0.8.2 this host is listening on :2015. I did not change my Caddyfile at all.

@abiosoft
Copy link

abiosoft commented Mar 1, 2016

Kindly share the Caddyfile. You can mask hostnames or other private values.

@zacheryph
Copy link
Author

Here is config, output from caddy start up is below. The www. redir possibly is browser cache i never get anything in the caddy logs for the redir even if i add log/errors but i didn't bother to check dev tools in browser.

### WORKING
[REDACT], [REDACT] {
  tls [REDACT]@[REDACT]
  log stdout
  errors stderr

  proxy / rsvp:6060
}

### WORKING
[REDACT] {
  log stdout
  errors stderr
  tls [REDACT]@[REDACT]

  header / {
    Strict-Transport-Security "max-age=31536000; includeSubDomains"
  }

  root /sites/[REDACT]/public
  ext .html
}

### WORKING
www.[REDACT] {
  tls [REDACT]@[REDACT]
  redir https://[REDACT]{uri}
}

### NOT WORKING (listening on :2015)
# ERROR in Browser: No such host at :443
[REDACT] {
  log stdout
  errors stderr
  tls /etc/caddy/ssl/[REDACT].crt /etc/caddy/ssl/[REDACT].key

  header / {
    Strict-Transport-Security "max-age=31536000; includeSubDomains"
  }

  proxy / gogs:3000 {
    websocket
    except /lita
  }

  # hide our lita-bot location
  proxy /lita http://[REDACT]:40080/ {
    without /lita
  }
}

### WORKING (even though log only shows www.[REDACT]:2015 ?!?!)
www.[REDACT] {
  tls /etc/caddy/ssl/[REDACT].crt /etc/caddy/ssl/[REDACT].key
  redir https://[REDACT]{uri}
}

Output from caddy startup

Activating privacy features... done.
[working]:443
www.[working]:443
[working]:443
www.[working]:443
[not-working]:2015
www.[not-working]:2015
[working]:80
www.[working]:80
[working]:80
www.[working]:80

@zacheryph
Copy link
Author

Talked with @abiosoft on gitter. I forcibly defined https://host, http://host and this is working now. Though not entirely sure why this changed, @abiosoft was a little surprised it worked how I had it in the first place.

I'll leave it up to maintainers to do what they wish with this issue. Though I will say the host definition / port / tls option logic can be a little confusing. maybe related to #384

@abiosoft
Copy link

abiosoft commented Mar 1, 2016

I thought Caddy doesn't do automatic http -> https handling/redirect when you specify your own tls certificates, that's only applicable when it is auto.

@zacheryph's Caddyfile looks like this.

site.com {
    tls /path/to/cert.crt  /path/to/cert.key
    ...
}

So I was a bit surprised when he said it's been working pre 0.8.2.

@mholt
Copy link
Member

mholt commented Mar 1, 2016

This is working as expected; Caddy does not enable automatic HTTPS when you bring your own certificates; thus you have to set the port yourself. Caddy treats this as kind of a "manual" mode.

@FiloSottile
Copy link

May I ask for the decision to be reconsidered? It's very surprising to change something as trivial as the certificate and seeing the port change. Principle of least surprise and all that.

@mholt
Copy link
Member

mholt commented May 18, 2016

@FiloSottile Yeah, I'm looking into this with 0.9. Automatic HTTPS has lots of moving parts to make it work, and it's difficult to define which parts belong to "managed TLS" and which parts belong to "TLS" in general.

I'm thinking that enabling TLS -- no matter where the certificates come from -- should still set up the redirection and port just like with fully managed TLS.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants