Fast, multi-platform web server with automatic HTTPS

Overview

Caddy

a project


Every site on HTTPS

Caddy is an extensible server platform that uses TLS by default.


@caddyserver on Twitter Caddy Forum
Caddy on Sourcegraph Cloudsmith

Releases · Documentation · Get Help

Menu

Powered by
CertMagic

Features

  • Easy configuration with the Caddyfile
  • Powerful configuration with its native JSON config
  • Dynamic configuration with the JSON API
  • Config adapters if you don't like JSON
  • Automatic HTTPS by default
    • ZeroSSL and Let's Encrypt for public names
    • Fully-managed local CA for internal names & IPs
    • Can coordinate with other Caddy instances in a cluster
    • Multi-issuer fallback
  • Stays up when other servers go down due to TLS/OCSP/certificate-related issues
  • Production-ready after serving trillions of requests and managing millions of TLS certificates
  • Scales to tens of thousands of sites ... and probably more
  • HTTP/1.1, HTTP/2, and experimental HTTP/3 support
  • Highly extensible modular architecture lets Caddy do anything without bloat
  • Runs anywhere with no external dependencies (not even libc)
  • Written in Go, a language with higher memory safety guarantees than other servers
  • Actually fun to use
  • So, so much more to discover

Install

The simplest, cross-platform way is to download from GitHub Releases and place the executable file in your PATH.

For other install options, see https://caddyserver.com/docs/download.

Build from source

Requirements:

For development

Note: These steps will not embed proper version information. For that, please follow the instructions in the next section.

$ git clone "https://github.com/caddyserver/caddy.git"
$ cd caddy/cmd/caddy/
$ go build

When you run Caddy, it may try to bind to low ports unless otherwise specified in your config. If your OS requires elevated privileges for this, you will need to give your new binary permission to do so. On Linux, this can be done easily with: sudo setcap cap_net_bind_service=+ep ./caddy

If you prefer to use go run which creates temporary binaries, you can still do this. Make an executable file called setcap.sh (or whatever you want) with these contents:

#!/bin/sh
sudo setcap cap_net_bind_service=+ep "$1"
"[email protected]"

then you can use go run like so:

$ go run -exec ./setcap.sh main.go

If you don't want to type your password for setcap, use sudo visudo to edit your sudoers file and allow your user account to run that command without a password, for example:

username ALL=(ALL:ALL) NOPASSWD: /usr/sbin/setcap

replacing username with your actual username. Please be careful and only do this if you know what you are doing! We are only qualified to document how to use Caddy, not Go tooling or your computer, and we are providing these instructions for convenience only; please learn how to use your own computer at your own risk and make any needful adjustments.

With version information and/or plugins

Using our builder tool, xcaddy...

$ xcaddy build

...the following steps are automated:

  1. Create a new folder: mkdir caddy
  2. Change into it: cd caddy
  3. Copy Caddy's main.go into the empty folder. Add imports for any custom plugins you want to add.
  4. Initialize a Go module: go mod init caddy
  5. (Optional) Pin Caddy version: go get github.com/caddyserver/caddy/[email protected] replacing version with a git tag, commit, or branch name.
  6. (Optional) Add plugins by adding their import: _ "import/path/here"
  7. Compile: go build

Quick start

The Caddy website has documentation that includes tutorials, quick-start guides, reference, and more.

We recommend that all users -- regardless of experience level -- do our Getting Started guide to become familiar with using Caddy.

If you've only got a minute, the website has several quick-start tutorials to choose from! However, after finishing a quick-start tutorial, please read more documentation to understand how the software works. 🙂

Overview

Caddy is most often used as an HTTPS server, but it is suitable for any long-running Go program. First and foremost, it is a platform to run Go applications. Caddy "apps" are just Go programs that are implemented as Caddy modules. Two apps -- tls and http -- ship standard with Caddy.

Caddy apps instantly benefit from automated documentation, graceful on-line config changes via API, and unification with other Caddy apps.

Although JSON is Caddy's native config language, Caddy can accept input from config adapters which can essentially convert any config format of your choice into JSON: Caddyfile, JSON 5, YAML, TOML, NGINX config, and more.

The primary way to configure Caddy is through its API, but if you prefer config files, the command-line interface supports those too.

Caddy exposes an unprecedented level of control compared to any web server in existence. In Caddy, you are usually setting the actual values of the initialized types in memory that power everything from your HTTP handlers and TLS handshakes to your storage medium. Caddy is also ridiculously extensible, with a powerful plugin system that makes vast improvements over other web servers.

To wield the power of this design, you need to know how the config document is structured. Please see our documentation site for details about Caddy's config structure.

Nearly all of Caddy's configuration is contained in a single config document, rather than being scattered across CLI flags and env variables and a configuration file as with other web servers. This makes managing your server config more straightforward and reduces hidden variables/factors.

Full documentation

Our website has complete documentation:

https://caddyserver.com/docs/

The docs are also open source. You can contribute to them here: https://github.com/caddyserver/website

Getting help

  • We strongly recommend that all professionals or companies using Caddy get a support contract through Ardan Labs before help is needed.

  • A sponsorship goes a long way! If Caddy is benefitting your company, please consider a sponsorship! This not only helps fund full-time work to ensure the longevity of the project, it's also a great look for your company to your customers and potential customers!

  • Individuals can exchange help for free on our community forum at https://caddy.community. Remember that people give help out of their spare time and good will. The best way to get help is to give it first!

Please use our issue tracker only for bug reports and feature requests, i.e. actionable development items (support questions will usually be referred to the forums).

About

The name "Caddy" is trademarked. The name of the software is "Caddy", not "Caddy Server" or "CaddyServer". Please call it "Caddy" or, if you wish to clarify, "the Caddy web server". Caddy is a registered trademark of Stack Holdings GmbH.

Caddy is a project of ZeroSSL, a Stack Holdings company.

Debian package repository hosting is graciously provided by Cloudsmith. Cloudsmith is the only fully hosted, cloud-native, universal package management solution, that enables your organization to create, store and share packages in any format, to any place, with total confidence.

