After upgrading to ghcr.io/letsencrypt/pebble:2.5.1, I am seeing the following error in our test suite:
INFO event=SendRequest url=https://localhost:14000/authZ/WKrIeCnHQULq6mp3BD0eEYTlwq7M_MInYnISVm5RmXA
INFO event=ReceivedResponse location=None body="{\n \"status\": \"invalid\",\n \"identifier\": {\n \"type\": \"dns\",\n \"value\": \"<redacted>\"\n },\n \"challenges\": [\n {\n \"type\": \"tls-alpn-01\",\n \"url\": \"https://localhost:14000/chalZ/qCiMNJz2zm1mLtYTUn9hXC4cizqg25g04UI1B2AWrjk\",\n \"token\": \"TlK9my79nS0tSjtdmugDJHWUzE6N1MdK_nMjKQrd0zU\",\n \"status\": \"invalid\",\n \"validated\": \"2024-03-19T16:51:56Z\",\n \"error\": {\n \"type\": \"urn:ietf:params:acme:error:malformed\",\n \"detail\": \"Error occurred while resolving URL \\\"<redacted>\\\": \\\"lookup <redacted> on 8.8.8.8:53: no such host\\\"\",\n \"status\": 400\n }\n }\n ],\n \"expires\": \"2024-03-19T17:51:55Z\"\n}"
This suggests that the -dnsserver setting is not honoured. As a workaround, I was able to specify a custom DNS server for the entire Docker container, but this required changing the port to 53.
After further investigation, the issue seems to be that container parameters are being ignored altogether. The following invocation should fail, but the invalid parameter goes unnoticed:
docker run ghcr.io/letsencrypt/pebble:2.5.1 abc
The container listing shows that the command is translated into /app abc:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e1b1b497e357 ghcr.io/letsencrypt/pebble:2.5.1 "/app abc" 2 minutes ago Up 2 minutes recursing_kare
Another issue I found with the new Docker image is that it does not expose any ports, requiring users to override the ExposedPorts setting when using the Docker daemon directly. Previously, the Dockerfile contained these two lines:
EXPOSE 14000
EXPOSE 15000
After upgrading to
ghcr.io/letsencrypt/pebble:2.5.1, I am seeing the following error in our test suite:This suggests that the
-dnsserversetting is not honoured. As a workaround, I was able to specify a custom DNS server for the entire Docker container, but this required changing the port to 53.After further investigation, the issue seems to be that container parameters are being ignored altogether. The following invocation should fail, but the invalid parameter goes unnoticed:
The container listing shows that the command is translated into
/app abc:Another issue I found with the new Docker image is that it does not expose any ports, requiring users to override the
ExposedPortssetting when using the Docker daemon directly. Previously, theDockerfilecontained these two lines: