← Problem Library
K8s L5 K8S 1394 · 14 min

A cert-manager HTTP01 solver pod comes up and challenges still fail

The solver is healthy, yet issuance fails because address-family preference changed at the edge and the CA reaches a different path than operators test.

K8sPlatform ReliabilityLevel 5Pro14 min
Scenario

A dual-stack ingress rollout lands and later HTTP01 certificate issuance breaks intermittently for one hostname set.

What to check first
  • Identify the primary failure signal in the The Solver Was Ready and the Internet Arrived on the Wrong Address Family scenario.
  • Separate visible symptoms from the underlying technical dependency.
  • Describe the safest recovery path and the follow-up prevention work.
Checking checklist
  1. Summarize the current impact and the last known change.
  2. Collect direct evidence from logs, runtime state, and configuration before changing anything.
  3. Separate immediate recovery from permanent prevention work.
Recovery and prevention

Inspect actual published family preference and CA reachability before editing issuers or restarting ingress.

Questions worth viewing together
What should you verify first when A cert-manager HTTP01 solver pod comes up and challenges still fail appears?

Community-field Kubernetes problem inspired by cert-manager and ingress community cases where dual-stack exposure changed the challenge path. Challenge traffic may reach a different address family than the one operators validate locally.

What usually causes A cert-manager HTTP01 solver pod comes up and challenges still fail in production?

Teams often blame DNS propagation when the published address-family preference is the real mismatch.

What should you document after resolving A cert-manager HTTP01 solver pod comes up and challenges still fail?

Dual-stack ingress rollouts should explicitly validate ACME challenge behavior across both address families.