* Initial implementation of ZeroSSL API issuer
Still needs CA support for CommonName-less certs
* Accommodate ZeroSSL CSR requirements; fix DNS prop check
* Fix README example
* Fix comment
* Changed solver DNS propagation check to only check authoritative nameservers directly if there are no explicitly given resolvers.
* Changed solver DNS propagation check to only succeed of any one of the checked nameservers has the required TXT entry
* feature: add optional !important suffix
if !important is added to any of the resolvers, then all are considered
exclusive and no other fallbacks will be added.
* fix: !important can be on it's own
* simplify recursiveNameservers
- use custom OR default nameservers
- add testing
* removed print line
* tests: fixed defaults when resolv.conf is found
When checking whether a new DNS TXT record is deployed, as part of the
DNS challenge procedure, checkAuthoritativeNss is called in a loop until
the requested TXT value is found in one of the records, or until a
timeout.
Previously, if there were other DNS TXT records for the same FQDN, the
call to checkAuthoritativeNss failed and the whole DNS challenge was
canceled. This means for example that if there was any previous
_acme-challenge TXT for the domain, the DNS challenge would always fail.
This fixes this issue by not returning an error, but instead returning
not ready, when there are other values returned by that DNS TXT record
request.
Co-authored-by: Matt Holt <mholt@users.noreply.github.com>
Wildcard domain names collide with the same subdomain for the ACME TXT
record as the non-wildcard parent domain (for example, example.com and
*.example.com both use _acme-challenge.example.com), so we need to solve
those challenges mutually exclusively.
One potential problem with this current implementation is that we don't
wait for the DNS record to un-propagate after it is deleted; I've found
that re-running it works fine, after waiting just a few seconds. I am
not sure how to generalize this logic in all cases though. It is likely
provider-dependent. (I was testing with Cloudflare.)
Should fix https://github.com/caddyserver/caddy/issues/3474
* Minor improvement to DNS request handling
Sometimes incoming udp traffic on port 53 is blocked to
prevent DDoS attacks. In those cases only TCP will work
for DNS request as the UDP request will time out. And as
a result the DNS challenge will fail, while the server is
trying to verify if the challenge was propageted through
the NS.
Now instead of returning immidently, if a timeout with UDP was
received, the request will be tried again using TCP.
* Formatting and comment
Co-authored-by: Georg Friedrich <g.friedrich@sonnenwagen.org>
Co-authored-by: Matthew Holt <mholt@users.noreply.github.com>
Before when we used lego as our ACME library, DNS solvers abounded in
the lego repository and they could be used directly. Our new acmez lib
is very lightweight, and "bring-your-own-solvers", let alone your own
DNS provider implementations.
DNS providers are implemented in libdns: https://github.com/libdns
This commit adds an implementation of acmez.Solver that solves the DNS
challenge using libdns providers.
Unlike the other solvers, this one is exported because it is not a
challenge type that is enabled by default, and there is more config
surface.
We borrowed some DNS utility functions and tests from the lego repo.
But this is a very lightweight implementation that has a much, much
simpler API and smaller footprint.
