Error Getting validation data

1. Caddy version (caddy version):

v2.1.1 h1:X9k1+ehZPYYrSqBvf/ocUgdLSRIuiNiMo7CvyGUQKeA=

2. How I run Caddy:

I run it with the official docker image and default caddyfile with only the domain changed

a. System environment:

Raspberry Pi4, docker-compose

c. Service/unit/compose file:

version: '3'

services:
  app:
    image: caddy
    network_mode: host
    restart: always
    volumes:
      - ./data:/etc/caddy

d. My complete Caddyfile or JSON config:

# The Caddyfile is an easy way to configure your Caddy web server.
#
# Unless the file starts with a global options block, the first
# uncommented line is always the address of your site.
#
# To use your own domain name (with automatic HTTPS), first make
# sure your domain's A/AAAA DNS records are properly pointed to
# this machine's public IP, then replace the line below with your
# domain name.
#:80
test.alwin.kat-zentrale.de

# Set this path to your site's directory.
root * /usr/share/caddy

# Enable the static file server.
file_server

# Another common task is to set up a reverse proxy:
# reverse_proxy localhost:8080

# Or serve a PHP site through php-fpm:
# php_fastcgi localhost:9000

# Refer to the Caddy docs for more information:
# https://caddyserver.com/docs/caddyfile

3. The problem I’m having:

The certificate is not being created successfully, it says Error Getting validation data, see below

4. Error messages and/or full log output:

Digs:

5. What I already tried:

I digged the domain and the records seem correct, but its not working

Are you sure you have ports 80 and 443 forwarded to your Raspberry Pi? Caddy needs to be publicly accessible to complete the HTTP or ALPN ACME challenges.

I do see you’re using host networking here. Is there any particular reason for this? You could instead publish ports 80 and 443.

Also, please make sure to persist the /data volume when running Caddy in Docker, because that’s where all the certificates and keys are stored. If you don’t persist that volume, then you may hit rate limits. Especially so if you use restart: always which may cause Caddy to retry very quickly after each failure.

I highly recommend adding another volume - caddy_data:/data and change restart: always to restart: unless_stopped so you can have an opportunity to stop Caddy if it misbehaves without it just spinning back up immediately after.

1 Like

I found the problem:
Our ISP changed and now we have a CGNAT which I did not noticed since yet since I was just testing in my network. (Then I saw the IP in fritzbox and on ip checker sites are differerent) Is there any way to use a webserver anyway from the outside?

1 Like

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