I, along with many others, am super excited about Let's Encrypt supporting wildcard certs in 2018. According to their latest blog they should have a test endpoint up in early January.

I really like this library, as it has saved me from having to deal with acme directly at all. Is acme v2 and wildcard support on your radar at all? I am not even sure what the major differences are, or what is involved in upgrading. Will a single library be able to handle both, or will a separate package be needed?

If I had all my dreams come true I would love for lego to let me get wildcard certs asap, but I know this is may be a considerable undertaking. Thanks for everything.

Add DNS provider for Yandex.

https://tech.yandex.com/domain/doc/concepts/api-dns-docpage/

Closes #278

ping @Akkarine, could you do:

rm -rf .lego

./lego -m [email protected] --dns yandex -d *.yourdomain.com -d yourdomain.com -s https://acme-staging-v02.api.letsencrypt.org/directory run

Note the wildcard domain is important.

If you have problems building lego, do not hesitate to ask me.

Hi,

I'm trying to use a DNS challenge with CloudFlare, but am getting: Time limit exceeded. Last error: NS laura.ns.cloudflare.com. did not return the expected TXT record

However, if I use dig to get the relevant TXT entry, it works (in real life I'm using the correct domain, not myhost.mydomain.com):

> dig _acme-challenge.myhost.mydomain.com txt @laura.ns.cloudflare.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> _acme-challenge.myhost.mydomain.com txt @laura.ns.cloudflare.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27257
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_acme-challenge.myhost.mydomain.com. IN	TXT

;; ANSWER SECTION:
_acme-challenge.myhost.mydomain.com. 120 IN	TXT	"<redacted>"

;; Query time: 368 msec
;; SERVER: 173.245.58.183#53(173.245.58.183)
;; WHEN: Thu Sep 21 13:49:17 IDT 2017
;; MSG SIZE  rcvd: 116

My Caddy version:

> caddy -version
Caddy 0.10.9

What am I missing? Thanks!

There was what I perceived as a problem with my Gandi ChallengeProvider in #133. Because of Gandi's long DNS record propagation time (in my tests, up to 25 minutes), I had to alter the timeout the acme package used when checking for record propagation. However, this affected all the DNS providers, the remainder of which just require the existing 30 second timeout. Forcing them all to have a 40 minute timeout for the sake of Gandi seemed... wrong?

This PR adds a new ChallengeProviderTimeout type to the acme package which allows for implementing DNS providers that require an unsually long timeout when checking for record propagation. In fact, although it would only be necessary for DNS providers like Gandi at present, it need not be solely for DNS providers. There could be in the future some yet not-invented challenge type, for which the same problem occured.

The Gandi provider in #133 has been altered to use this new interface, so all the remaining DNS providers will now use the 30 second timeout again as normal.

Thoughts?

EDIT: This PR now sits on top of #144, due to new WaitFor semantics.

This pr adds support for autodns based on https://help.internetx.com/display/APIJSONEN

Closes #501

Checklist

• [x] add a description to your PR
• [x] be able to maintain this provider
• [x] have a homogeneous design with the other providers
• [x] add tests (units)
• [x] add tests ("live") (i guess? Please correct me if I'm wrong)
• [x] add the provider to the readme.md
• [x] add a provider descriptor
• [x] generate CLI help and documentation
• [x] pass the linter (golangci-lint must be installed)
• [x] do go mod tidy
• [x] be able to do: (and put the output of this command to a comment in your PR)

rm -rf .lego

./lego -m [email protected] --dns YOUR_PROVIDER_NAME -d *.example.com -d example.com -s https://acme-staging-v02.api.letsencrypt.org/directory run

Note the wildcard domain is important.

lego --email="[email protected]" \
       --accept-tos \
       --csr="/path/to/csr.csr" \
       --path="/path/to/letsencrypt/data/" \
       --server="https://acme-v02.api.letsencrypt.org/directory" \
       --dns="gcloud" \
       --dns-resolvers="8.8.4.4:53" \
       --dns-resolvers="8.8.8.8:53" \
       --dns-resolvers="1.0.0.1:53" \
       --dns-resolvers="1.1.1.1:53" \
       --dns-timeout=5 \
       run;

2018/09/20 21:42:34 [INFO] [domain.net, *.domain.net, *.staging.domain.net, domain.info, *.domain.info, *.staging.domain.info] acme: Obtaining bundled SAN certificate given a CSR
2018/09/20 21:42:35 [INFO] [*.domain.info] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz/xxxx
2018/09/20 21:42:35 [INFO] [*.domain.net] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz/xxxx
2018/09/20 21:42:35 [INFO] [*.staging.domain.info] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz/xxxx
2018/09/20 21:42:35 [INFO] [*.staging.domain.net] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz/xxxx
2018/09/20 21:42:35 [INFO] [domain.info] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz/xxxx
2018/09/20 21:42:35 [INFO] [domain.net] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz/xxxx
2018/09/20 21:42:35 [INFO] [domain.info] acme: Could not find solver for: tls-alpn-01
2018/09/20 21:42:35 [INFO] [domain.net] acme: Could not find solver for: tls-alpn-01
2018/09/20 21:42:35 [INFO] [domain.info] acme: Preparing to solve DNS-01
2018/09/20 21:42:38 [INFO] [domain.net] acme: Preparing to solve DNS-01
2018/09/20 21:42:41 [INFO] [staging.domain.info] acme: Preparing to solve DNS-01
2018/09/20 21:42:44 [INFO] [staging.domain.net] acme: Preparing to solve DNS-01
2018/09/20 21:42:47 [INFO] [domain.info] acme: Preparing to solve DNS-01
2018/09/20 21:42:49 [INFO] [domain.net] acme: Preparing to solve DNS-01
2018/09/20 21:42:51 [INFO] [domain.info] acme: Trying to solve DNS-01
2018/09/20 21:42:51 [INFO] [domain.info] Checking DNS record propagation using [8.8.4.4:53 8.8.8.8:53 1.0.0.1:53 1.1.1.1:53]
2018/09/20 21:45:54 [INFO] [domain.net] acme: Trying to solve DNS-01
2018/09/20 21:45:54 [INFO] [domain.net] Checking DNS record propagation using [8.8.4.4:53 8.8.8.8:53 1.0.0.1:53 1.1.1.1:53]
2018/09/20 21:48:55 [INFO] [staging.domain.info] acme: Trying to solve DNS-01
2018/09/20 21:48:55 [INFO] [staging.domain.info] Checking DNS record propagation using [8.8.4.4:53 8.8.8.8:53 1.0.0.1:53 1.1.1.1:53]
2018/09/20 21:49:01 [INFO] [staging.domain.info] The server validated our request
2018/09/20 21:49:01 [INFO] [staging.domain.net] acme: Trying to solve DNS-01
2018/09/20 21:49:01 [INFO] [staging.domain.net] Checking DNS record propagation using [8.8.4.4:53 8.8.8.8:53 1.0.0.1:53 1.1.1.1:53]
2018/09/20 21:49:07 [INFO] [staging.domain.net] The server validated our request
2018/09/20 21:49:09 [WARN] Error cleaning up staging.domain.info: googlecloud: <nil>
2018/09/20 21:49:11 [WARN] Error cleaning up staging.domain.net: googlecloud: <nil>
2018/09/20 21:49:11 Could not obtain certificates
	acme: Error -> One or more domains had a problem:
[domain.info] Time limit exceeded. Last error: NS ns-cloud-c1.googledomains.com. did not return the expected TXT record
[domain.net] Time limit exceeded. Last error: NS ns-cloud-c1.googledomains.com. did not return the expected TXT record

weird thing is that it validates the *.staging.domain.<tld> domains...

have also tried without --dns-resolvers

Hi there!

I upgraded to v0.1 and now I am getting this error:

2015/12/04 10:10:14 Could not create client:decode directory: invalid character '<' looking for beginning of value

I am using the following parameters:

lego --domains=mydomain.de -B 4096 --email="[email protected]" -s "https://acme-v01.api.letsencrypt.org/" --path=/var/container/nginx/newcert/ --port 9999 run

Did something change? I tried using the existing keys and creating new ones, the error is still the same.

Thanks!

Most of the days it works fine, but today the configured 30 seconds timeout isn't sufficient. I get the following error over and over:

Time limit exceeded. Last error: NS nora.ns.cloudflare.com. did not return the expected TXT record

Either bumping it up to a much higher value - it does multiple checks within that timeout, right? - or making it configurable by command line parameter would help to cater for this incidental high propagation times.

When running lego for multiple domains it will set the dns TXT record and check propagation in sequence. This can take a long time if the number of domains is large. Would it be possible to parallelize this?

alpine 3.4 no longer works with error

package context: unrecognized import path "context" (import path does not begin with hostname)

alpine 3.5 with no changes did not work with error

# runtime/cgo
/tmp/go-build671992352/runtime/cgo/_obj/_cgo_export.c:2:20: fatal error: stdlib.h: No such file or directory
 #include <stdlib.h>
                    ^
compilation terminated.

alpine 3.6 with no changes did not work with error:

# github.com/xenolf/lego
/usr/lib/go/pkg/tool/linux_amd64/link: running gcc failed: exit status 1
/usr/lib/gcc/x86_64-alpine-linux-musl/6.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: cannot find Scrt1.o: No such file or directory
/usr/lib/gcc/x86_64-alpine-linux-musl/6.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: cannot find crti.o: No such file or directory
/usr/lib/gcc/x86_64-alpine-linux-musl/6.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: cannot find -lpthread
/usr/lib/gcc/x86_64-alpine-linux-musl/6.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: cannot find -lssp_nonshared
collect2: error: ld returned 1 exit status

Thanks for lego, it's awesome!

When I use the DNS challenge to request a cert for a FQDN that's a CNAME, I get the following. Assume iamacname.example.com is a CNAME for www.example.com

2016/02/01 13:06:25 [INFO][iamacname.example.com] acme: Obtaining bundled SAN certificate

2016/02/01 13:06:25 [INFO][iamacname.example.com] acme: Trying to solve DNS-01
2016/02/01 13:06:25 [INFO] acme: Please create the following TXT record in your DNS zone:
2016/02/01 13:06:25 [INFO] acme: _acme-challenge.iamacname.example.com. 120 IN TXT "U4BJAr7Mg1x2BSdYWeCDLvWSYPkj14XR3uohxan1_RU"
2016/02/01 13:06:25 [INFO] acme: Press 'Enter' when you are done
2016/02/01 13:06:25 [INFO] acme: You can now remove this TXT record from your DNS zone:
2016/02/01 13:06:25 [INFO] acme: _acme-challenge.iamacname.example.com. 120 IN TXT "..."
panic: interface conversion: dns.RR is *dns.CNAME, not *dns.SOA

goroutine 1 [running]:
github.com/xenolf/lego/acme.checkDNS(0x7ffcb3f28514, 0x13, 0xc820424690, 0x24, 0xc820424690)
        /home/happy/x/src/github.com/xenolf/lego/acme/dns_challenge.go:82 +0x355
github.com/xenolf/lego/acme.(*dnsChallenge).Solve(0xc82011c240, 0x0, 0x0, 0xc820432180, 0x6, 0xc820432190, 0x7, 0xc8203500e0, 0x68, 0xc8204240c0, ...)
        /home/happy/x/src/github.com/xenolf/lego/acme/dns_challenge.go:65 +0x5a6
github.com/xenolf/lego/acme.(*Client).solveChallenges(0xc820126080, 0xc82000a300, 0x1, 0x1, 0xc82000a300)
        /home/happy/x/src/github.com/xenolf/lego/acme/client.go:369 +0x250
github.com/xenolf/lego/acme.(*Client).ObtainCertificate(0xc820126080, 0xc820013990, 0x1, 0x1, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
        /home/happy/x/src/github.com/xenolf/lego/acme/client.go:227 +0x25b
main.run(0xc8200dc240)
        /home/happy/x/src/github.com/xenolf/lego/cli_handlers.go:174 +0x173f
github.com/codegangsta/cli.Command.Run(0x9412b0, 0x3, 0x0, 0x0, 0x0, 0x0, 0x0, 0x9dbd80, 0x3a, 0x0, ...)
        /home/happy/x/src/github.com/codegangsta/cli/command.go:163 +0x131d
github.com/codegangsta/cli.(*App).Run(0xc82008fe60, 0xc82000a0c0, 0xc, 0xc, 0x0, 0x0)
        /home/happy/x/src/github.com/codegangsta/cli/app.go:179 +0x1169
main.main()
        /home/happy/x/src/github.com/xenolf/lego/cli.go:126 +0x106f

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
        /usr/lib/go/src/runtime/asm_amd64.s:1696 +0x1

goroutine 9 [IO wait]:
net.runtime_pollWait(0x7f8f324ee000, 0x72, 0xc820012270)
        /usr/lib/go/src/runtime/netpoll.go:157 +0x60
net.(*pollDesc).Wait(0xc820128060, 0x72, 0x0, 0x0)
        /usr/lib/go/src/net/fd_poll_runtime.go:73 +0x3a
net.(*pollDesc).WaitRead(0xc820128060, 0x0, 0x0)
        /usr/lib/go/src/net/fd_poll_runtime.go:78 +0x36
net.(*netFD).Read(0xc820128000, 0xc82031c000, 0x800, 0x800, 0x0, 0x7f8f34652050, 0xc820012270)
        /usr/lib/go/src/net/fd_unix.go:232 +0x23a
net.(*conn).Read(0xc820030080, 0xc82031c000, 0x800, 0x800, 0x0, 0x0, 0x0)
        /usr/lib/go/src/net/net.go:172 +0xe4
crypto/tls.(*block).readFromUntil(0xc8201123f0, 0x7f8f34656b50, 0xc820030080, 0x5, 0x0, 0x0)
        /usr/lib/go/src/crypto/tls/conn.go:455 +0xcc
crypto/tls.(*Conn).readRecord(0xc8200d4840, 0xa14117, 0x0, 0x0)
        /usr/lib/go/src/crypto/tls/conn.go:540 +0x2d1
crypto/tls.(*Conn).Read(0xc8200d4840, 0xc820188000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
        /usr/lib/go/src/crypto/tls/conn.go:901 +0x167
net/http.noteEOFReader.Read(0x7f8f34663308, 0xc8200d4840, 0xc8200e67e8, 0xc820188000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
        /usr/lib/go/src/net/http/transport.go:1370 +0x67
net/http.(*noteEOFReader).Read(0xc82044a700, 0xc820188000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
        <autogenerated>:126 +0xd0
bufio.(*Reader).fill(0xc8203ecfc0)
        /usr/lib/go/src/bufio/bufio.go:97 +0x1e9
bufio.(*Reader).Peek(0xc8203ecfc0, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0)
        /usr/lib/go/src/bufio/bufio.go:132 +0xcc
net/http.(*persistConn).readLoop(0xc8200e6790)
        /usr/lib/go/src/net/http/transport.go:876 +0xf7
created by net/http.(*Transport).dialConn
        /usr/lib/go/src/net/http/transport.go:685 +0xc78

goroutine 10 [select]:
net/http.(*persistConn).writeLoop(0xc8200e6790)
        /usr/lib/go/src/net/http/transport.go:1009 +0x40c
created by net/http.(*Transport).dialConn
        /usr/lib/go/src/net/http/transport.go:686 +0xc9d

Fixes #1795

The comparison in findZone does not work because authZone has a dot at the end and the entries in zones do not contain a dot.

If the dot is removed with UnFqdn it works for me.

Welcome

• [X] Yes, I'm using a binary release within 2 latest releases.
• [X] Yes, I've searched similar issues on GitHub and didn't find any.
• [X] Yes, I've included all information below (version, config, etc).

What did you expect to see?

issue of a certificate

What did you see instead?

2023/01/02 00:11:37 Could not obtain certificates:
  error: one or more domains had a problem:
[example.net] [example.net] acme: error presenting token: luadns: no matching zone found for domain example.net

How do you use lego?

Binary

Reproduction steps

lego --accept-tos --path . -d example.net --email [email protected] --key-type ec256 --dns luadns run

Version of lego

lego version a824cab316e0bc31fe9049e130c84f97cdfcb697 linux/amd64
lego version 4.9.0 linux/amd64

Logs

# paste output here
2023/01/02 00:11:36 [INFO] [example.net] acme: use dns-01 solver
2023/01/02 00:11:36 [INFO] [example.net] acme: Preparing to solve DNS-01
2023/01/02 00:11:37 [INFO] [example.net] acme: Cleaning DNS-01 challenge
2023/01/02 00:11:37 [WARN] [example.net] acme: cleaning up failed: luadns: unknown record ID for '_acme-challenge.example.net.'
2023/01/02 00:11:37 [INFO] Deactivating auth: https://acme-v02.api.letsencrypt.org/acme/authz-v3/111111111111111
2023/01/02 00:11:37 Could not obtain certificates:
  error: one or more domains had a problem:
[example.net] [example.net] acme: error presenting token: luadns: no matching zone found for domain example.net

Go environment (if applicable)

$ go version && go env
# paste output here

Welcome

• [X] Yes, I've searched similar issues on GitHub and didn't find any.

How do you use lego?

Binary

Detailed Description

Currently there's no logs when server returns RetryAfter. It looks like the whole program stuck, which confuse user. Please add logs to indicate server returns retry. https://github.com/go-acme/lego/blob/a824cab316e0bc31fe9049e130c84f97cdfcb697/challenge/resolver/solver_manager.go#L78-L131

Welcome

• [X] Yes, I've searched similar issues on GitHub and didn't find any.
• [X] Yes, the DNS provider exposes a public API.
• [X] Yes, I know that the lego maintainers don't have an account in all DNS providers in the world.
• [ ] Yes, I'm able to create a pull request and be able to maintain the implementation.
• [X] Yes, I'm able to test an implementation if someone creates a pull request to add the support of this DNS provider.

How do you use lego?

Docker image

Link to the DNS provider

https://timeweb.cloud/

Link to the API documentation

https://timeweb.cloud/docs/public-api/api-managing-domains

Additional Notes

No response

This extends the documentation for the --dns.resolvers flag as suggested in #1777.

The commits are currently based off of PR #1785, so depending on whether that gets merged, I'll rebase this PR accordingly.

@oseiberts11: Would you like to proof-read the new section? You can find a preview here: https://mm.dmke.org/lego-b649657b/usage/cli/options/#dns-resolvers-and-challenge-verification

Description

To prevent bit rot, this adds a bit of go generate code to build the lego --help output on the CLI options page directly from the *urfave/cli.App.

Technically, internal/cli_help/main.go instantiates the CLI app similar to the way cmd/lego/main.go does it, but omits some details (like the version number or the CWD prefix to --path). It then simulates a few help commands (lego help, etc.) and dumps the results into docs/data/zz_cli_help.toml, from where Hugo embeds it into the Options.md via a new shortcode ("{{< clihelp >}}").

(I don't really like the shortcode detour, but Markdown content files are not allowed to access variables directly.)

The initial go generate ./... call (e.g. from make generate-dns) might now take a moment longer, because the initialization of the CLI app requires a few more CPU cycles.

Other changes

• I've tried to reduce the line length of the *cli.Flag definitions (in cmd/cmd_*.go) to a reasonable limit. Feel free to omit 3249cd7f entirely if you feel this is a pointless endeavour :)
• In order to capture the output of lego dnshelp, a small modification of displayDNSHelp() (generated by internal/dnsdocs) was needed: It now accepts an io.Writer.
• make validate-docs now suppresses the output of the git diff --exit-code conditional. I found its output confusing.

Preview

https://mm.dmke.org/lego/usage/cli/options/ (manually updated)