Getting log erro "no information found to solve challenge for identifier:"

Help
1

1. Caddy version (caddy version):

v2.4.6 h1:HGkGICFGvyrodcqOOclHKfvJC0qTU7vny/7FhYp9hNw=

2. How I run Caddy:

a. System environment:

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.6 LTS"

Caddy is running using systemd

b. Command:

systemctl start caddy

c. Service/unit/compose file:

[Unit]
Description=Caddy
Documentation=https://caddyserver.com/docs/
After=network.target network-online.target
Requires=network-online.target

[Service]
Type=notify
User=caddy
Group=caddy
ExecStart=/usr/bin/caddy run --config /etc/caddy/Caddyfile
ExecReload=/usr/bin/caddy reload -config /etc/caddy/Caddyfile
TimeoutStopSec=5s
LimitNOFILE=1048576
LimitNPROC=512
PrivateTmp=true
ProtectSystem=full
AmbientCapabilities=CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.target

d. My complete Caddyfile or JSON config:

report.alpenv.eurac.edu {
	tls it@eurac.edu

	basicauth /LTER/* {
         ...
	}

	basicauth /MONALISA/* {
		...
	}

	file_server /LTER/* {
		root /lter/
		hide *.dat *.csv *.tar
	}

	file_server /MONALISA/* {
		root /lter/
		hide *.dat *.csv *.tar
	}
}

pics.alpenv.eurac.edu {
	tls it@eurac.edu

	file_server /* {
		root /lter/pics
		hide *.dat *.csv *.tar
	}
}

3. The problem I’m having:

Everything is working except we are seeing a continouse flow of the below logs.

4. Error messages and/or full log output:

Feb 01 13:43:23 XDCltb02 caddy[14593]: {"level":"error","ts":1643719403.3632011,"logger":"tls.issuance.acme","msg":"looking up info for HTTP challenge","host":"pics.alpenv.eurac.edu","error":"no information found to solve challenge for identifier: pics.alpenv.eurac.edu"}
Feb 01 13:43:23 XDCltb02 caddy[14593]: {"level":"error","ts":1643719403.3632681,"logger":"tls.issuance.acme","msg":"looking up info for HTTP challenge","host":"pics.alpenv.eurac.edu","error":"no information found to solve challenge for identifier: pics.alpenv.eurac.edu"}
Feb 01 13:43:29 XDCltb02 caddy[14593]: {"level":"error","ts":1643719409.7133195,"logger":"tls.issuance.acme","msg":"looking up info for HTTP challenge","host":"report.alpenv.eurac.edu","error":"no information found to solve challenge for identifier: report.alpenv.eurac.edu"}
Feb 01 13:43:29 XDCltb02 caddy[14593]: {"level":"error","ts":1643719409.7134006,"logger":"tls.issuance.acme","msg":"looking up info for HTTP challenge","host":"report.alpenv.eurac.edu","error":"no information found to solve challenge for identifier: report.alpenv.eurac.edu"}

5. What I already tried:

  1. We stopped Caddy removed all directories under /var/lib/caddy/.local. Started Caddy again everytime with the same result that we see the above logs.
  2. Add the following to the Caddyfile:
pics-ts.alpenv.eurac.edu {
	tls it@eurac.edu

	file_server /* {
		root /mnt/pics
		hide *.dat *.csv *.tar
	}
}

For the test domain no such error messages are generated.
3. Tested with curl -I http://<domain> that the redirect work and that the Ports 80 & 443 are reachable.

6. Links to relevant resources:

2

Strange.

These errors mean that some client outside your network is making requests to grab a challenge, but Caddy is rejecting the request because it no longer has a challenge for that hostname.

It’s hard to say why this is happening, but I don’t think this is the first report of this we’ve seen. I think ZeroSSL has some issues surrounding its HTTP challenge solver that would cause jobs to continually get retried like this. Hmm.

1 Like
3

After looking the access log we identified who makes the request.

Sorry for spamming, we should have taken a closer look at the access log! Thanks for the help!!!

4

What was causing it? What did you determine? Details would be very useful to know in case it happens again to someone else.

1 Like
5

I’m also getting this error on a lot of domains that issue with ZeroSSL.
I still didn’t figure out why it is happening and those domains don’t get any SSL.

6

We migrated the two sites from our K8s cluster to a standalone VM with Caddy. On the K8s cluster we only shrunk the deployments of the sites to 0 and left the ingress configuration intact. Changed the DNS entries to point to the new VM. The K8s ingress constantly tired to lookup those challenges. After enabling the access log on the Caddy site we identified the requester IP belongs to our K8s cluster. Deleting the ingress configuration solved the issue.

7

I’m confused, does the K8s ingress repeatedly retry requests that previously failed? That’s weird.

8

No it should not. We are still investigating why it did for these sites.

9

This topic was automatically closed after 30 days. New replies are no longer allowed.