Caddy will refuse to run

Help
1

This was working fine before I upgraded to latest caddy today:

rom.quark.business {
        log /var/log/caddy/rom-quark-business.log {
                rotate {
                size 1  # Rotate after 1 MB
                age  7  # Keep log files for 7 days
                keep 1  # Keep at most 1 log files
                }
        }
        header / {
                Strict-Transport-Security "max-age=31536000"
                X-XSS-Protection "1; mode=block"
                X-Content-Type-Options "nosniff"
                X-Frame-Options "DENY"
        }
        tls {
                key_type rsa4096
                ciphers ECDHE-ECDSA-AES256-GCM-SHA384
                protocols tls1.2
                curves p384
                must_staple
        }
        root /var/www/html
}

git.quark.business {
        log /var/log/caddy/git-quark-business.log {
                rotate {
                size 1  # Rotate after 1 MB
                age  7  # Keep log files for 7 days
                keep 1  # Keep at most 1 log files
                }
        }
        header / {
                Strict-Transport-Security "max-age=31536000"
                X-XSS-Protection "1; mode=block"
                X-Content-Type-Options "nosniff"
                X-Frame-Options "DENY"
        }
        tls {
                key_type rsa4096
        }
        proxy / http://127.0.0.1:3000 {
                transparent
        }
}

Now will refuse to start with:

2017/04/26 05:30:00 Caddyfile:3 - Parse error: Unexpected token '{', expecting argument

What could it be?

2

Hmm, noticed that log has changed (are any of these changes documented somewhere on a change log?). Changed:

 log /var/log/caddy/git-quark-business.log {
                rotate {
                size 1  # Rotate after 1 MB
                age  7  # Keep log files for 7 days
                keep 1  # Keep at most 1 log files
                }

To:

 log /var/log/caddy/git-quark-business.log {
                rotate_size 1  # Rotate after 1 MB
                rotate_age  7  # Keep log files for 7 days
                rotate_keep 1  # Keep at most 1 log files
}

And the error went away, but it will still refuse to start with systemctl start caddy. If I run caddy on /etc/caddy/ (where Cadddyfile is), it runs fine. What next?

3

Error is:

â—Ź caddy.service - Caddy HTTP/2 web server
   Loaded: loaded (/etc/systemd/system/caddy.service; enabled; vendor preset: enabled)
   Active: inactive (dead) (Result: exit-code) since Wed 2017-04-26 05:45:04 EDT; 2s ago
     Docs: https://caddyserver.com/docs
  Process: 42204 ExecStart=/usr/local/sbin/caddy -log stdout -agree=true -conf=/etc/caddy/Caddyfile -root=/var/tmp (code=exited, status=1/FAILURE)
 Main PID: 42204 (code=exited, status=1/FAILURE)

Apr 26 05:45:03 rom.quark.business systemd[1]: caddy.service: Main process exited, code=exited, status=1/FAILURE
Apr 26 05:45:03 rom.quark.business systemd[1]: caddy.service: Unit entered failed state.
Apr 26 05:45:03 rom.quark.business systemd[1]: caddy.service: Failed with result 'exit-code'.
Apr 26 05:45:04 rom.quark.business systemd[1]: caddy.service: Service hold-off time over, scheduling restart.
Apr 26 05:45:04 rom.quark.business systemd[1]: Stopped Caddy HTTP/2 web server.
Apr 26 05:45:04 rom.quark.business systemd[1]: caddy.service: Start request repeated too quickly.
Apr 26 05:45:04 rom.quark.business systemd[1]: Failed to start Caddy HTTP/2 web server.
4

Rebooting the server made it work again. Why would a reboot be needed?

5

Also, this doesn’t work anymore:

       tls {
                key_type rsa4096
                ciphers ECDHE-ECDSA-AES256-GCM-SHA384
                protocols tls1.2
                curves p384
                must_staple
        }

Had to change it to:

       tls {
                key_type rsa4096
                protocols tls1.2
                must_staple
        }

For it to work. Why?

6

Hi @Fastidious -

Yes, of course; always read the release notes when new versions come out, especially before a stable 1.0.:

We’ve also changed the syntax of the log and errors directives to be more similar and flattened the options for log rotation.

  • errors, log: Standardized, simplified directive syntax

No idea, probably a systemd thing because Caddy reloads fine without it and without needing for the whole machine to be rebooted.

What odes “doesn’t work” mean?

7

Caddy will refuse to run/start. After removing those lines, it started.

Do you have a link to the release notes? Could not find it.

8

The release notes are in CHANGES.txt that are distributed with every Caddy download, but also always available on GitHub: Releases · caddyserver/caddy · GitHub and for significant releases there is a blog post with information. (A quick Google search for “Caddy release notes” would bring these up too ;))

Help me out - I’m looking for an error message here. What’s the error?

9

I added those lines back on a test server. Safari will simply say that can’t establish a secure connection. Chrome spits out:

"rom.quark.business uses an unsupported protocol.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH”

There are no errors server side.

10

But that worked just fine before 0.10.0.

11

Thanks, that’s much more helpful. :slight_smile: There would be errors on the server side, if you’re reading the logs – make sure you enable the logs with the -log flag.

I see the same thing here, but I’m not sure why it would have changed in 0.10…

12

This is what it gets on the log (running caddy -log /tmp/dump.txt:

2017/04/26 11:07:09 http: TLS handshake error from 132.170.26.39:58031: tls: no cipher suite supported by both client and server
2017/04/26 11:07:09 http: TLS handshake error from 132.170.26.39:58032: tls: no cipher suite supported by both client and server
2017/04/26 11:07:09 http: TLS handshake error from 132.170.26.39:58033: tls: client offered an unsupported, maximum protocol version of 301
2017/04/26 11:07:09 http: TLS handshake error from 132.170.26.39:58034: tls: client offered an unsupported, maximum protocol version of 301
13

I’m seeing it too – looking into it now.

1 Like
14

Okay, so, this is an easy explanation. I didn’t catch this before in your config:

ECDHE-ECDSA-AES256-GCM-SHA384 is the only cipher suite you’re allowing, but your certificate is RSA. You can’t use a wholly elliptic cipher suite with an RSA key; while it can use EC for key exchange, the asymmetric encryption (for the signature) has to use an RSA key, so ECDSA won’t be used.

So add ECDHE-RSA-AES256-GCM-SHA384 to your cipher suite list.

This is one reason why I urge caution when adjusting the TLS configuration. The defaults are sane, I suggest sticking to them unless you’re really careful.

15

That is odd, though. How would we explain the fact that it was working fine before 0.10.0?

16

Because in Go 1.8 we can finally customize each site’s TLS config, rather than having to combine them all that share a listener. So it unioned cipher suites before, meaning that another site had a more generous cipher suite selection.

1 Like
17

Mystery solved then. Hopefully it might be of use to others. Thanks!

18

A reboot is not needed. Run:

# see whether other services failed
systemctl --failed

systemctl reset-failed
systemctl start caddy
1 Like
19

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