caddyserver/caddy · critical

failed to provision default CA: %s

Error message

failed to provision default CA: %s

What it means

Returned by PKI.GetCA (modules/caddypki/pki.go:139) when the default CA id was requested but not yet provisioned, and the lazy call to ProvisionDefaultCA fails. It wraps the provisioning error, which typically points at storage or filesystem problems rather than user config, since the default CA requires no configuration.

Source

Thrown at modules/caddypki/pki.go:139

func (p *PKI) Stop() error {
	return nil
}

// GetCA retrieves a CA by ID. If the ID is the default
// CA ID, and it hasn't been provisioned yet, it will
// be provisioned.
func (p *PKI) GetCA(ctx caddy.Context, id string) (*CA, error) {
	ca, ok := p.CAs[id]
	if !ok {
		// for anything other than the default CA ID, error out if it wasn't configured
		if id != DefaultCAID {
			return nil, fmt.Errorf("no certificate authority configured with id: %s", id)
		}

		// for the default CA ID, provision it, because we want it to "just work"
		err := p.ProvisionDefaultCA(ctx)
		if err != nil {
			return nil, fmt.Errorf("failed to provision default CA: %s", err)
		}
		ca = p.CAs[id]
	}

	return ca, nil
}

// Interface guards
var (
	_ caddy.Provisioner = (*PKI)(nil)
	_ caddy.App         = (*PKI)(nil)
)

View on GitHub (pinned to 50e54ee279)

Solutions

  1. Read the wrapped error and fix the underlying storage/permission issue (chown the storage dir to the service user; ensure the volume is writable)
  2. Validate with caddy validate --config <file> run as the same user as the daemon
  3. If a custom storage module is in play, test it standalone or temporarily switch to file-system storage to confirm
  4. After fixing, restart Caddy so GetCA re-attempts provisioning

Example fix

# before
volumes:
  - ./caddy-data:/data   # owned by root, caddy runs as app

# after
volumes:
  - ./caddy-data:/data
# ensure ownership
#   chown -R 1000:1000 ./caddy-data
Defensive patterns

Strategy: validation

Validate before calling

# before starting, verify the default CA can write its storage
sudo -u caddy mkdir -p /var/lib/caddy/pki/authorities/local
sudo -u caddy touch /var/lib/caddy/pki/authorities/local/.probe && rm /var/lib/caddy/pki/authorities/local/.probe

Try / catch

ca, err := p.GetCA(ctx, DefaultCAID)
if err != nil {
    // wrapped message names the real cause (storage/permissions);
    // fix environment, then restart so GetCA lazily re-provisions
    return nil, err
}

Prevention

When it happens

Trigger: A module (e.g. the internal TLS issuer) calls GetCA(ctx, 'local') before any CA exists and ProvisionDefaultCA fails - unwritable storage for <storage>/pki/authorities/local, a failing custom storage backend, or permission errors creating the root/intermediate key files.

Common situations: Same as other default-CA provisioning failures: container users without write access to the data volume, read-only filesystems, network storage plugins that cannot create directories, or disk quota exhaustion during first-run key generation.

Related errors


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