[Bug]: Doesn't recognize (*.subdomain.domain.com) as valid

[ZaxLofful]

Steps to Reproduce

1. Use Adguard "Filters->DNS Rewrites", add the wildcard A entry. (*.subdomain.domain.com)
2. Send a TLS cert request using the DNS name anything.subdomain.domain.com (traefik auto-request)

Note: As soon as that initial domain fully fails, it proceeds to get a cert for subdomain.domain.com just fine. Note2: Other machines (including the Smallstep docker host) can ping anything.subdomain.domain.com, including my browser. Thus it's not a failure of Adguard to publish the DNS wildcard.

Your Environment

• OS - Ubuntu Server 20.04
• step-ca Version - 0.25.2

Expected Behavior

Give out cert immediately and not get an error

Actual Behavior

Smallstep responds with "The server could not connect to validation target"

Additional Context

It takes about 5+ mins for Smallstep to finally give up and reject the Traefik request (during this time my Traefik container cannot proceed and the cert requests are stalled for other domains, making them inaccessible)

Contributing

Vote on this issue by adding a 👍 reaction. To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[hslatman]

Hey @ZaxLofful, can the machine/container running step-ca successfully connect to anything.subdomain.domain.com itself? Assuming you're running it in Docker (since you mentioned the Docker host), it's possible the container uses a different DNS server and thus doesn't get the right answer. With Docker it's possible to set the DNS server to use: https://docs.docker.com/network/#dns-services. You can also run step-ca with --resolver=<ip:port> to specify a DNS server.

[ZaxLofful]

@hslatman : I already give it the docker-compose DNS options. I will try running it with --resolver to see if that fixes the issue.

[adamhorsburgh]

I get the same "The server could not connect to validation target" error when trying to issue any cert, from any client. This is a fresh PKI and I cannot find much aside from the DNS recommendation. I have tried adding the --resolver option to no avail.

Any ideas?

[Mon Jun 10 19:51:12 EDT 2024] response='{"identifier":{"type":"dns","value":"client.domain.lcl"},"status":"pending","challenges":[{"type":"dns-01","status":"pending","token":"mOupne2uud4XvAJeLRnpBcRlVqj3m9yD","url":"https://intermediate.domain.lcl/acme/acme/challenge/IxQOd2KGsQ3UeiWX6s9SUk3mg6sIHygg/bezVG3SrNHqajPYVnjeWnAYIMBUxBelz"},{"type":"http-01","status":"pending","token":"mOupne2uud4XvAJeLRnpBcRlVqj3m9yD","url":"https://intermediate.domain.lcl/acme/acme/challenge/IxQOd2KGsQ3UeiWX6s9SUk3mg6sIHygg/OXcZCANI7YgKCMMHDqChbAmWEkJJMZmh","error":{"type":"urn:ietf:params:acme:error:connection","detail":"The server could not connect to validation target"}},{"type":"tls-alpn-01","status":"pending","token":"mOupne2uud4XvAJeLRnpBcRlVqj3m9yD","url":"https://intermediate.domain.lcl/acme/acme/challenge/IxQOd2KGsQ3UeiWX6s9SUk3mg6sIHygg/4LiX6khcPROxTwwN1vqNy0gt3jVQbt8o"}],"wildcard":false,"expires":"2024-06-11T23:54:31Z"}' [Mon Jun 10 19:51:12 EDT 2024] status='pending

[hslatman]

@adamhorsburgh does client.domain.lcl resolve correctly to the system the ACME client is running on from the viewpoint of the CA? Assuming you don't have the infrastructure setup to be able to use DNS challenges, is the ACME client system reachable from the CA viewpoint on port 80 or 443 (i.e. route available; not firewalled)?

[adamhorsburgh]

@hslatman thanks for the reply, got it figured out. The issue was with iptables. Opening ports 80/443 on the client allowed the server to complete its verifications in short order.