From ab80ff4fd2911afc394b9dbceeb9f71c7a0b7ec1 Mon Sep 17 00:00:00 2001 From: Matt Holt Date: Wed, 27 Jan 2021 16:16:04 -0700 Subject: admin: Identity management, remote admin, config loaders (#3994) This commits dds 3 separate, but very related features: 1. Automated server identity management How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it). Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs. This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below). 2. Remote administration over secure connection This feature adds generic remote admin functionality that is safe to expose on a public interface. - The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint. - It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS. - TLS cannot be disabled on this endpoint. - TLS mutual auth is required, and cannot be disabled. - The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded. - The TLS server takes care of verifying the client. - The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\ - Sensible defaults are still WIP. - Config fields subject to change/renaming. 3. Dyanmic config loading at startup Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR. Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense). This PR comes with a standard config loader module called `caddy.config_loaders.http`. Caddyfile config for all of this can probably be added later. COMMITS: * admin: Secure socket for remote management Functional, but still WIP. Optional secure socket for the admin endpoint is designed for remote management, i.e. to be exposed on a public port. It enforces TLS mutual authentication which cannot be disabled. The default port for this is :2021. The server certificate cannot be specified manually, it MUST be obtained from a certificate issuer (i.e. ACME). More polish and sensible defaults are still in development. Also cleaned up and consolidated the code related to quitting the process. * Happy lint * Implement dynamic config loading; HTTP config loader module This allows Caddy to load a dynamic config when it starts. Dynamically-loaded configs are intentionally not persisted to storage. Includes an implementation of the standard config loader, HTTPLoader. Can be used to download configs over HTTP(S). * Refactor and cleanup; prevent recursive config pulls Identity management is now separated from remote administration. There is no need to enable remote administration if all you want is identity management, but you will need to configure identity management if you want remote administration. * Fix lint warnings * Rename identities->identifiers for consistency --- modules/caddytls/acmeissuer.go | 21 ++++++++++++++++++++- modules/caddytls/tls.go | 12 ++++++++++++ 2 files changed, 32 insertions(+), 1 deletion(-) (limited to 'modules/caddytls') diff --git a/modules/caddytls/acmeissuer.go b/modules/caddytls/acmeissuer.go index 64725c9..bbcd5d7 100644 --- a/modules/caddytls/acmeissuer.go +++ b/modules/caddytls/acmeissuer.go @@ -59,6 +59,13 @@ type ACMEIssuer struct { // other than ACME transactions. Email string `json:"email,omitempty"` + // If you have an existing account with the ACME server, put + // the private key here in PEM format. The ACME client will + // look up your account information with this key first before + // trying to create a new one. You can use placeholders here, + // for example if you have it in an environment variable. + AccountKey string `json:"account_key,omitempty"` + // If using an ACME CA that requires an external account // binding, specify the CA-provided credentials here. ExternalAccount *acme.EAB `json:"external_account,omitempty"` @@ -98,15 +105,26 @@ func (ACMEIssuer) CaddyModule() caddy.ModuleInfo { func (iss *ACMEIssuer) Provision(ctx caddy.Context) error { iss.logger = ctx.Logger(iss) + repl := caddy.NewReplacer() + // expand email address, if non-empty if iss.Email != "" { - email, err := caddy.NewReplacer().ReplaceOrErr(iss.Email, true, true) + email, err := repl.ReplaceOrErr(iss.Email, true, true) if err != nil { return fmt.Errorf("expanding email address '%s': %v", iss.Email, err) } iss.Email = email } + // expand account key, if non-empty + if iss.AccountKey != "" { + accountKey, err := repl.ReplaceOrErr(iss.AccountKey, true, true) + if err != nil { + return fmt.Errorf("expanding account key PEM '%s': %v", iss.AccountKey, err) + } + iss.AccountKey = accountKey + } + // DNS providers if iss.Challenges != nil && iss.Challenges.DNS != nil && iss.Challenges.DNS.ProviderRaw != nil { val, err := ctx.LoadModule(iss.Challenges.DNS, "ProviderRaw") @@ -161,6 +179,7 @@ func (iss *ACMEIssuer) makeIssuerTemplate() (certmagic.ACMEManager, error) { CA: iss.CA, TestCA: iss.TestCA, Email: iss.Email, + AccountKeyPEM: iss.AccountKey, CertObtainTimeout: time.Duration(iss.ACMETimeout), TrustedRoots: iss.rootPool, ExternalAccount: iss.ExternalAccount, diff --git a/modules/caddytls/tls.go b/modules/caddytls/tls.go index fd3473e..489d87f 100644 --- a/modules/caddytls/tls.go +++ b/modules/caddytls/tls.go @@ -306,9 +306,11 @@ func (t *TLS) Manage(names []string) error { // requires that the automation policy for r.Host has an issuer of type // *certmagic.ACMEManager, or one that is ACME-enabled (GetACMEIssuer()). func (t *TLS) HandleHTTPChallenge(w http.ResponseWriter, r *http.Request) bool { + // no-op if it's not an ACME challenge request if !certmagic.LooksLikeHTTPChallenge(r) { return false } + // try all the issuers until we find the one that initiated the challenge ap := t.getAutomationPolicyForName(r.Host) type acmeCapable interface{ GetACMEIssuer() *ACMEIssuer } @@ -320,6 +322,16 @@ func (t *TLS) HandleHTTPChallenge(w http.ResponseWriter, r *http.Request) bool { } } } + + // it's possible another server in this process initiated the challenge; + // users have requested that Caddy only handle HTTP challenges it initiated, + // so that users can proxy the others through to their backends; but we + // might not have an automation policy for all identifiers that are trying + // to get certificates (e.g. the admin endpoint), so we do this manual check + if challenge, ok := certmagic.GetACMEChallenge(r.Host); ok { + return certmagic.SolveHTTPChallenge(t.logger, w, r, challenge.Challenge) + } + return false } -- cgit v1.2.3