Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
ZaxLofful opened this issue Apr 19, 2024 · 5 comments
Open

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

ZaxLofful opened this issue Apr 19, 2024 · 5 comments
Labels
bug needs triage Waiting for discussion / prioritization by team

Comments

@ZaxLofful
Copy link

ZaxLofful commented Apr 19, 2024 •
edited
Loading

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).
@ZaxLofful ZaxLofful added bug needs triage Waiting for discussion / prioritization by team labels Apr 19, 2024
@hslatman
Copy link
Member

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
Copy link
Author

@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
Copy link

adamhorsburgh commented Jun 11, 2024 •
edited
Loading

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
Copy link
Member

@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
Copy link

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug needs triage Waiting for discussion / prioritization by team
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@hslatman @adamhorsburgh @ZaxLofful