certbot "Some challenges have failed" in CI

By Daniel Zoghalchali·Latchkey

certbot ran the ACME challenges and at least one did not validate, so it aborts with "Some challenges have failed." The detail lines above name the failing domain and challenge type. Common CI causes are the HTTP-01 file not reachable on port 80, a DNS-01 TXT record that is wrong or not propagated, or an egress rule blocking Let's Encrypt from reaching the host. Read the per-domain detail to see which.

What this error means

certbot ends with "Some challenges have failed." and, above it, a per-domain "Detail:" line explaining why the specific challenge did not validate.

Certbot failed to authenticate some domains (authenticator: standalone).
Domain: example.com
Type:   connection
Detail: Fetching http://example.com/.well-known/acme-challenge/abc: Timeout
Some challenges have failed.

Common causes

The HTTP-01 path is unreachable on port 80

Let's Encrypt cannot fetch the challenge file because port 80 is blocked, the standalone server is not bound, or a proxy sits in front.

The DNS-01 TXT record is wrong or not propagated

For a DNS challenge, the _acme-challenge TXT value does not match or has not propagated, so validation fails.

How to fix it

Read the per-domain detail and fix the challenge

1. Find the "Detail:" line for the failing domain to see the exact reason.
2. For HTTP-01, ensure port 80 is open and the challenge file is served.
3. For DNS-01, confirm the TXT record value and that it has propagated publicly.

# for standalone HTTP-01, port 80 must be reachable
sudo certbot certonly --standalone -d example.com --dry-run

Validate DNS-01 records publicly

Query the challenge TXT record against a public resolver to confirm it matches what certbot set.

dig +short TXT _acme-challenge.example.com @1.1.1.1

Make the gate meaningful

• Fail the build on the severity you actually intend to block, and set it explicitly. A scanner that reports without failing is documentation, not a gate.
• Scan the artifact you ship, not the source tree. A vulnerability in a base image will not appear in a source scan.
• Pin the scanner version and its database snapshot for reproducibility, then update deliberately; a floating database turns an unrelated push into a red build.
• Give the job a way to record accepted risk, or people will disable the gate rather than triage it.

How to prevent it

• Use --dry-run against staging in CI before real issuance.
• Ensure port 80 is reachable for HTTP-01 or use DNS-01 where it is not.
• Confirm DNS-01 TXT records propagate publicly before validating.

Frequently asked questions

Related guides

References

• GitHub Actions documentation