caddyserver/caddy · error

configuring TLS client authentication: %v

Error message

configuring TLS client authentication: %v

What it means

Returned by buildStandardTLSConfig when ClientAuthentication.ConfigureTLSConfig fails after successful provisioning — i.e. the trust material loaded, but wiring it into the *tls.Config (building the client CA pool, setting verification modes for the verifiers) errored. Distinct from the provisioning error: this is the apply-to-config step.

Source

Thrown at modules/caddytls/connpolicy.go:386

	// min and max protocol versions
	if (p.ProtocolMin != "" && p.ProtocolMax != "") && p.ProtocolMin > p.ProtocolMax {
		return fmt.Errorf("protocol min (%x) cannot be greater than protocol max (%x)", p.ProtocolMin, p.ProtocolMax)
	}
	if p.ProtocolMin != "" {
		cfg.MinVersion = SupportedProtocols[p.ProtocolMin]
	}
	if p.ProtocolMax != "" {
		cfg.MaxVersion = SupportedProtocols[p.ProtocolMax]
	}

	// client authentication
	if p.ClientAuthentication != nil {
		if err := p.ClientAuthentication.provision(ctx); err != nil {
			return fmt.Errorf("provisioning client CA: %v", err)
		}
		if err := p.ClientAuthentication.ConfigureTLSConfig(cfg); err != nil {
			return fmt.Errorf("configuring TLS client authentication: %v", err)
		}

		// Prevent privilege escalation in case multiple vhosts are configured for
		// this TLS server; we could potentially figure out if that's the case, but
		// that might be complex to get right every time. Actually, two proper
		// solutions could leave tickets enabled, but I am not sure how to do them
		// properly without significant time investment; there may be new Go
		// APIs that alloaw this (Wrap/UnwrapSession?) but I do not know how to use
		// them at this time. TODO: one of these is a possible future enhancement:
		// A) Prevent resumptions across server identities (certificates): binding the ticket to the
		// certificate we would serve in a full handshake, or even bind a ticket to the exact SNI
		// it was issued under (though there are proposals for session resumption across hostnames).
		// B) Prevent resumptions falsely authenticating a client: include the realm in the ticket,
		// so that it can be validated upon resumption.
		cfg.SessionTicketsDisabled = true
	}

	if p.InsecureSecretsLog != "" {

View on GitHub (pinned to 50e54ee279)

Solutions

1. Read the wrapped cause; it comes from the verifier's ConfigureTLSConfig
2. Simplify: test with the standard 'verifier' (standard CA verification) to isolate whether a custom/leaf verifier is the problem
3. Ensure the verifier's inputs (trust pool with actual certs) are complete
4. If from a plugin, report upstream with the inner error text

When it happens

Trigger: A verifier that loads fine but cannot configure the TLS config, e.g. a leaf verifier with trust material that cannot be assembled into a verification pool, or a custom verifier plugin returning an error from ConfigureTLSConfig. Reached only after client auth provisioning succeeded.

Common situations: Plugin verifiers whose configure step has extra requirements; inconsistent combinations (verifier leaf with empty trust data after filtering); rarely hit with stock modules since most config errors surface at provision time instead.

Understand the failure class

• SSL/TLS and certificate errors — how TLS handshakes and certificate validation fail.
• Authentication and authorization failures — expired tokens, bad credentials, and missing scopes.

Related errors

• loading client cert verifiers: %v
• provisioning client CA: %v
• two policies with same match criteria have conflicting clien
• parsing certificate at index %d: %v
• reading %s: %v

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