Timeout problems using dns-01 challenge

Help
1

1. Caddy version (caddy version):

v2.0.0 h1:pQSaIJGFluFvu8KDGDODV8u4/QRED/OPyIR+MWYYse8=

2. How I run Caddy:

a. System environment:

Debian 10 (buster)
systemd 241

b. Command:

systemctl start caddy.service

c. Service/unit/compose file:

/etc/systemd/system/caddy.service

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

[Service]
User=caddy
Group=caddy
EnvironmentFile=/var/lib/caddy/environment.txt
ExecStart=/usr/local/bin/caddy run --environ --config /etc/caddy/Caddyfile
ExecReload=/usr/local/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:

{
  # debugging
  acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
}

sub.example.com {
  tls {
    dns lego_deprecated netcup
  }
  reverse_proxy 10.0.0.11:80
}

3. The problem I’m having:

After reading your beginner friendly documentation I tried getting Caddy to work in my local network. The domain in use is registered at Netcup where the dns-01 challenge can be used for getting a TLS certificate. So Caddy was built using

xcaddy build --with github.com/caddy-dns/lego-deprecated

The necessary environment varibales are set in /var/lib/caddy/environment.txt:

NETCUP_POLLING_INTERVAL=30
NETCUP_PROPAGATION_TIMEOUT=1800
NETCUP_API_KEY="ALONGAPIKEY"
NETCUP_API_PASSWORD="ALONGAPIPASSWORD"
NETCUP_CUSTOMER_NUMBER="ANUMERICCUSTOMERNUMBER"

Sadly, in first tests a certificate could not be created. I changed to Let’s Encrypt’s staging environment and checked what happend at a Caddy service start using

journalctl -f -u caddy

The problem seems to be that there is too little waiting time when requesting the certificate because my settings for POLLING_INTERVAL and PROPAGATION_TIMEOUT are ignored.

4. Error messages and/or full log output:

[INFO] Wait for propagation [timeout: 1m0s, interval: 2s]

5. What I already tried:

It seems that the waiting time necessary varies in each run. I have been able to generate a certificate in two or three tries using the default settings for waiting time and the staging environment. Therefore I am sure that my setup of supplying environment data from a file to systemd startup is working as NETCUP_API_KEY, NETCUP_API_PASSWORD and NETCUP_CUSTOMER_NUMBER are used successfully. But my values for POLLING_INTERVAL and PROPAGATION_TIMEOUT from the very same file are ignored.

I have already tried

  • moving the ignored lines around in environment.txt (top, bottom)
  • variants of describing the time: 30, 30s, 30S
  • using quotes around the value
  • understanding “PropagationTimeout: env.GetOrDefaultSecond(EnvPropagationTimeout, 120*time.Second)”, but sadly I do not speak any Go

What could I be doing wrong?

6. Links to relevant resources:

2

Hmm, not sure, you might want to open an issue with Lego, which implements that functionality. This is all part of a deprecated suite if plugins that we no longer develop or maintain.

3

To check if the problem can be reproduced in plain Lego I made a basic setup.

Lego binary in use:

lego version 3.7.0 linux/amd64

/etc/systemd/system/legotest.service:

[Unit]
Description=Lego test

[Service]
User=caddy
Group=caddy
EnvironmentFile=/var/lib/caddy/environment.txt
ExecStart=/var/lib/caddy/legotest/lego
  --server=https://acme-staging-v02.api.letsencrypt.org/directory
  --email="user@example.com"
  --domains="sub.example.com"
  --dns="netcup"
  --path="/var/lib/caddy/legotest/certs/"
  --accept-tos
  run

(ExecStart reformatted for easier reading)

As I watched progress with

journalctl -f

a line appeared:

[INFO] Wait for propagation [timeout: 30m0s, interval: 30s]

It took more than 7 minutes this time but certificate generation was successful and my values for POLLING_INTERVAL and PROPAGATION_TIMEOUT were accepted and used.

I fully understand that you do not want to waste energy on a deprecated suite that you no longer develop or maintain. Just did this test to try what it could be. To me it looks like the two environment variables are lost somewhere and not passed to Lego.
I think to understand from lego-deprecated/go.mod at master · caddy-dns/lego-deprecated · GitHub that lego-deprecated is using Lego v3.6.0. Trying with that version showed the same behaviour as 3.7.0.

Thank you for your comment that inspired me to do the tests in Lego.

4

Ah, yeah, that could be why.

The reason we made new DNS provider plugins is because of trouble with environment variable configuration. More info:

So I made libdns (introduced here: Introducing libdns: A collaborative effort for unified DNS provider APIs) and there are instructions for implementing providers here: Writing new DNS provider modules for Caddy

5

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