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
- Read the wrapped error and fix the underlying storage/permission issue (chown the storage dir to the service user; ensure the volume is writable)
- Validate with caddy validate --config <file> run as the same user as the daemon
- If a custom storage module is in play, test it standalone or temporarily switch to file-system storage to confirm
- 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
- Ensure the storage directory is writable by the service user before first start
- Containerize with a named volume for /data so the default CA survives and stays writable
- Monitor first-start logs; a failed default-CA provisioning usually repeats on every request needing TLS
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
- failed to get root and intermediate cert for CA %s: %v
- failed to provision CA %s, %w
- loading storage module: %v
- creating storage configuration: %v
- loading signing key: %v
AI-assisted analysis of caddyserver/caddy@50e54ee279 (2026-08-15).
Data as JSON: /api/errors/ab84ad6fc7d764d9.
Report an issue: GitHub.