Why isn't Caddy redirecting between hosts with this config?

Hi there. I have a problem: with the Caddyfile below, the redirects I’ve set up in the last two definition blocks don’t work. For example if I go to http://ellipsix.com then I get a page with “No such site at :80” instead of getting redirected to http://www.ellipsix.net, and similarly for all the domains in the third block (ellipsix.net and www.ellipsix.com). And if I go to the HTTPS version, https://ellipsix.com, I get a security warning from the browser because Caddy sends the certificate associated with www.ellipsix.net. I’m not sure if these are related or separate problems (but guessing the former for purposes of titling this post).

Am I missing something in the Caddyfile that I need to make the redirections work?

The first two blocks, with the proxy directives, work great. It’s just the redirections that are the problem.

www.ellipsix.net:80 static.ellipsix.net:80 www.zombiedynamics.com:80 {
        tls off
        proxy / localhost:8080 {
                transparent
        }
}

www.ellipsix.net:443 static.ellipsix.net:443 www.zombiedynamics.com:443 {
        tls tls@ellipsix.net
        proxy / localhost:8080 {
                transparent
        }
}

ellipsix.net:80 ellipsix.com:80 www.ellipsix.com:80 {
        tls off
        redir http://www.ellipsix.net{uri}
}
 
ellipsix.net:443 ellipsix.com:443 www.ellipsix.com:443 {
        tls tls@ellipsix.net
        redir https://www.ellipsix.net{uri}
}

This is with Caddy 0.10.3 on a somewhat outdated Gentoo server. I can provide more details of the environment if it’s relevant.

If I read that caddy file correctly, then the underlying server is the one that needs to do the redirects.

As you’ve written that caddyfile a req for .com gets sent to the backend as a .com request.

I suspect that you want it to send a .net request to the backend.

Hi @diazona,

Are you able to give us the logs from Caddy’s startup? That should tell us which sites Caddy thinks it’s configured to serve.

Also, as an aside - you could, theoretically, massively reduce the complexity of your Caddyfile:

// This will handle HTTP and HTTPS for these labels, redirecting both.
ellipsix.net, ellipsix.com, www.ellipsix.com {
  tls tls@ellipsix.net
  redir https://www.ellipsix.net{uri}
}

// Opinionated - using scheme instead of port, but these are
// interchangable here in terms of Caddyfile configuration.
// Both schemes are specified here, presumably to serve the
// site identically on both HTTP and HTTPS without redirections.
https://www.ellipsix.net, https://static.ellipsix.net, https://www.zombiedynamics.com,
http://www.ellipsix.net, http://static.ellipsix.net, http://www.zombiedynamics.com {
  tls tls@ellipsix.net
  proxy / localhost:8080 {
    transparent
  }
}

Can you clarify how this Caddyfile shows that an ellipsix.com request gets sent through to the backend? I don’t understand how what I’ve written would lead to that. The only definition block labeled with ellipsix.com contains a redir directive but no proxy directive, so I don’t see why caddy would issue a proxy backend request for that domain.

It shouldn’t, it should be issuing a redirect.

There are two explanations for No such site at :80 - either the Caddyfile that Caddy is reading from doesn’t have a label for the requested domain, or your request is incorrect (perhaps a typo). A log of Caddy’s startup will tell us whether or not Caddy thinks it’s supposed to serve http://ellipsix.com, and the answer will help inform us where to look next.

So… it turns out this was a silly albeit convoluted mistake on my part. I’ve been using an initscript to control caddy, but the initscript wasn’t working properly. When I thought I was restarting or reloading caddy, I actually wasn’t, so all along caddy was running with an old version of my Caddyfile that didn’t include the blocks performing the redirection. Now that I manually quit the process and started it up again for real, it is working properly. Sorry about that! Thanks for the help anyway.

Now the log output I get on starting it up is exactly what it should be:

