{"record":{"id":"dbf924f221ebbddc","repo":"caddyserver/caddy","slug":"configuring-tls-client-authentication-v","errorCode":null,"errorMessage":"configuring TLS client authentication: %v","messagePattern":"configuring TLS client authentication: (.+?)","errorType":"validation","errorClass":null,"httpStatus":null,"severity":"error","filePath":"modules/caddytls/connpolicy.go","lineNumber":386,"sourceCode":"\n\t// min and max protocol versions\n\tif (p.ProtocolMin != \"\" && p.ProtocolMax != \"\") && p.ProtocolMin > p.ProtocolMax {\n\t\treturn fmt.Errorf(\"protocol min (%x) cannot be greater than protocol max (%x)\", p.ProtocolMin, p.ProtocolMax)\n\t}\n\tif p.ProtocolMin != \"\" {\n\t\tcfg.MinVersion = SupportedProtocols[p.ProtocolMin]\n\t}\n\tif p.ProtocolMax != \"\" {\n\t\tcfg.MaxVersion = SupportedProtocols[p.ProtocolMax]\n\t}\n\n\t// client authentication\n\tif p.ClientAuthentication != nil {\n\t\tif err := p.ClientAuthentication.provision(ctx); err != nil {\n\t\t\treturn fmt.Errorf(\"provisioning client CA: %v\", err)\n\t\t}\n\t\tif err := p.ClientAuthentication.ConfigureTLSConfig(cfg); err != nil {\n\t\t\treturn fmt.Errorf(\"configuring TLS client authentication: %v\", err)\n\t\t}\n\n\t\t// Prevent privilege escalation in case multiple vhosts are configured for\n\t\t// this TLS server; we could potentially figure out if that's the case, but\n\t\t// that might be complex to get right every time. Actually, two proper\n\t\t// solutions could leave tickets enabled, but I am not sure how to do them\n\t\t// properly without significant time investment; there may be new Go\n\t\t// APIs that alloaw this (Wrap/UnwrapSession?) but I do not know how to use\n\t\t// them at this time. TODO: one of these is a possible future enhancement:\n\t\t// A) Prevent resumptions across server identities (certificates): binding the ticket to the\n\t\t// certificate we would serve in a full handshake, or even bind a ticket to the exact SNI\n\t\t// it was issued under (though there are proposals for session resumption across hostnames).\n\t\t// B) Prevent resumptions falsely authenticating a client: include the realm in the ticket,\n\t\t// so that it can be validated upon resumption.\n\t\tcfg.SessionTicketsDisabled = true\n\t}\n\n\tif p.InsecureSecretsLog != \"\" {","sourceCodeStart":368,"sourceCodeEnd":404,"githubUrl":"https://github.com/caddyserver/caddy/blob/50e54ee279aa1e504fe218ca49ab6ae16c100410/modules/caddytls/connpolicy.go#L368-L404","documentation":"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.","triggerScenarios":"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.","commonSituations":"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.","solutions":["Read the wrapped cause; it comes from the verifier's ConfigureTLSConfig","Simplify: test with the standard 'verifier' (standard CA verification) to isolate whether a custom/leaf verifier is the problem","Ensure the verifier's inputs (trust pool with actual certs) are complete","If from a plugin, report upstream with the inner error text"],"exampleFix":null,"handlingStrategy":"try-catch","validationCode":null,"typeGuard":null,"tryCatchPattern":null,"preventionTips":["Prefer stock verifiers; custom verifier plugins should have integration tests covering ConfigureTLSConfig","When a configure failure appears, compare against a minimal known-good client_auth block to bisect","Keep verifier plugins updated in lockstep with Caddy since they hook internal interfaces"],"tags":["caddy","tls","client-auth","configuration","verifier"],"backgroundTag":null,"analyzedSha":"50e54ee279aa1e504fe218ca49ab6ae16c100410","analyzedAt":"2026-08-15T09:20:21.641Z","schemaVersion":2},"datasetVersion":"2026-08-15T22:17:37.221Z"}