- Packages
- Isolate code used by the CLI into the package `cmd`
- (experimental) Add e2e tests for HTTP01, TLS-ALPN-01 and DNS-01, use [Pebble](https://github.com/letsencrypt/pebble) and [challtestsrv](https://github.com/letsencrypt/boulder/tree/master/test/challtestsrv)
- Support non-ascii domain name (punnycode)
- Check all challenges in a predictable order
- No more global exported variables
- Archive revoked certificates
- Fixes revocation for subdomains and non-ascii domains
- Disable pending authorizations
- use pointer for RemoteError/ProblemDetails
- Poll authz URL instead of challenge URL
- The ability for a DNS provider to solve the challenge sequentially
- Check all nameservers in a predictable order
- Option to disable the complete propagation Requirement
- CLI, support for renew with CSR
- CLI, add SAN on renew
- Add command to list certificates.
- Logs every iteration of waiting for the propagation
- update DNSimple client
- update github.com/miekg/dns
Also, remove "Go-http-client/1.1". In practice this added detail doesn't
wind up being useful in diagnosing problems, particularly since it can
be deduced from the xenolf-acme version.
* add UA comments.
The latest versions of draft-ietf-acme-tls-alpn specify a different
idPeAcmeIdentifierV1 than LEGO was previously using. The old value had
a conflict with an existing assignment.
This commit updates the idPeAcmeIdentifierV1 value to match draft-05 and
updates any references to the draft RFC to use the latest draft number.
* Client: Do not send a JWS body when POSTing challenges.
In legacy ACME there was a requirement to send a JWS body that contained
a key authorization as part of all challenge initiation POSTs. Since
both the client and server can reconstitute the key authorization there
is no need to send it and modern ACME expects challenges to be initiated
with a JWS carrying the trivial empty JSON object (`{}`). Some ACME
servers (e.g. Pebble in `-strict` mode) will reject all challenge POSTs
that have a legacy JWS body.
This commit updates the LEGO `acme/client.go`'s `validate` function to
send the correct JWS payload for challenge POSTs.
ACME draft Section 7.4 "Applying for Certificate Issuance"
https://tools.ietf.org/html/draft-ietf-acme-acme-12#section-7.4
says:
Clients SHOULD NOT make any assumptions about the sort order of
"identifiers" or "authorizations" elements in the returned order
object.
* refactor: create log.Infof and log.Warnf
* refactor: review DNS providers.
- use one `http.Client` by provider instead of one client by request
- use the same receiver name `d` for all `DNSProvider`
- use `http.MethodXXX`
* refactor: logger init.
This commit updates `acme/http.go` to allow customizing the
`*x509.CertPool` used by the `HTTPClient` by specifying the filepath of
a custom CA certificate via the `CA_CERTIFICATE` environment variable.
This allows developers to easily trust a non-standard CA when
interacting with an ACME test server (e.g. Pebble):
```
CA_CERTIFICATE=~/go/src/github.com/letsencrypt/pebble/test/certs/pebble.minica.pem \
lego \
--server https://localhost:14000/dir \
--email foo@bar.com \
-d example.com \
run
```