Comments
  • ssl certs failure

    ssl certs failure

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

    Caddy (untracked dev build) (last commit hash bbf954c)

    2. What are you trying to do?

    Rebooted my machine and let caddy run agin

    3. What is your entire Caddyfile?

    prolly not relevant (yet)
    

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

    ExecStart=/opt/bin/caddy -pidfile /var/www/caddy.pid -agree=true -email \
        [email protected] -conf=/etc/caddy/Caddyfile -log stdout
    

    5. What did you expect to see?

    Not the following

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

    -- Logs begin at Fri 2016-09-30 19:54:00 UTC. --
    Oct 01 20:23:39 deb caddy[5591]: 2016/10/01 20:23:39 http: TLS handshake error from 85.25.210.234:21233: tls: client offered an unsupported, maximum protocol version of 301
    Oct 01 20:23:40 deb caddy[5591]: 2016/10/01 20:23:40 http: TLS handshake error from 85.25.210.234:13864: tls: client offered an unsupported, maximum protocol version of 301
    Oct 01 20:23:40 deb caddy[5591]: 2016/10/01 20:23:40 http: TLS handshake error from 85.25.210.234:17874: tls: client offered an unsupported, maximum protocol version of 301
    Oct 01 20:24:36 deb caddy[5591]: 2016/10/01 20:24:36 http: TLS handshake error from 106.120.173.99:46438: tls: first record does not look like a TLS handshake
    Oct 01 20:25:36 deb caddy[5591]: 2016/10/01 20:25:36 http: TLS handshake error from [2a02:908:b40:a0:5c79:4d07:c5a9:3d83]:61116: tls: client offered an unsupported, maximum protocol version of 301
    Oct 01 20:31:03 deb caddy[5591]: 2016/10/01 20:31:03 http: TLS handshake error from [2001:1a50:11:0:5f:8f:ac0c:1]:41341: tls: client offered an unsupported, maximum protocol version of 301
    Oct 01 20:34:11 deb caddy[5591]: 2016/10/01 20:34:11 http: TLS handshake error from 54.221.81.125:40546: tls: client offered an unsupported, maximum protocol version of 301
    Oct 01 20:34:11 deb caddy[5591]: 2016/10/01 20:34:11 http: TLS handshake error from 54.221.81.125:40625: tls: client offered an unsupported, maximum protocol version of 301
    Oct 01 20:42:15 deb caddy[5591]: 2016/10/01 20:42:15 http: TLS handshake error from 173.48.168.206:51582: EOF
    Oct 01 20:43:51 deb caddy[5591]: 2016/10/01 20:43:51 http: TLS handshake error from 180.153.73.63:45483: tls: unsupported SSLv2 handshake received
    Oct 01 20:44:25 deb caddy[5591]: 2016/10/01 20:44:25 http: TLS handshake error from 113.160.154.138:44733: tls: unsupported SSLv2 handshake received
    

    After which I restarted Caddy, resulting in the following:

    -- Logs begin at Fri 2016-09-30 19:54:00 UTC, end at Sat 2016-10-01 20:45:48 UTC. --
    Sep 30 19:54:04 deb systemd[1]: Starting Caddy HTTP/2 web server...
    Sep 30 19:54:04 deb systemd[1]: Started Caddy HTTP/2 web server.
    Sep 30 19:54:05 deb caddy[5591]: 2016/09/30 19:54:04 [INFO] NLgids localhost: [email protected]
    Sep 30 19:54:08 deb caddy[5591]: Activating privacy features... done.
    Sep 30 19:54:08 deb caddy[5591]: https://miek.nl
    Sep 30 19:54:08 deb caddy[5591]: https://www.miek.nl
    Sep 30 19:54:08 deb caddy[5591]: https://archive.miek.nl
    Sep 30 19:54:08 deb caddy[5591]: https://nlgids.london
    Sep 30 19:54:08 deb caddy[5591]: https://www.nlgids.london
    Sep 30 19:54:08 deb caddy[5591]: https://coredns.io
    Sep 30 19:54:08 deb caddy[5591]: https://www.coredns.io
    Sep 30 19:54:08 deb caddy[5591]: https://blog.coredns.io
    Sep 30 19:54:08 deb caddy[5591]: https://dnssex.nl
    Sep 30 19:54:08 deb caddy[5591]: https://www.dnssex.nl
    Sep 30 19:54:08 deb caddy[5591]: https://www.berkestoffering.nl
    Sep 30 19:54:08 deb caddy[5591]: https://berkestoffering.nl
    Sep 30 19:54:08 deb caddy[5591]: https://atoom.net
    Sep 30 19:54:08 deb caddy[5591]: https://www.atoom.net
    Sep 30 19:54:08 deb caddy[5591]: https://isitinfra.net
    Sep 30 19:54:08 deb caddy[5591]: https://www.isitinfra.net
    Sep 30 19:54:08 deb caddy[5591]: http://wereldstadsgidsen.com
    Sep 30 19:54:08 deb caddy[5591]: http://www.wereldstadsgiden.com
    Sep 30 19:54:08 deb caddy[5591]: http://wereldstadgidsen.nl
    Sep 30 19:54:08 deb caddy[5591]: http://www.wereldstadgidsen.nl
    Sep 30 19:54:08 deb caddy[5591]: http://wereldstadgidsen.be
    Sep 30 19:54:08 deb caddy[5591]: http://www.wereldstadgidsen.be
    Sep 30 19:54:08 deb caddy[5591]: http://miek.nl
    Sep 30 19:54:08 deb caddy[5591]: http://www.miek.nl
    Sep 30 19:54:08 deb caddy[5591]: http://archive.miek.nl
    Sep 30 19:54:08 deb caddy[5591]: http://nlgids.london
    Sep 30 19:54:08 deb caddy[5591]: http://www.nlgids.london
    Sep 30 19:54:08 deb caddy[5591]: http://coredns.io
    Sep 30 19:54:08 deb caddy[5591]: http://www.coredns.io
    Sep 30 19:54:08 deb caddy[5591]: http://blog.coredns.io
    Sep 30 19:54:08 deb caddy[5591]: http://dnssex.nl
    Sep 30 19:54:08 deb caddy[5591]: http://www.dnssex.nl
    Sep 30 19:54:08 deb caddy[5591]: http://www.berkestoffering.nl
    Sep 30 19:54:08 deb caddy[5591]: http://berkestoffering.nl
    Sep 30 19:54:08 deb caddy[5591]: http://atoom.net
    Sep 30 19:54:08 deb caddy[5591]: http://www.atoom.net
    Sep 30 19:54:08 deb caddy[5591]: http://isitinfra.net
    Sep 30 19:54:08 deb caddy[5591]: http://www.isitinfra.net
    Sep 30 19:55:03 deb caddy[5591]: 92.12.221.148 - miek.nl GET /rss.xml HTTP/1.1 404 1252 -
    Sep 30 19:55:30 deb caddy[5591]: 50.90.21.165 - miek.nl GET /images/apple.jpg HTTP/2.0 200 298876 https://www.google.com/
    Sep 30 19:55:35 deb caddy[5591]: 2016/09/30 19:55:35 http: TLS handshake error from 65.19.138.35:27189: tls: client offered an unsupported, maximum protocol version of 30
    Sep 30 19:55:36 deb caddy[5591]: 2016/09/30 19:55:36 http: TLS handshake error from 8.29.198.27:42107: tls: client offered an unsupported, maximum protocol version of 301
    Sep 30 19:55:36 deb caddy[5591]: 2016/09/30 19:55:36 http: TLS handshake error from 8.29.198.27:14930: tls: client offered an unsupported, maximum protocol version of 300
    Sep 30 19:56:07 deb caddy[5591]: 2001:8b0:bf59:4c3f:a796:8189:437c:4729 - miek.nl GET / HTTP/2.0 200 1609 -
    Sep 30 19:56:07 deb caddy[5591]: 2001:8b0:bf59:4c3f:a796:8189:437c:4729 - miek.nl GET /css/style.css HTTP/2.0 200 3557 https://miek.nl/
    Sep 30 19:56:07 deb caddy[5591]: 2001:8b0:bf59:4c3f:a796:8189:437c:4729 - miek.nl GET /css/monosocialiconsfont.css HTTP/2.0 200 368 https://miek.nl/
    Sep 30 19:56:07 deb caddy[5591]: 2001:8b0:bf59:4c3f:a796:8189:437c:4729 - miek.nl GET /css/highlight.css HTTP/2.0 200 629 https://miek.nl/
    Sep 30 19:56:07 deb caddy[5591]: 2001:8b0:bf59:4c3f:a796:8189:437c:4729 - miek.nl GET /images/avatar.jpg HTTP/2.0 200 35651 https://miek.nl/
    Sep 30 19:56:07 deb caddy[5591]: 2001:8b0:bf59:4c3f:a796:8189:437c:4729 - miek.nl GET /js/main.js HTTP/2.0 200 406 https://miek.nl/
    Sep 30 19:56:07 deb caddy[5591]: 2001:8b0:bf59:4c3f:a796:8189:437c:4729 - miek.nl GET /fonts/MonoSocialIconsFont-1.10.ttf HTTP/2.0 200 146660 https://miek.nl/css/monosoci
    Sep 30 19:56:07 deb caddy[5591]: 2001:8b0:bf59:4c3f:a796:8189:437c:4729 - miek.nl GET /js/highlight.js HTTP/2.0 200 23415 https://miek.nl/
    Sep 30 19:56:07 deb caddy[5591]: 2001:8b0:bf59:4c3f:a796:8189:437c:4729 - miek.nl GET /images/favicon.ico HTTP/2.0 200 5182 https://miek.nl/
    Sep 30 19:56:10 deb caddy[5591]: 2001:8b0:bf59:4c3f:a796:8189:437c:4729 - coredns.io GET / HTTP/2.0 200 2660 -
    Sep 30 19:56:10 deb caddy[5591]: 2001:8b0:bf59:4c3f:a796:8189:437c:4729 - coredns.io GET /img/coredns-logo.png HTTP/2.0 200 1347 https://coredns.io/
    Sep 30 19:56:10 deb caddy[5591]: 2001:8b0:bf59:4c3f:a796:8189:437c:4729 - coredns.io GET /css/landing-page.css HTTP/2.0 200 987 https://coredns.io/
    Sep 30 19:56:10 deb caddy[5591]: 2001:8b0:bf59:4c3f:a796:8189:437c:4729 - coredns.io GET /js/jquery.easing.min.js HTTP/2.0 200 1857 https://coredns.io/
    Sep 30 19:56:10 deb caddy[5591]: 2001:8b0:bf59:4c3f:a796:8189:437c:4729 - coredns.io GET /js/landing-page.js HTTP/2.0 200 471 https://coredns.io/
    Sep 30 19:56:10 deb caddy[5591]: 2001:8b0:bf59:4c3f:a796:8189:437c:4729 - coredns.io GET /font-awesome-4.1.0/css/font-awesome.min.css HTTP/2.0 200 4684 https://coredns.io
    Sep 30 19:56:10 deb caddy[5591]: 2001:8b0:bf59:4c3f:a796:8189:437c:4729 - coredns.io GET /js/bootstrap.min.js HTTP/2.0 200 8544 https://coredns.io/
    Sep 30 19:56:10 deb caddy[5591]: 2001:8b0:bf59:4c3f:a796:8189:437c:4729 - coredns.io GET /css/bootstrap.min.css HTTP/2.0 200 18109 https://coredns.io/
    Sep 30 19:56:10 deb caddy[5591]: 2001:8b0:bf59:4c3f:a796:8189:437c:4729 - coredns.io GET /js/jquery-1.11.0.js HTTP/2.0 200 33391 https://coredns.io/
    Sep 30 19:56:10 deb caddy[5591]: 2001:8b0:bf59:4c3f:a796:8189:437c:4729 - coredns.io GET /img/lava.jpg HTTP/2.0 200 198893 https://coredns.io/
    Sep 30 19:56:11 deb caddy[5591]: 2001:8b0:bf59:4c3f:a796:8189:437c:4729 - coredns.io GET /font-awesome-4.1.0/fonts/fontawesome-webfont.woff HTTP/2.0 200 83760 https://cor
    Sep 30 19:56:11 deb caddy[5591]: 2001:8b0:bf59:4c3f:a796:8189:437c:4729 - coredns.io GET /img/html-code.jpg HTTP/2.0 200 119296 https://coredns.io/
    Sep 30 19:56:11 deb caddy[5591]: 2001:8b0:bf59:4c3f:a796:8189:437c:4729 - coredns.io GET /img/cloud.jpg HTTP/2.0 200 435545 https://coredns.io/
    Sep 30 19:56:11 deb caddy[5591]: 2001:8b0:bf59:4c3f:a796:8189:437c:4729 - coredns.io GET /img/disk.jpg HTTP/2.0 200 757713 https://coredns.io/
    Sep 30 19:56:11 deb caddy[5591]: 2001:8b0:bf59:4c3f:a796:8189:437c:4729 - coredns.io GET /img/intro-bg.jpg HTTP/2.0 200 435545 https://coredns.io/css/landing-page.css
    Sep 30 19:56:11 deb caddy[5591]: 2001:8b0:bf59:4c3f:a796:8189:437c:4729 - coredns.io GET /img/contact-bg.jpg HTTP/2.0 200 544154 https://coredns.io/css/landing-page.css
    Sep 30 19:56:12 deb caddy[5591]: 2001:8b0:bf59:4c3f:a796:8189:437c:4729 - coredns.io GET /img/mountain.jpg HTTP/2.0 200 1332881 https://coredns.io/
    Sep 30 19:56:12 deb caddy[5591]: 2001:8b0:bf59:4c3f:a796:8189:437c:4729 - coredns.io GET /favicon.ico HTTP/2.0 404 0 https://coredns.io/
    Sep 30 19:56:56 deb caddy[5591]: 49.128.61.142 - miek.nl GET /favicon.ico HTTP/2.0 404 3919 https://miek.nl/downloads/2015/go.pdf
    Sep 30 19:56:56 deb caddy[5591]: 80.100.158.12 - miek.nl GET /feeds/all.atom.xml HTTP/2.0 404 1252 -
    Sep 30 19:56:57 deb caddy[5591]: 49.128.61.142 - miek.nl GET /downloads/2015/go.pdf HTTP/2.0 200 994890 http://dave.cheney.net/resources-for-new-go-programmers
    Sep 30 19:56:57 deb caddy[5591]: 49.128.61.142 - miek.nl GET /downloads/2015/go.pdf HTTP/2.0 206 634442 https://miek.nl/downloads/2015/go.pdf
    Sep 30 19:57:02 deb caddy[5591]: 2607:8400:2010:2:c90a:ae38:f60a:3756 - www.miek.nl GET /rss.xml HTTP/1.1 404 1252 -
    Sep 30 19:57:05 deb caddy[5591]: 2016/09/30 19:57:05 http2: server: error reading preface from client 49.128.61.142:53745: timeout waiting for client preface
    Sep 30 19:57:06 deb caddy[5591]: 2016/09/30 19:57:06 http: TLS handshake error from 49.128.61.142:53747: EOF
    Sep 30 19:57:38 deb caddy[5591]: 86.105.55.25 - miek.nl GET /feeds/all.atom.xml HTTP/1.1 404 1252 -
    Sep 30 19:58:14 deb caddy[5591]: 66.249.76.120 - www.nlgids.london GET /specials.html HTTP/1.1 200 4797 -
    Sep 30 19:58:18 deb caddy[5591]: 180.76.15.7 - archive.miek.nl GET /downloads/pubs/secreg-report.pdf HTTP/1.1 200 94343 -
    Sep 30 19:58:29 deb caddy[5591]: 49.128.61.142 - miek.nl GET / HTTP/2.0 200 1609 -
    Sep 30 19:58:29 deb caddy[5591]: 49.128.61.142 - miek.nl GET /css/highlight.css HTTP/2.0 200 629 https://miek.nl/
    Sep 30 19:58:29 deb caddy[5591]: 49.128.61.142 - miek.nl GET /css/style.css HTTP/2.0 200 3557 https://miek.nl/
    ...skipping...
    Oct 01 20:23:36 deb caddy[5591]: 2016/10/01 20:23:36 http: TLS handshake error from 85.25.210.234:42145: tls: client offered an unsupported, maximum protocol version of 3
    Oct 01 20:23:36 deb caddy[5591]: 2016/10/01 20:23:36 http: TLS handshake error from 85.25.210.234:34234: tls: client offered an unsupported, maximum protocol version of 3
    Oct 01 20:23:37 deb caddy[5591]: 2016/10/01 20:23:37 http: TLS handshake error from 85.25.210.234:40256: tls: client offered an unsupported, maximum protocol version of 3
    Oct 01 20:23:38 deb caddy[5591]: 2016/10/01 20:23:38 http: TLS handshake error from 85.25.210.234:62341: tls: client offered an unsupported, maximum protocol version of 3
    Oct 01 20:23:38 deb caddy[5591]: 2016/10/01 20:23:38 http: TLS handshake error from 85.25.210.234:34146: tls: client offered an unsupported, maximum protocol version of 3
    Oct 01 20:23:38 deb caddy[5591]: 2016/10/01 20:23:38 http: TLS handshake error from 85.25.210.234:58432: tls: client offered an unsupported, maximum protocol version of 3
    Oct 01 20:23:39 deb caddy[5591]: 2016/10/01 20:23:39 http: TLS handshake error from 85.25.210.234:41085: tls: client offered an unsupported, maximum protocol version of 3
    Oct 01 20:23:39 deb caddy[5591]: 2016/10/01 20:23:39 http: TLS handshake error from 85.25.210.234:21233: tls: client offered an unsupported, maximum protocol version of 3
    Oct 01 20:23:40 deb caddy[5591]: 2016/10/01 20:23:40 http: TLS handshake error from 85.25.210.234:13864: tls: client offered an unsupported, maximum protocol version of 3
    Oct 01 20:23:40 deb caddy[5591]: 2016/10/01 20:23:40 http: TLS handshake error from 85.25.210.234:17874: tls: client offered an unsupported, maximum protocol version of 3
    Oct 01 20:24:36 deb caddy[5591]: 2016/10/01 20:24:36 http: TLS handshake error from 106.120.173.99:46438: tls: first record does not look like a TLS handshake
    Oct 01 20:25:36 deb caddy[5591]: 2016/10/01 20:25:36 http: TLS handshake error from [2a02:908:b40:a0:5c79:4d07:c5a9:3d83]:61116: tls: client offered an unsupported, maxim
    Oct 01 20:31:03 deb caddy[5591]: 2016/10/01 20:31:03 http: TLS handshake error from [2001:1a50:11:0:5f:8f:ac0c:1]:41341: tls: client offered an unsupported, maximum proto
    Oct 01 20:34:11 deb caddy[5591]: 2016/10/01 20:34:11 http: TLS handshake error from 54.221.81.125:40546: tls: client offered an unsupported, maximum protocol version of 3
    Oct 01 20:34:11 deb caddy[5591]: 2016/10/01 20:34:11 http: TLS handshake error from 54.221.81.125:40625: tls: client offered an unsupported, maximum protocol version of 3
    Oct 01 20:42:15 deb caddy[5591]: 2016/10/01 20:42:15 http: TLS handshake error from 173.48.168.206:51582: EOF
    Oct 01 20:43:51 deb caddy[5591]: 2016/10/01 20:43:51 http: TLS handshake error from 180.153.73.63:45483: tls: unsupported SSLv2 handshake received
    Oct 01 20:44:25 deb caddy[5591]: 2016/10/01 20:44:25 http: TLS handshake error from 113.160.154.138:44733: tls: unsupported SSLv2 handshake received
    Oct 01 20:45:39 deb systemd[1]: Stopping Caddy HTTP/2 web server...
    Oct 01 20:45:39 deb systemd[1]: Stopped Caddy HTTP/2 web server.
    Oct 01 20:45:39 deb systemd[1]: Starting Caddy HTTP/2 web server...
    Oct 01 20:45:39 deb systemd[1]: Started Caddy HTTP/2 web server.
    Oct 01 20:45:39 deb caddy[26635]: 2016/10/01 20:45:39 [INFO] NLgids localhost: [email protected]
    Oct 01 20:45:42 deb caddy[26635]: Activating privacy features...2016/10/01 20:45:42 [INFO] Certificate for [www.dnssex.nl] expires in 699h15m17.206609051s; attempting ren
    Oct 01 20:45:43 deb caddy[26635]: 2016/10/01 20:45:43 [INFO][www.dnssex.nl] acme: Trying renewal with 699 hours remaining
    Oct 01 20:45:43 deb caddy[26635]: 2016/10/01 20:45:43 [INFO][www.dnssex.nl] acme: Obtaining bundled SAN certificate
    Oct 01 20:45:43 deb caddy[26635]: 2016/10/01 20:45:43 [INFO][www.dnssex.nl] acme: Trying to solve TLS-SNI-01
    Oct 01 20:45:45 deb caddy[26635]: 2016/10/01 20:45:45 [INFO][www.dnssex.nl] The server validated our request
    Oct 01 20:45:45 deb caddy[26635]: 2016/10/01 20:45:45 [INFO][www.dnssex.nl] acme: Validations succeeded; requesting certificates
    Oct 01 20:45:45 deb caddy[26635]: 2016/10/01 20:45:45 [INFO] acme: Requesting issuer cert from https://acme-v01.api.letsencrypt.org/acme/issuer-cert
    Oct 01 20:45:46 deb caddy[26635]: 2016/10/01 20:45:46 [INFO][www.dnssex.nl] Server responded with a certificate.
    Oct 01 20:45:46 deb caddy[26635]: 2016/10/01 20:45:46 [INFO] Certificate for [www.isitinfra.net] expires in 699h21m13.896591197s; attempting renewal
    Oct 01 20:45:46 deb caddy[26635]: 2016/10/01 20:45:46 [INFO][www.isitinfra.net] acme: Trying renewal with 699 hours remaining
    Oct 01 20:45:46 deb caddy[26635]: 2016/10/01 20:45:46 [INFO][www.isitinfra.net] acme: Obtaining bundled SAN certificate
    Oct 01 20:45:46 deb caddy[26635]: 2016/10/01 20:45:46 [INFO][www.isitinfra.net] acme: Trying to solve HTTP-01
    Oct 01 20:45:47 deb caddy[26635]: 2016/10/01 20:45:47 [INFO][www.isitinfra.net] Served key authentication
    Oct 01 20:45:48 deb caddy[26635]: 2016/10/01 20:45:48 [INFO][www.isitinfra.net] The server validated our request
    Oct 01 20:45:48 deb caddy[26635]: 2016/10/01 20:45:48 [INFO][www.isitinfra.net] acme: Validations succeeded; requesting certificates
    Oct 01 20:45:48 deb caddy[26635]: 2016/10/01 20:45:48 [INFO] acme: Requesting issuer cert from https://acme-v01.api.letsencrypt.org/acme/issuer-cert
    Oct 01 20:45:48 deb caddy[26635]: 2016/10/01 20:45:48 [INFO][www.isitinfra.net] Server responded with a certificate.
    Oct 01 20:45:48 deb caddy[26635]: 2016/10/01 20:45:48 [INFO] Certificate for [miek.nl ] expires in 699h14m11.202888651s; attempting renewal
    Oct 01 20:45:48 deb caddy[26635]: 2016/10/01 20:45:48 [INFO][miek.nl] acme: Trying renewal with 699 hours remaining
    Oct 01 20:45:49 deb caddy[26635]: 2016/10/01 20:45:49 [INFO][miek.nl] acme: Obtaining bundled SAN certificate
    Oct 01 20:45:49 deb caddy[26635]: 2016/10/01 20:45:49 [INFO][miek.nl] acme: Trying to solve TLS-SNI-01
    deb# journalctl -fu caddy
    -- Logs begin at Fri 2016-09-30 19:54:00 UTC. --
    Oct 01 20:46:00 deb caddy[26635]: 2016/10/01 20:46:00 [INFO][www.berkestoffering.nl] acme: Obtaining bundled SAN certificate
    Oct 01 20:46:01 deb caddy[26635]: 2016/10/01 20:46:01 [INFO][www.berkestoffering.nl] acme: Trying to solve HTTP-01
    Oct 01 20:46:01 deb caddy[26635]: 2016/10/01 20:46:01 [INFO][www.berkestoffering.nl] Served key authentication
    Oct 01 20:46:02 deb caddy[26635]: 2016/10/01 20:46:02 [INFO][www.berkestoffering.nl] The server validated our request
    Oct 01 20:46:02 deb caddy[26635]: 2016/10/01 20:46:02 [INFO][www.berkestoffering.nl] acme: Validations succeeded; requesting certificates
    Oct 01 20:46:03 deb caddy[26635]: 2016/10/01 20:46:03 [INFO] acme: Requesting issuer cert from https://acme-v01.api.letsencrypt.org/acme/issuer-cert
    Oct 01 20:46:03 deb caddy[26635]: 2016/10/01 20:46:03 [INFO][www.berkestoffering.nl] Server responded with a certificate.
    Oct 01 20:46:03 deb caddy[26635]: 2016/10/01 20:46:03 [INFO] Certificate for [www.atoom.net] expires in 699h18m56.277058473s; attempting renewal
    Oct 01 20:46:03 deb caddy[26635]: 2016/10/01 20:46:03 [INFO][www.atoom.net] acme: Trying renewal with 699 hours remaining
    Oct 01 20:46:04 deb caddy[26635]: 2016/10/01 20:46:04 [INFO][www.atoom.net] acme: Obtaining bundled SAN certificate
    Oct 01 20:46:04 deb caddy[26635]: 2016/10/01 20:46:04 [INFO][www.atoom.net] acme: Trying to solve HTTP-01
    Oct 01 20:46:05 deb caddy[26635]: 2016/10/01 20:46:05 [INFO][www.atoom.net] Served key authentication
    Oct 01 20:46:06 deb caddy[26635]: 2016/10/01 20:46:06 [INFO][www.atoom.net] The server validated our request
    Oct 01 20:46:06 deb caddy[26635]: 2016/10/01 20:46:06 [INFO][www.atoom.net] acme: Validations succeeded; requesting certificates
    Oct 01 20:46:06 deb caddy[26635]: 2016/10/01 20:46:06 [INFO] acme: Requesting issuer cert from https://acme-v01.api.letsencrypt.org/acme/issuer-cert
    Oct 01 20:46:06 deb caddy[26635]: 2016/10/01 20:46:06 [INFO][www.atoom.net] Server responded with a certificate.
    Oct 01 20:46:06 deb caddy[26635]: 2016/10/01 20:46:06 [INFO] Certificate for [isitinfra.net] expires in 699h18m53.361987199s; attempting renewal
    Oct 01 20:46:06 deb caddy[26635]: 2016/10/01 20:46:06 [INFO][isitinfra.net] acme: Trying renewal with 699 hours remaining
    Oct 01 20:46:07 deb caddy[26635]: 2016/10/01 20:46:07 [INFO][isitinfra.net] acme: Obtaining bundled SAN certificate
    Oct 01 20:46:07 deb caddy[26635]: 2016/10/01 20:46:07 [INFO][isitinfra.net] acme: Trying to solve HTTP-01
    Oct 01 20:46:07 deb caddy[26635]: 2016/10/01 20:46:07 [INFO][isitinfra.net] Served key authentication
    Oct 01 20:46:08 deb caddy[26635]: 2016/10/01 20:46:08 [INFO][isitinfra.net] The server validated our request
    Oct 01 20:46:08 deb caddy[26635]: 2016/10/01 20:46:08 [INFO][isitinfra.net] acme: Validations succeeded; requesting certificates
    Oct 01 20:46:09 deb caddy[26635]: 2016/10/01 20:46:09 [INFO] acme: Requesting issuer cert from https://acme-v01.api.letsencrypt.org/acme/issuer-cert
    Oct 01 20:46:09 deb caddy[26635]: 2016/10/01 20:46:09 [INFO][isitinfra.net] Server responded with a certificate.
    Oct 01 20:46:09 deb caddy[26635]: 2016/10/01 20:46:09 [INFO] Certificate for [archive.miek.nl] expires in 699h14m50.622164874s; attempting renewal
    Oct 01 20:46:09 deb caddy[26635]: 2016/10/01 20:46:09 [INFO][archive.miek.nl] acme: Trying renewal with 699 hours remaining
    Oct 01 20:46:09 deb caddy[26635]: 2016/10/01 20:46:09 [INFO][archive.miek.nl] acme: Obtaining bundled SAN certificate
    Oct 01 20:46:10 deb caddy[26635]: 2016/10/01 20:46:10 [INFO][archive.miek.nl] acme: Could not find solver for: dns-01
    Oct 01 20:46:10 deb caddy[26635]: 2016/10/01 20:46:10 [INFO][archive.miek.nl] acme: Trying to solve TLS-SNI-01
    Oct 01 20:46:11 deb caddy[26635]: 2016/10/01 20:46:11 [INFO][archive.miek.nl] The server validated our request
    Oct 01 20:46:11 deb caddy[26635]: 2016/10/01 20:46:11 [INFO][archive.miek.nl] acme: Validations succeeded; requesting certificates
    Oct 01 20:46:12 deb caddy[26635]: 2016/10/01 20:46:12 [INFO] acme: Requesting issuer cert from https://acme-v01.api.letsencrypt.org/acme/issuer-cert
    Oct 01 20:46:12 deb caddy[26635]: 2016/10/01 20:46:12 [INFO][archive.miek.nl] Server responded with a certificate.
    Oct 01 20:46:12 deb caddy[26635]: 2016/10/01 20:46:12 [INFO] Certificate for [nlgids.london] expires in 699h14m47.650614623s; attempting renewal
    Oct 01 20:46:12 deb caddy[26635]: 2016/10/01 20:46:12 [INFO][nlgids.london] acme: Trying renewal with 699 hours remaining
    Oct 01 20:46:12 deb caddy[26635]: 2016/10/01 20:46:12 [INFO][nlgids.london] acme: Obtaining bundled SAN certificate
    Oct 01 20:46:13 deb caddy[26635]: 2016/10/01 20:46:13 [INFO][nlgids.london] acme: Trying to solve TLS-SNI-01
    Oct 01 20:46:15 deb caddy[26635]: 2016/10/01 20:46:15 [INFO][nlgids.london] The server validated our request
    Oct 01 20:46:15 deb caddy[26635]: 2016/10/01 20:46:15 [INFO][nlgids.london] acme: Validations succeeded; requesting certificates
    Oct 01 20:46:15 deb caddy[26635]: 2016/10/01 20:46:15 [INFO] acme: Requesting issuer cert from https://acme-v01.api.letsencrypt.org/acme/issuer-cert
    Oct 01 20:46:15 deb caddy[26635]: 2016/10/01 20:46:15 [INFO][nlgids.london] Server responded with a certificate.
    Oct 01 20:46:15 deb caddy[26635]: 2016/10/01 20:46:15 [INFO] Certificate for [berkestoffering.nl] expires in 699h14m44.235123573s; attempting renewal
    Oct 01 20:46:15 deb caddy[26635]: 2016/10/01 20:46:15 [INFO][berkestoffering.nl] acme: Trying renewal with 699 hours remaining
    Oct 01 20:46:16 deb caddy[26635]: 2016/10/01 20:46:16 [INFO][berkestoffering.nl] acme: Obtaining bundled SAN certificate
    Oct 01 20:46:16 deb caddy[26635]: 2016/10/01 20:46:16 [INFO][berkestoffering.nl] acme: Trying to solve HTTP-01
    Oct 01 20:46:17 deb caddy[26635]: 2016/10/01 20:46:17 [INFO][berkestoffering.nl] Served key authentication
    Oct 01 20:46:18 deb caddy[26635]: 2016/10/01 20:46:18 [INFO][berkestoffering.nl] The server validated our request
    Oct 01 20:46:18 deb caddy[26635]: 2016/10/01 20:46:18 [INFO][berkestoffering.nl] acme: Validations succeeded; requesting certificates
    Oct 01 20:46:20 deb caddy[26635]: 2016/10/01 20:46:20 [INFO] acme: Requesting issuer cert from https://acme-v01.api.letsencrypt.org/acme/issuer-cert
    Oct 01 20:46:20 deb caddy[26635]: 2016/10/01 20:46:20 [INFO][berkestoffering.nl] Server responded with a certificate.
    Oct 01 20:46:20 deb caddy[26635]: 2016/10/01 20:46:20 [INFO] Certificate for [atoom.net] expires in 699h18m39.180178862s; attempting renewal
    Oct 01 20:46:21 deb caddy[26635]: 2016/10/01 20:46:21 [INFO][atoom.net] acme: Trying renewal with 699 hours remaining
    Oct 01 20:46:21 deb caddy[26635]: 2016/10/01 20:46:21 [INFO][atoom.net] acme: Obtaining bundled SAN certificate
    Oct 01 20:46:21 deb caddy[26635]: 2016/10/01 20:46:21 [INFO][atoom.net] acme: Trying to solve HTTP-01
    Oct 01 20:46:22 deb caddy[26635]: 2016/10/01 20:46:22 [INFO][atoom.net] Served key authentication
    Oct 01 20:46:23 deb caddy[26635]: 2016/10/01 20:46:23 [INFO][atoom.net] The server validated our request
    Oct 01 20:46:23 deb caddy[26635]: 2016/10/01 20:46:23 [INFO][atoom.net] acme: Validations succeeded; requesting certificates
    Oct 01 20:46:23 deb caddy[26635]: 2016/10/01 20:46:23 [INFO] acme: Requesting issuer cert from https://acme-v01.api.letsencrypt.org/acme/issuer-cert
    Oct 01 20:46:23 deb caddy[26635]: 2016/10/01 20:46:23 [INFO][atoom.net] Server responded with a certificate.
    Oct 01 20:46:26 deb caddy[26635]:  done.
    Oct 01 20:46:26 deb caddy[26635]: https://miek.nl
    Oct 01 20:46:26 deb caddy[26635]: https://www.miek.nl
    Oct 01 20:46:26 deb caddy[26635]: https://archive.miek.nl
    Oct 01 20:46:26 deb caddy[26635]: https://nlgids.london
    Oct 01 20:46:26 deb caddy[26635]: https://www.nlgids.london
    Oct 01 20:46:26 deb caddy[26635]: https://coredns.io
    Oct 01 20:46:26 deb caddy[26635]: https://www.coredns.io
    Oct 01 20:46:26 deb caddy[26635]: https://blog.coredns.io
    Oct 01 20:46:26 deb caddy[26635]: https://dnssex.nl
    Oct 01 20:46:26 deb caddy[26635]: https://www.dnssex.nl
    Oct 01 20:46:26 deb caddy[26635]: https://www.berkestoffering.nl
    Oct 01 20:46:26 deb caddy[26635]: https://berkestoffering.nl
    Oct 01 20:46:26 deb caddy[26635]: https://atoom.net
    Oct 01 20:46:26 deb caddy[26635]: https://www.atoom.net
    Oct 01 20:46:26 deb caddy[26635]: https://isitinfra.net
    Oct 01 20:46:26 deb caddy[26635]: https://www.isitinfra.net
    Oct 01 20:46:26 deb caddy[26635]: http://wereldstadsgidsen.com
    Oct 01 20:46:26 deb caddy[26635]: http://www.wereldstadsgiden.com
    Oct 01 20:46:26 deb caddy[26635]: http://wereldstadgidsen.nl
    Oct 01 20:46:26 deb caddy[26635]: http://www.wereldstadgidsen.nl
    Oct 01 20:46:26 deb caddy[26635]: http://wereldstadgidsen.be
    Oct 01 20:46:26 deb caddy[26635]: http://www.wereldstadgidsen.be
    Oct 01 20:46:26 deb caddy[26635]: http://miek.nl
    Oct 01 20:46:26 deb caddy[26635]: http://www.miek.nl
    Oct 01 20:46:26 deb caddy[26635]: http://archive.miek.nl
    Oct 01 20:46:26 deb caddy[26635]: http://nlgids.london
    Oct 01 20:46:26 deb caddy[26635]: http://www.nlgids.london
    Oct 01 20:46:26 deb caddy[26635]: http://coredns.io
    Oct 01 20:46:26 deb caddy[26635]: http://www.coredns.io
    Oct 01 20:46:26 deb caddy[26635]: http://blog.coredns.io
    Oct 01 20:46:26 deb caddy[26635]: http://dnssex.nl
    Oct 01 20:46:26 deb caddy[26635]: http://www.dnssex.nl
    Oct 01 20:46:26 deb caddy[26635]: http://www.berkestoffering.nl
    Oct 01 20:46:26 deb caddy[26635]: http://berkestoffering.nl
    Oct 01 20:46:26 deb caddy[26635]: http://atoom.net
    Oct 01 20:46:26 deb caddy[26635]: http://www.atoom.net
    Oct 01 20:46:26 deb caddy[26635]: http://isitinfra.net
    Oct 01 20:46:26 deb caddy[26635]: http://www.isitinfra.net
    

    7. How can someone who is starting from scratch reproduce this behavior as minimally as possible?

    Good question.

    bug :lady_beetle: help wanted :sos: 
    opened by miekg 95
  • Proposal: Permanently change all proprietary licensing to open source

    Proposal: Permanently change all proprietary licensing to open source

    We (Light Code Labs in partnership with Ardan Labs) have decided that we would like to make all Caddy code open source and permanently remove all proprietary licensing within the project, effective as soon as this proposal is accepted.

    We would like the community's feedback on these plans, which are as follows:

    • Reaffirm that Caddy is an Apache 2.0-licensed open source project (this is unchanged)
    • All Caddy binaries remain open source, Apache 2.0-licensed
    • All official, enterprise-only v2 plugins that were to be reserved for business customers be released under the same open source license and moved into open repositories
    • Drop plans for "Caddy Enterprise" branding
    • Invite the community to collaborate in the development of all of Caddy, including former-Enterprise-only features
    • Drop all build server subscriptions, startup packages, and private plugin hosting

    With regards to the website, our plans are:

    • Remove all use case restrictions from the build server (download page and getcaddy.com)
    • Eliminate all mentions of products, business licensing, and subscriptions from the website
    • Move the current website to caddyserver.com/v1 with redirects for most URLs
    • Put up a v2 website at caddyserver.com that reflects the values, features, and benefits of the new Caddy project
    • Add a Support/Contact link for companies who require support
    • Add Ardan Labs' logo to broadcast our close relationship with Ardan Labs, and to make it clear that this open source project is backed by a trusted company

    With Ardan Labs as our official partner for the Caddy project, we are ready to support the enterprise use cases. Ardan Labs is world-renowned for their Go training and support in the enterprise setting. We are confident that businesses will love using Caddy 2 once they try it, and we look forward to supporting their production use cases.

    Our plans for businesses are:

    • Light Code Labs will continue supporting our current v1 customers until their subscriptions expire
    • Leverage Ardan Labs expertise to serve our clients with what they require -- whether it be 24/7 on-call support, custom feature development, training, and/or installation help or consultation
    • Light Code Labs may seek sponsorships to help back the ongoing, full-time open source development of the project
    • Light Code Labs will reach out to our current customers to let them know about these changes and help them understand these improved support options

    With regards to Caddy v2, our plans are:

    • Release a new beta version approximately every Monday
    • Release RC1 by the end of the year
    • Release stable 2.0 in Q1 2020

    We want the world to know that Caddy:

    1. is open source for good
    2. is not a toy project
    3. has corporate backing
    4. can be used without hassle or worry in both small business and enterprise environments
    5. can support enterprise use

    We hope these changes will make this vision for the new Caddy project a reality.

    What do you think?

    Please submit your votes and feedback in this issue, and share it as widely as you can because this is the culmination of many years' efforts from ourselves and many of you! Thank you to everyone involved!

    discussion :speech_balloon: 
    opened by mholt 72
  • ZeroSSL certificate must be forcibly reissued

    ZeroSSL certificate must be forcibly reissued

    https://help.zerossl.com/hc/en-us/articles/900006733066

    ZeroSSL has announced that certificates issued by ACME may be revoked by Sectigo. Caddy-issued certificates clearly fall into this category.

    Certificates prior to May 21, 2021 must be prompted to reship the certificate. Can this be handled at the Caddy level? If necessary, we also need to provide a means for the user to handle it manually.

    bug :lady_beetle: 
    opened by fu-sen 64
  • Allow revocation list for client cert auth

    Allow revocation list for client cert auth

    Hello, could caddy add an option to check client certificate against a revocation list ? This was the object of https://github.com/mholt/caddy/issues/1904, which it was closed as duplicate of https://github.com/mholt/caddy/issues/1375, but https://github.com/mholt/caddy/issues/1375 doesn't seems to implement that. Best,


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

    v0.11.0

    2. What are you trying to do?

    Disallow revoked client certs

    3. What is your entire Caddyfile?

    Not relevant, there's no option to do that as per https://caddyserver.com/docs/tls

    help wanted :sos: feature :gear: 
    opened by u1735067 61
  • Caddy ignores -https-port and breaks custom port mapping with recent change

    Caddy ignores -https-port and breaks custom port mapping with recent change

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

    broken (latest master): 0b83014ff81b68b8fde21521662339396c277ab8

    a working revision: 4f5df39bdd9ce05146da14bb60f5a17a163d5262

    2. What are you trying to do?

    Proper security by explicit port forwarding and explicitly limited capabilities.

    3. What is your entire Caddyfile?

    http://example.com:8080 {
      redir https://asdas.net{uri}
    }
    
    https://example.comt:8443 {
      tls [email protected]
      limits 1mb
      log stdout
      errors stdout
    }
    

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

    caddy -agree -http-port 8080 -https-port 8443 -conf /path/to/config/Caddyfile -log stdout
    
    • external port mapping from external ports 80 and 443 to internal 8080 and 8443 by SDN.

    6. What did you expect to see?

    Older versions including the "working" revision respect the flags and are able to request and and renew LE/ACME certificates fine with the config. At least the version defined as "broken" tries to bind to port 443 ignoring the given CLI flag.

    bug :lady_beetle: 
    opened by rmoriz 58
  • proxy: Add header and uri load balancing policies

    proxy: Add header and uri load balancing policies

    Can caddy support more load balancing algorithms such as haproxy.

    • round-robin for short connections, pick each server in turn
    • leastconn for long connections, pick the least recently used of the servers with the lowest connection count
    • source for SSL farms or terminal server farms, the server directly depends on the client's source address
    • uri for HTTP caches, the server directly depends on the HTTP URI
    • hdr the server directly depends on the contents of a specific HTTP header field
    • first for short-lived virtual machines, all connections are packed on the smallest possible subset of servers so that unused ones can be powered down
    feature :gear: good first issue :baby_chick: 
    opened by vicanso 57
  • Support to reverse proxy into Docker Containers

    Support to reverse proxy into Docker Containers

    A useful feature that would be good to use Caddy as the frontend server in front of 1+ Docker Hosts (or Docker Swarm).

    The caddy configuration file would have one or more docker hosts specified so that specifically tagged/named docker container instances running on those hosts could be looked up based on the Host header requested via HTTP. When a request comes in, take the Host header and do a lookup (full, partial or regex) against the Docker API to match the Host header to a Docker Instance running on the docker hosts (load balancing if multiple instances are running).

    This would make it easy to launch docker containers that are configured in a specific way (i.e. a container tagged as dockerhubacct/www.example.com -or- via environment variables). There are many different ways this could be setup, container names need to be unique per docker host, but tags and environment variables do not.

    Docker Proxy - Possible Caddyfile Directives

    docker_proxy / dockerhost1 dockerhost2 {
      # Use the same things as a normal proxy. docker_proxy would just be a smarter proxy module
    }
    
    feature :gear: 
    opened by madeofstars0 57
  • Add WSGI directive for serving Python apps

    Add WSGI directive for serving Python apps

    I don't have time (or expertise) to contribute this but I'd definitely be interested in using it so I figured I'd create the feature request and try to gather interest.

    I :heart: Caddy and want to use it for all the things. That includes serving up my Django app via WSGI.

    I imagine this working similar to the proxy directive where you tell it to serve some directory via WSGI. (Forgive my perhaps incorrect use of terms, I'm a Python noob.)

    I found this package for serving WSGI apps via Go but not sure of its production readiness.

    feature :gear: plugin :electric_plug: 
    opened by jpoehls 57
  • Build error regarding h2quic

    Build error regarding h2quic

    When I try to build the server I'm receiving:

    package github.com/lucas-clemente/quic-go/h2quic: 
    cannot find package "github.com/lucas-clemente/quic-go/h2quic"
    

    I noticed there was a recent change on the library renaming the directory from h2quic to http3: Example here.

    documentation :books: 
    opened by wallacyyy 55
  • HTTP/2 push support plugin (golang 1.8)

    HTTP/2 push support plugin (golang 1.8)

    Hi all,

    This change introduces new push plugin (adressing https://github.com/mholt/caddy/issues/816)

    This will be possible in golang 1.8 due to http.Pusher and http.PushOptions interfaces being introduced (https://github.com/golang/go/commit/cf73bbfa259afe29962a5ca5e207441f63c9bcf2, tracking https://github.com/golang/go/issues/13443)

    As interface was published yesterday I could not resist and implemented new push directive :grin:

    This middleware operates in two modes: rules-based and link-based.

    Rules-based syntax

    push /index.html /index.css
    
    push /index2.html /index.css
    
    push / /ga.js
    
    push /index.html /pushedResource.js /pushedCss.css {
       method GET
       header That-Was-Pushed Wow
       header Server Caddy-Push
    }
    

    Link-based mode

    Middleware intercepts Link headers from the Next middleware and tries to use Pusher to push resources to the client.

    For more information about Link header: https://w3c.github.io/preload/

    Note for reviewers

    This plugin is complete and tested but non functional as of current go's tip (actual implementation in https://go-review.googlesource.com/#/c/29439/ was not yet merged).

    But... when go 1.8 will be released this plugin will actually support HTTP/2 Push in Caddy

    Discussion

    I'm not sure if this plugin should be integral part of the caddy's core or should I move it to it's own repo - opinions on that will be appreciated.

    https://www.youtube.com/watch?v=vCadcBR95oU 🕶

    opened by wendigo 55
  • [feature request] build PHP directly in caddy or as plugin

    [feature request] build PHP directly in caddy or as plugin

    with the statement that caddy is also "It's easy to set up and doesn't get in the way." or "If you've ever found it difficult to configure a web server, try Caddy." as the website says I would say that a PHP plugin should be there, maybe even MySQL, because not everyone knows (or wants to know) how to do stuff with a fastCGI "server", well I got it to work but in the end, but having it integrated would make it a LOT easier.

    discussion :speech_balloon: 
    opened by My1 55
  • [Feature request] in- and export certs

    [Feature request] in- and export certs

    While going on the search for some answers for my question I found out that Caddy's certification storage is a little tricky to find - at least, I think so.

    So it'd be useful to have either an API or CLI method of retriving or adding certificates (i.e.: when moving servers or wanting to back up the certs for other reasons).

    The DEB package stores them like so:

    /var/lib/caddy/.local/share/caddy
    |-- acme
    |   |-- acme-staging-v02.api.letsencrypt.org-directory
    |   |   `-- users
    |   |       `-- default
    |   |           |-- default.json
    |   |           `-- default.key
    |   |-- acme-v02.api.letsencrypt.org-directory
    |   |   |-- challenge_tokens
    |   |   `-- users
    |   |       `-- default
    |   |           |-- default.json
    |   |           `-- default.key
    |   `-- acme.zerossl.com-v2-dv90
    |       `-- users
    |           `-- [email protected]
    |               |-- caddy.json
    |               `-- caddy.key
    |-- certificates
    |   `-- acme-v02.api.letsencrypt.org-directory
    |       |-- birb.it
    |       |   |-- birb.it.crt
    |       |   |-- birb.it.json
    |       |   `-- birb.it.key
    |       `-- ingwie.me
    |           |-- ingwie.me.crt
    |           |-- ingwie.me.json
    |           `-- ingwie.me.key
    |-- locks
    `-- ocsp
        |-- birb.it-35d50d53
        |-- birb.it-5e4a8635
        |-- ingwie.me-62663424
        `-- ingwie.me-f736987a
    
    17 directories, 16 files
    

    Having a somewhat easier way to find, retrive and/or store certificates would be pretty helpful.

    caddy get-cert-key $domain
    caddy get-cert-crt $domain
    
    caddy set-cert $key $crt
    

    Thanks for the awesome program and have a great day!

    Kind regards, Ingwie

    feature :gear: discussion :speech_balloon: 
    opened by IngwiePhoenix 1
  • How to use both custom certificates and wildcard auto-generated ones?

    How to use both custom certificates and wildcard auto-generated ones?

    I want to caddy to generate a wildcard certificate *.example.com, and then use that for multiple hosts (like homeassistant.example.com and other.example.com) on port 443.

    I also want to have homeassistant-external.example.com on port 21443 so I can use a manually set certificate.

    Basically, I want that when I access https://homeassistant.example.com:443 the certificate used is the auto-generated wildcard one, and when I access https://homeassistant-external.example.com:21443 it uses the supplied certificate instead.

    The problem is the moment I add the :21443 block, it will always pick up that certificate for both :443 and :21443, and ignore the auto-generated one!

    I have this setup working fine under nginx, but I haven’t been able to do it with caddy…

    (Note: this is a follow up on https://caddy.community/t/how-to-use-custom-certificates-with-wildcard-generated-ones/17808/1)

    docker-compose.yml

    version: '3.7'
    
    services:
      caddy:
        build: ./caddy
        restart: unless-stopped
        networks:
          backbone:
            ipv4_address: 10.0.0.12
        ports:
          - "80:80"
          - "443:443"
          - "21443:21443"
        volumes:
          - "./caddy/Caddyfile:/etc/caddy/Caddyfile"
          - "./caddy/data:/data"
          - "./caddy/cf-certs/certificate.pem:/etc/ssl/certs/cf-certificate.pem"
          - "./caddy/cf-certs/origin-pull-ca.pem:/etc/ssl/certs/cf-origin-pull-ca.pem"
          - "./caddy/cf-certs/privatekey.pem:/etc/ssl/private/cf-key.pem"
        env_file:
          - ./common.env
          - ./caddy/secrets.env
        dns: 10.0.0.3
    
    networks:
      backbone:
        driver: bridge
        driver_opts:
          com.docker.network.bridge.name: backbone
        ipam:
          config:
            - subnet: 10.0.0.0/27
    

    Dockerfile

    FROM caddy:builder-alpine AS builder
    
    RUN xcaddy build \
        --with github.com/caddy-dns/cloudflare
    
    FROM caddy:alpine
    
    COPY --from=builder /usr/bin/caddy /usr/bin/caddy
    

    Caddyfile

    *.example.com:443 {
    	tls {
    		dns cloudflare {env.CADDY_CLOUDFLARE_TOKEN}
    	}
    
    	@homeassistant host homeassistant.example.com
    	handle @homeassistant {
    		encode zstd gzip
    		reverse_proxy homeassistant:8123
    	}
    
    	@other host other.example.com
    	handle @other {
    		encode zstd gzip
    		reverse_proxy other
    	}
    }
    
    :21443 {
    	 tls /etc/ssl/certs/cf-certificate.pem /etc/ssl/private/cf-key.pem {
    		 client_auth {
    			 mode require_and_verify
    			 trusted_ca_cert_file /etc/ssl/certs/cf-origin-pull-ca.pem
    		 }
    	 }
    
    	 @homeassistant host homeassistant-external.example.com
    	 handle @homeassistant {
    		 encode zstd gzip
    		 reverse_proxy homeassistant:8123
    	 }
    }
    

    Log entries

    {"level":"info","ts":1669049465.481152,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":"caddyfile"}
    {"level":"warn","ts":1669049465.4910066,"msg":"Caddyfile input is not formatted; run the 'caddy fmt' command to fix inconsistencies","adapter":"caddyfile","file":"/etc/caddy/Caddyfile","line":2}
    {"level":"info","ts":1669049465.4954476,"logger":"admin","msg":"admin endpoint started","address":"localhost:2019","enforce_origin":false,"origins":["//localhost:2019","//[::1]:2019","//127.0.0.1:2019"]}
    {"level":"info","ts":1669049465.4981682,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0x4000440310"}
    {"level":"info","ts":1669049465.50363,"logger":"http","msg":"server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS","server_name":"srv0","https_port":443}
    {"level":"info","ts":1669049465.5037131,"logger":"http","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
    {"level":"info","ts":1669049465.51021,"logger":"http","msg":"enabling HTTP/3 listener","addr":":443"}
    {"level":"info","ts":1669049465.5101776,"logger":"tls","msg":"cleaning storage unit","description":"FileStorage:/data/caddy"}
    {"level":"info","ts":1669049465.510438,"msg":"failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB). See https://github.com/lucas-clemente/quic-go/wiki/UDP-Receive-Buffer-Size for details."}
    {"level":"debug","ts":1669049465.5105987,"logger":"http","msg":"starting server loop","address":"[::]:443","tls":true,"http3":true}
    {"level":"info","ts":1669049465.5106263,"logger":"http.log","msg":"server running","name":"srv0","protocols":["h1","h2","h3"]}
    {"level":"debug","ts":1669049465.5107412,"logger":"http","msg":"starting server loop","address":"[::]:80","tls":false,"http3":false}
    {"level":"info","ts":1669049465.5107656,"logger":"http.log","msg":"server running","name":"remaining_auto_https_redirects","protocols":["h1","h2","h3"]}
    {"level":"info","ts":1669049465.5107765,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["*.example.com"]}
    {"level":"debug","ts":1669049465.5117052,"logger":"tls","msg":"loading managed certificate","domain":"*.example.com","expiration":1676811013,"issuer_key":"acme-v02.api.letsencrypt.org-directory","storage":"FileStorage:/data/caddy"}
    {"level":"debug","ts":1669049465.5124776,"logger":"tls.cache","msg":"added certificate to cache","subjects":["*.example.com"],"expiration":1676811013,"managed":true,"issuer_key":"acme-v02.api.letsencrypt.org-directory","hash":"73ca35f4146d93539ede788e63f664049395110f58b0fbd301b215124fb07479","cache_size":1,"cache_capacity":10000}
    {"level":"debug","ts":1669049465.5125697,"logger":"events","msg":"event","name":"cached_managed_cert","id":"48c0b6ea-a061-4272-b97d-0564946e6fac","origin":"tls","data":{"sans":["*.example.com"]}}
    {"level":"info","ts":1669049465.5134115,"logger":"tls","msg":"finished cleaning storage units"}
    {"level":"info","ts":1669049465.5136263,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"}
    {"level":"info","ts":1669049465.5136645,"msg":"serving initial configuration"}
    
    opened by pedrolamas 0
  • Placeholder in error code only works with 2 parameters

    Placeholder in error code only works with 2 parameters

    When trying to use a placeholder in the error directive, Caddy seems to be confused if it should be a error code or error message.

    Consider this Caddyfile (trying to implement https://kubernetes.github.io/ingress-nginx/user-guide/custom-errors/):

    http://:8080
    
    @custom_err header_regexp X-Code ^\d+$
    # works
    error @custom_err "ERR" {header.X-Code}
    # doesn't work
    #error @custom_err {header.X-Code}
    respond "okay"
    
    handle_errors {
            respond "{err.status_code} | {err.status_text} | {err.message}"
    }
    

    Test with: curl -v -H X-Code:503 http://localhost:8080/

    When using the 1-argument form of error, this returns code 500 (Caddy's default), but when using the 2-argument form, this correctly returns 503.

    opened by TobiX 0
  • version: don't panic if read build info doesn't work

    version: don't panic if read build info doesn't work

    If debug.ReadBuildInfo() doesn't return the build information we should not try to access it. Especially if users only want to build with the CustomVersion we should not assume access to debug.ReadBuildInfo().

    The build environment where this isn't available for me is when building with bazel.

    under review :monocle_face: 
    opened by lukedirtwalker 4
  • Feature request: configurable autosave behaviour

    Feature request: configurable autosave behaviour

    What would you like to have changed?

    A Caddyfile configuration option to enable/disable autosaving the server's configuration state could be useful to reduce some log noise.

    Why is this feature a useful, necessary, and/or important addition to this project?

    This is low priority -- it's not hugely necessary or important -- but I noticed some log messages relating to caddy attempting to autosave configuration to disk, and from there noticed that the relevant allowPersist variable is hardcoded in v2.6.2.

    For sites where configuration is static and/or configuration writes are not expected/possible, it could make sense to allow that variable to be configurable.

    What alternatives are there, or what are you doing in the meantime to work around the lack of this feature?

    Failure to write the autosaved configuration is not a fatal error, so the service continues to run.

    opened by jayaddison 3
  • X-Accel-Redirect setup doesn't work due to strange behaior of rewrite

    X-Accel-Redirect setup doesn't work due to strange behaior of rewrite

    Hey ! I'm trying to configure a pretty simple X-Accel-Direct kind of setup under Caddy 2.6.2, but think I encountered an issue that prevents me to do so.

    My stripped down Caddyfile looks like this:

    localhost {
        reverse_proxy service_a:5000 {
            @accel header X-Accel-Redirect *
            handle_response @accel {
                rewrite * {rp.header.X-Accel-Redirect}
                reverse_proxy service_b:5000
            }
        }
    }
    

    The service_a returns a response with a header X-Accel-Redirect: /hello?some=param&some_other=param. This is be picked by Caddy and rewritten so that this query is handled by service_b. The rewrite of the path works, but the GET params get swallowed and are not visible to service_b where I only see /hello.

    It works as expected when I hardcode the same value in the caddy file like this (which IMO should be 100% equivalent).

    localhost {
        reverse_proxy service_a:5000 {
            @accel header X-Accel-Redirect *
            handle_response @accel {
                rewrite * /hello?some=param&some_other=param
                reverse_proxy service_b:5000
            }
        }
    }
    

    Just to understand what's happening, I tried with some variants such as rewrite * /hello?{rp.header.X-Accel-Redirect} with just the paramters in the header. In this case, service_b sees http://localhost/hello?some%3Dparam%26some_other%3Dparam, so not good either.

    Seems some rogue urlencoding happens, but I couldn't find anything in the doc about that.

    Any pointer about how to solve this ? I searched through the issues but could not find anything about this exactly.

    discussion :speech_balloon: 
    opened by olivierdalang 4
Releases(v2.6.2)
Owner
Caddy
The ultimate server: enterprise-ready, extensible, open source, and automatic HTTPS with a configuration API
Caddy
Caddy: an extensible server platform that uses TLS by default

a project Every site on HTTPS Caddy is an extensible server platform that uses TLS by default. Releases · Documentation · Get Help Menu Features Insta

Blizard 0 Nov 7, 2021
⚡ A fast, lightweight, and secure chat protocol, client and server, written in Go.

⚡ A fast, lightweight, and secure chat protocol, client and server, written in Go.

Bolt 17 Oct 27, 2022
:tophat: Small self-contained pure-Go web server with Lua, Markdown, HTTP/2, QUIC, Redis and PostgreSQL support

Web server with built-in support for QUIC, HTTP/2, Lua, Markdown, Pongo2, HyperApp, Amber, Sass(SCSS), GCSS, JSX, BoltDB (built-in, stores the databas

Alexander F. Rødseth 2.1k Nov 28, 2022
Heart 💜A high performance Lua web server with a simple, powerful API

Heart ?? A high performance Lua web server with a simple, powerful API. See the full documentation here. Overview Heart combines Go's fasthttp with Lu

Hyperspace Logistics 77 Aug 31, 2022
Lightweight go web server that provides a searchable directory index.

autoindex Lightweight go web server that provides a searchable directory index. Optimized for handling large numbers of files (100k+) and remote file

Niels AD 22 Aug 28, 2022
Oogway is a simple web server with dynamic content generation and extendability in mind supporting a Git based workflow.

Oogway Oogway is a simple web server with dynamic content generation and extendability in mind supporting a Git based workflow. It's somewhere in betw

Emvi 6 Nov 9, 2022
Static Content Web Server

Static Content Web Server The main purpose of the project is to develop static server that can be used with modern javascript frameworks (React, vue.j

Rinat 1 Dec 17, 2021
Web server for running Brainfuck on the backend

Brainfuck Web Server Web server for running Brainfuck on the backend Run go run . <brainfuck file> The server will start on port 8080 by default. You

Fabrizio Delcompare 3 Oct 25, 2021
HTTP Echo is a go web server that echos back the arguments given to it.

HTTP Echo is a go web server that echos back the arguments given to it. This is especially useful for demos or a more extensive "hello world" application in Docker or Kubernetes.

jxlwqq 7 Jul 27, 2022
A simple http-web server logging incoming requests to stdout with simple http-interface.

http-cli-echo-logger A simple http-web server logging incoming requests to stdout with simple http-interface. Run locally go run ./cmd/main.go Default

Andrii Bosonchenko 5 Jul 18, 2022
Golang-redis-webserver - Web server using redis

Web Server using Redis Api REST Database SQLITE3 Cache Redis # Creating record s

Paulo Lopes Estevão 1 Jun 19, 2022
a simple http server as replacement of python -m http.server

ser a simple http server as replacement of python -m http.server

Changkun Ou 5 Sep 26, 2022
OpenAPI specs for your Go server, generated at server runtime. No CLI, no code generation, and no HTTP

Overview "oas" is short for "OpenAPI Spec". Go package for generating OpenAPI docs at runtime. Non-features: No code generation. No CLI. No magic comm

Nelo Mitranim 0 Dec 3, 2021
A Language Server Protocol (LSP) server for Jsonnet

Jsonnet Language Server A Language Server Protocol (LSP) server for Jsonnet. Features Jump to definition self-support.mp4 dollar-support.mp4 Error/War

Grafana Labs 88 Nov 20, 2022
Open platform to collect and prioritize product feedback

Fider A platform to collect and organize customer feedback. Let your customers share, vote and discuss on suggestions they have to make your product e

getfider 2.1k Nov 29, 2022
A simple SHOUTcast server.

DudelDu DudelDu is a simple audio/video streaming server using the SHOUTcast protocol. Features Supports various streaming clients: VLC, ServeStream,

Matthias Ladkau 138 Nov 20, 2022
A feature flag solution, with only a YAML file in the backend (S3, GitHub, HTTP, local file ...), no server to install, just add a file in a central system and refer to it. 🎛️

??️ go-feature-flag A feature flag solution, with YAML file in the backend (S3, GitHub, HTTP, local file ...). No server to install, just add a file i

Thomas Poignant 549 Nov 23, 2022
An XMPP server written in Go (Golang).

jackal An XMPP server written in Go. About jackal is a free, open-source, high performance XMPP server which aims to be known for its stability, simpl

Miguel Ángel Ortuño 1.4k Nov 25, 2022