2017/06/11 20:51:30 [INFO][ellipsix.net] acme: Obtaining bundled SAN certificate
2017/06/11 20:51:31 [INFO][ellipsix.net] AuthURL: https://acme-v01.api.letsencrypt.org/acme/authz/[redacted]
2017/06/11 20:51:31 [INFO][ellipsix.net] acme: Trying to solve HTTP-01
2017/06/11 20:51:31 [INFO][ellipsix.net] Served key authentication
2017/06/11 20:51:32 [INFO][ellipsix.net] The server validated our request
2017/06/11 20:51:32 [INFO][ellipsix.net] acme: Validations succeeded; requesting certificates
2017/06/11 20:51:33 [INFO] acme: Requesting issuer cert from https://acme-v01.api.letsencrypt.org/acme/issuer-cert
2017/06/11 20:51:33 [INFO][ellipsix.net] Server responded with a certificate.
2017/06/11 20:51:33 [INFO][ellipsix.net] Certificate written to disk: /etc/ssl/caddy/acme/acme-v01.api.letsencrypt.org/sites/ellipsix.net/ellipsix.net.crt
2017/06/11 20:51:33 [INFO][ellipsix.com] acme: Obtaining bundled SAN certificate
2017/06/11 20:51:34 [INFO][ellipsix.com] AuthURL: https://acme-v01.api.letsencrypt.org/acme/authz/[redacted]
2017/06/11 20:51:34 [INFO][ellipsix.com] acme: Trying to solve TLS-SNI-01
2017/06/11 20:51:37 [INFO][ellipsix.com] The server validated our request
2017/06/11 20:51:37 [INFO][ellipsix.com] acme: Validations succeeded; requesting certificates
2017/06/11 20:51:38 [INFO] acme: Requesting issuer cert from https://acme-v01.api.letsencrypt.org/acme/issuer-cert
2017/06/11 20:51:38 [INFO][ellipsix.com] Server responded with a certificate.
2017/06/11 20:51:38 [INFO][ellipsix.com] Certificate written to disk: /etc/ssl/caddy/acme/acme-v01.api.letsencrypt.org/sites/ellipsix.com/ellipsix.com.crt
2017/06/11 20:51:38 [INFO][www.ellipsix.com] acme: Obtaining bundled SAN certificate
2017/06/11 20:51:39 [INFO][www.ellipsix.com] AuthURL: https://acme-v01.api.letsencrypt.org/acme/authz/[redacted]
2017/06/11 20:51:39 [INFO][www.ellipsix.com] acme: Could not find solver for: dns-01
2017/06/11 20:51:39 [INFO][www.ellipsix.com] acme: Trying to solve TLS-SNI-01
2017/06/11 20:51:41 [INFO][www.ellipsix.com] The server validated our request
2017/06/11 20:51:41 [INFO][www.ellipsix.com] acme: Validations succeeded; requesting certificates
2017/06/11 20:51:43 [INFO] acme: Requesting issuer cert from https://acme-v01.api.letsencrypt.org/acme/issuer-cert
2017/06/11 20:51:43 [INFO][www.ellipsix.com] Server responded with a certificate.
2017/06/11 20:51:43 [INFO][www.ellipsix.com] Certificate written to disk: /etc/ssl/caddy/acme/acme-v01.api.letsencrypt.org/sites/www.ellipsix.com/www.ellipsix.com.crt
2017/06/11 20:51:43 https://www.ellipsix.net
2017/06/11 20:51:43 https://static.ellipsix.net
2017/06/11 20:51:43 https://www.zombiedynamics.com
2017/06/11 20:51:43 https://ellipsix.net
2017/06/11 20:51:43 https://ellipsix.com
2017/06/11 20:51:43 https://www.ellipsix.com
2017/06/11 20:51:43 http://www.ellipsix.net
2017/06/11 20:51:43 http://static.ellipsix.net
2017/06/11 20:51:43 http://www.zombiedynamics.com
2017/06/11 20:51:43 http://ellipsix.net
2017/06/11 20:51:43 http://ellipsix.com
2017/06/11 20:51:43 http://www.ellipsix.com

In case it helps anyone else: the problem is that the directory where I told caddy to put its PID file (I was using -pidfile=/var/run/caddy.pid) wasn’t writable by the user caddy was running under, so the PID file wasn’t actually getting created. Then when I used my initscript to stop or reload caddy, because it didn’t find a PID file, it decided that there was no caddy process to stop or reload, and showed an indicator of success despite not actually doing anything. Meanwhile caddy kept running using the old configuration. I didn’t figure it out until I ran pgrep caddy after attempting to stop it with the initscript and kept getting a process ID.

It’s always the init systems…

whoa. well, I’m glad that you got it figured out – as I looked at that conf file longer, and after more coffee, it seemed like it should have worked.

Even better for me to realize that I’m not the only one that does things like that! :smiley:

2 Likes

Except when it’s DNS!

1 Like

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