Cannot get certificates for subdomains

[GabrielZirk]

Hello module author,

obtaining certificates for my https://domainname.dev works perfectly fine, but I am not able to get them for any subdomain, including https://www.domainname.dev.

This is my Caddyfile:

{
    debug
}

domainname.dev, www.domainname.dev {
    root * /usr/share/caddy/public
    file_server

    # Redirect HTTP to HTTPS
    @http {
        protocol http
    }
    redir @http https://{host}{uri} 301

    tls {
        dns inwx {
            username ${INWX_USERNAME}
            password ${INWX_PASSWORD}
        }
    }
}

home.domainname.dev {
    # root * /usr/share/caddy/public
    # file_server

    respond "Hello" 200

    # Redirect HTTP to HTTPS
    @http {
        protocol http
    }
    redir @http https://{host}{uri} 301

    tls {
        dns inwx {
            username ${INWX_USERNAME}
            password ${INWX_PASSWORD}
        }
    }
}

This is my Dockerfile:

FROM caddy:builder AS builder

RUN xcaddy build \
    --with github.com/caddy-dns/inwx

FROM caddy:latest

COPY --from=builder /usr/bin/caddy /usr/bin/caddy

And my compose.yml to start my docker docktainer:

services:
  caddy:
    image: caddy-inwx
    restart: unless-stopped
    container_name: caddy
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - ./public:/usr/share/caddy/public
      - caddy_data:/data
      - caddy_config:/config
    environment:
      - INWX_USERNAME=${CADDY_INWX_USERNAME}
      - INWX_PASSWORD=${CADDY_INWX_PASSWORD}

volumes:
  caddy_data:
  caddy_config:

Of course there are A records for www.domainname.dev and home.domainname.dev!

Since I get the certificate for https://domainname.dev, I dont think there is an issue with incorrect credentials and the are properly served by my .env file.

However, there seems to be something wrong with the authentication, see caddy log output below:

caddy  | {"level":"error","ts":1729447364.3561056,"logger":"tls.obtain","msg":"will retry","error":"[www.domainname.dev] Obtain: [www.domainname.dev] solving challenges: presenting for challenge: adding temporary record for zone \"domainname.dev.\": (2200) Authentication error (order=https://acme-v02.api.letsencrypt.org/acme/order/2009592577/315493xxx) (ca=https://acme-v02.api.letsencrypt.org/directory)","attempt":1,"retrying_in":60,"elapsed":5.068295076,"max_duration":2592000}

Any help is appreciated, thanks in advance!
Best

[david-askari]

Ran into this issue today and fixed it by explicity setting endpoint_url as stated in their docs:

{
	acme_dns inwx {
		username ${INWX_USERNAME}
		password ${INWX_PASSWORD}
		shared_secret 
		endpoint_url https://api.domrobot.com/jsonrpc/
	}
}

The README says:

If you don’t provide an endpoint_url the URL of the production environment (https://ote.domrobot.com/jsonrpc/) is used by default. If you want to use the test environment, set endpoint_url to https://api.ote.domrobot.com/jsonrpc/.

I assume this plugin uses an old url (https://ote.domrobot.com/jsonrpc/), although libdns/inwx uses the current one.

@ihmels you seem do manage both repos, do you have an idea?

[ihmels]

I assume this plugin uses an old url (https://ote.domrobot.com/jsonrpc/), although libdns/inwx uses the current one.

@david-askari This plugin uses the URL that is stored in libdns/inwx if endpoint_url is not set. The readme incorrectly stated that https://ote.domrobot.com/jsonrpc/ is used. However, the correct URL https://api.domrobot.com/jsonrpc/ is actually used.

@GabrielZirk Do you have two-factor authentication enabled in your INWX account?

[GabrielZirk]

Hello,

No I did not use 2FA and ended up not using the automatic certificate management. However, thank you for your help. Will try it ASAP.

Best
Gabriel

[david-askari]

@ihmels you were right, no need to explicitly state endpoint_url. I had an issue with my ISP's DNS server being too slow and thought it would be related to endpoint_url. Thanks for the quick response!

@GabrielZirk After some back and forth, I got subdomains and wildcard subdomains working for me:

{
	# debug
	# acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
	email [email protected]
}

domain.tld {
	tls {
		resolvers 1.1.1.1
		dns inwx {
			username <username>
			password <password>
		}
	}

	# Service #1
        reverse_proxy localhost:1111
}

*.domain.tld {
	tls {
		resolvers 1.1.1.1
		dns inwx {
			username <username>
			password <password>
		}
	}

	# Service #2
	@service host service.domain.tld
	handle @service {
		reverse_proxy localhost:2222
	}

	# Fallback for otherwise unhandled domains
	handle {
		abort
	}
}

sub.domain.tld {
	tls {
		resolvers 1.1.1.1
		dns inwx {
			username <username>
			password <password>
		}
	}
        # Service #3
	reverse_proxy localhost:3333
}

*.sub.domain.tld {
	tls {
		resolvers 1.1.1.1
		dns inwx {
			username <username>
			password <password>
		}
	}

	# Service #4
	@service host service.sub.domain.tld
	handle @service {
		reverse_proxy localhost:4444
	}

	# Fallback for otherwise unhandled domains
	handle {
		abort
	}
}

I'm running Caddy as a systemd service, also no 2FA and use the ACME DNS challenge.

Due to the DNS issue above, I'm explicitly setting 1.1.1.1 as DNS server. I am aware of the global acme_dns option, yet at one point Caddy tried it via the other two ACME challenges, so I explicitly said to use the DNS challenge for each certificiate.