caddyserver/caddy · error

provisioning default issuer %d: %T: %v

Error message

provisioning default issuer %d: %T: %v

What it means

DefaultIssuersProvisioned provisions the default issuer chain (default ACME issuer and, when configured, ZeroSSL) returned by DefaultIssuers(). If any of those issuers implement caddy.Provisioner and their Provision returns an error, this wrapper reports the index and Go type of the failing issuer plus the underlying error. It is marked experimental, and is typically invoked for automation policies that specify no issuers of their own.

Source

Thrown at modules/caddytls/automation.go:498

	issuers := []certmagic.Issuer{new(ACMEIssuer)}
	if strings.TrimSpace(userEmail) != "" {
		issuers = append(issuers, &ACMEIssuer{
			CA:    certmagic.ZeroSSLProductionCA,
			Email: userEmail,
		})
	}
	return issuers
}

// DefaultIssuersProvisioned returns empty but provisioned default Issuers from
// DefaultIssuers(). This function is experimental and has no compatibility promises.
func DefaultIssuersProvisioned(ctx caddy.Context) ([]certmagic.Issuer, error) {
	issuers := DefaultIssuers("")
	for i, iss := range issuers {
		if prov, ok := iss.(caddy.Provisioner); ok {
			err := prov.Provision(ctx)
			if err != nil {
				return nil, fmt.Errorf("provisioning default issuer %d: %T: %v", i, iss, err)
			}
		}
	}
	return issuers, nil
}

// ChallengesConfig configures the ACME challenges.
type ChallengesConfig struct {
	// HTTP configures the ACME HTTP challenge. This
	// challenge is enabled and used automatically
	// and by default.
	HTTP *HTTPChallengeConfig `json:"http,omitempty"`

	// TLSALPN configures the ACME TLS-ALPN challenge.
	// This challenge is enabled and used automatically
	// and by default.
	TLSALPN *TLSALPNChallengeConfig `json:"tls-alpn,omitempty"`

View on GitHub (pinned to 50e54ee279)

Solutions

1. Look at the wrapped error and the reported issuer type (%T) to identify which default issuer failed and why, then fix the corresponding global TLS/ACME setting.
2. Set issuers explicitly on the automation policy so defaults are not used, bypassing the failing default configuration.
3. Verify environment variables used in global ACME/email placeholders are set.
4. If using a forked build, confirm patches to default issuers still Provision cleanly.

Example fix

# before: invalid global CA URL breaks default issuer provisioning
{
	acme_ca https://example.invalid/dir
}

# after: correct CA or explicit per-site issuer
{
	acme_ca https://acme-v02.api.letsencrypt.org/directory
}

issuers, err := caddytls.DefaultIssuersProvisioned(ctx)
if err != nil {
    return nil, fmt.Errorf("default issuers unusable; set explicit issuers on the policy: %w", err)
}

When it happens

Trigger: An automation policy without explicit issuers (falling back to defaults) during Provision/RebuildCertMagic, where the default ACMEIssuer's Provision fails — e.g. invalid CA URL, email placeholder expansion failure, or unsupported configuration inherited from global settings.

Common situations: Global ACME settings (acme ca url, email via env placeholder, eab config) that are invalid; upgrading Caddy where DefaultIssuers gained a new provisioning step that rejects old global config; custom builds patching default issuers.

Related errors

• provisioning default public automation policy: %v
• filling in global issuer defaults for AP %d, issuer %d: %v
• acme_dns specified without DNS provider config, but no provi
• filling in global issuer defaults for issuer %d: %v
• getting tls app: %v

AI-assisted analysis of caddyserver/caddy@50e54ee279 (2026-08-15). Data as JSON: /api/errors/68c1ffb249783f86. Report an issue: GitHub.