66863aad3b
* caddytls: Add support for ZeroSSL; add Caddyfile support for issuers
Configuring issuers explicitly in a Caddyfile is not easily compatible
with existing ACME-specific parameters such as email or acme_ca which
infer the kind of issuer it creates (this is complicated now because
the ZeroSSL issuer wraps the ACME issuer)... oh well, we can revisit
that later if we need to.
New Caddyfile global option:
{
cert_issuer <name> ...
}
Or, alternatively, as a tls subdirective:
tls {
issuer <name> ...
}
For example, to use ZeroSSL with an API key:
{
cert_issuser zerossl API_KEY
}
For now, that still uses ZeroSSL's ACME endpoint; it fetches EAB
credentials for you. You can also provide the EAB credentials directly
just like any other ACME endpoint:
{
cert_issuer acme {
eab KEY_ID MAC_KEY
}
}
All these examples use the new global option (or tls subdirective). You
can still use traditional/existing options with ZeroSSL, since it's
just another ACME endpoint:
{
acme_ca https://acme.zerossl.com/v2/DV90
acme_eab KEY_ID MAC_KEY
}
That's all there is to it. You just can't mix-and-match acme_* options
with cert_issuer, because it becomes confusing/ambiguous/complicated to
merge the settings.
* Fix broken test
This test was asserting buggy behavior, oops - glad this branch both
discovers and fixes the bug at the same time!
* Fix broken test (post-merge)
* Update modules/caddytls/acmeissuer.go
Fix godoc comment
Co-authored-by: Francis Lavoie <lavofr@gmail.com>
* Add support for ZeroSSL's EAB-by-email endpoint
Also transform the ACMEIssuer into ZeroSSLIssuer implicitly if set to
the ZeroSSL endpoint without EAB (the ZeroSSLIssuer is needed to
generate EAB if not already provided); this is now possible with either
an API key or an email address.
* go.mod: Use latest certmagic, acmez, and x/net
* Wrap underlying logic rather than repeating it
Oops, duh
* Form-encode email info into request body for EAB endpoint
Co-authored-by: Francis Lavoie <lavofr@gmail.com>
|
||
|---|---|---|
| .github | ||
| caddyconfig | ||
| caddytest | ||
| cmd | ||
| modules | ||
| .gitignore | ||
| .golangci.yml | ||
| .goreleaser.yml | ||
| admin.go | ||
| admin_test.go | ||
| AUTHORS | ||
| caddy.go | ||
| caddy_test.go | ||
| context.go | ||
| context_test.go | ||
| go.mod | ||
| go.sum | ||
| LICENSE | ||
| listeners.go | ||
| listeners_fuzz.go | ||
| listeners_test.go | ||
| logging.go | ||
| modules.go | ||
| modules_test.go | ||
| README.md | ||
| replacer.go | ||
| replacer_fuzz.go | ||
| replacer_test.go | ||
| sigtrap.go | ||
| sigtrap_nonposix.go | ||
| sigtrap_posix.go | ||
| storage.go | ||
| usagepool.go | ||
Every site on HTTPS
Caddy is an extensible server platform that uses TLS by default.
Releases · Documentation · Get Help
Menu
Powered by
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
- Let's Encrypt for public sites
- Fully-managed local CA for internal names & IPs
- Can coordinate with other Caddy instances in a cluster
- Stays up when other servers go down due to TLS/OCSP/certificate-related issues
- 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
Build from source
Requirements:
For development
$ git clone "https://github.com/caddyserver/caddy.git"
$ cd caddy/cmd/caddy/
$ go build
Note: These steps will not embed proper version information. For that, please follow the instructions below.
With version information and/or plugins
Using our builder tool, xcaddy...
$ xcaddy build
...the following steps are automated:
- Create a new folder:
mkdir caddy - Change into it:
cd caddy - Copy Caddy's main.go into the empty folder. Add imports for any custom plugins you want to add.
- Initialize a Go module:
go mod init caddy - (Optional) Pin Caddy version:
go get github.com/caddyserver/caddy/v2@versionreplacingversionwith a git tag or commit. - (Optional) Add plugins by adding their import:
_ "import/path/here" - Compile:
go build
Quick start
The Caddy website has documentation that includes tutorials, quick-start guides, reference, and more.
We recommend that all users 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:
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.
-
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 Light Code Labs, LLC.
- Project on Twitter: @caddyserver
- Author on Twitter: @mholt6