- 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
```
* Fix zone detection for cross-zone cnames
CNAMEs cannot co-exist with SOA records so responses with
a CNAME should be skipped.
The `cross-zone-example.assets.sh.` is currently hosted by
me (@fd) and will continue to exist for as long as the assets.sh
domain exists. (The assets.sh domain is used as a CDN and is unlikely
to go away.)
See #330
* Extracted CNAME checking to simplify the FindZoneByFqdn control flow.
They will not get anymore an error message saying
"Could not find the start of authority".
Finding the zone cut of a FQDN now only rely on the presence
of a SOA record. Indeed, in the context of an eTLD the
authority will be the eTLD itself so you need to continue
to recurse until you get an answer instead of cutting the search
when you find the public suffix of a domain.
Fixes#434
* Move nonce retry from jws to http
The error raised by an "invalid nonce" response never appeared
inside jws.go, but instead it was handled at http.go, so it makes
sense to move the retry logic to that file. The previous code from
jws.go had no effect and did not solve issues related to invalid
nonces.
* Rename retry response variable name for clarity
If `links["next"] == ""` the early return does not send neither success, nor failure to outer code,
which leads to whole `getChallenges` method being stuck forever, cause it waits for either `resc` or `errc` to receive message.
* [reduce-locking] Prepare for change
* [reduce-locking] Do not lock on http request
* [reduce-locking] Move getNonce and getNonceFromResponse from jws struct cause they do not need access to it
* [reduce-locking] Extract nonceManager
* [reduce-locking] Add test that tries to show locking on http requests problem
* Close response body in error case
* Ensure the body of both responses is closed when polling for cert
Also make a new const of maxBodySize, and cap the number of polls
to a maximum of 1000.
* More correct placement for polling limit
* Move const to the top
* add issuer certificate to CertificateResource
Also write it out to the file system when running "lego run"
Removed caching of the issuer certificate inside the acme client, since
it didn't appear to be used.
* only append issuerCert to issuedCert in case of success
Effectively a no-op since issuerCert will be nil on error, but it seems
more correct to only do it if fetching the issuer succeeds.
Before read access to `nonces` field in jws structure (in `Nonces` method) was not synchronized and we were still able
to get `slice bounds out of range` panic when trying to "pop" value in `Nonces` method.
The race can be actually observed by running `Nonce` method multiple times in separate goroutines with th precondition is `len(jws.nonces) == 1`.
* Get better dns server defaults if available
if an /etc/resolv.conf file exists, then get the dns servers from there
* fix handwritten code...
* Make discovering system dns servers more testable
Allow specifying path to resolv.conf file to allow testing logic
* add tests
* Log which resolvers we are using
* move log statement for dns resolvers used
Introduces a new command line switch `--must-staple` to `run` and `renew`.
Using this switch will add the must staple TLS extension to the CSR generated by lego and thus also to the generated certificate.
This does not work with user specified CSRs!
Fixes#270
client.RenewCertificate now supports CSRs, and in fact prefers them,
when renewing certificates. In other words, if the certificate was
created via a CSR then using that will be attempted before re-generating
off a new private key.
Also adjusted the API of ObtainCertificateForCSR to be a little
more in line with the original ObtainCertificate function.
This commit also breaks requestCertificate() into two parts, the first of
which generates a CSR, the second of which became requestCertificateForCsr()
which does what the name implies.
Add 2 new functions to acme.Client for registration stuff:
* QueryRegistration: This performs a POST on the client
registration's URI and gets the updated registration info.
* DeleteRegistration: This deletes the registration as currently
configured in the client.
The latter, while a part of the IETF draft, may not be 100%
functional in LE yet, my tests showed that resources were still
available after deletion.
Added a slice of NS to be used when retrying queries. Also used with FindZoneByFqdn()
Adjusted 2 error messages given to better differentiate the returned error string
This patch adds code to only parse the HTTP response body as JSON if the
content-type header advertises the content as JSON. In my case, the
directory server was unavailable: it returned a 503 HTTP response code
with an HTML document, and the only thing lego reported was:
2016/04/04 19:12:56 Could not create client: get directory at 'https://acme-v01.api.letsencrypt.org/directory': invalid character '<' looking for beginning of value
This was caused by trying to parse the document body (HTML) as JSON,
without looking at the content-type header and returning the JSON parse
error.
- Reworked the code in dns_challenge.go to not assume nameserver is
port-less or defaults to 53. (messes up testing)
- Updated nameserver test to clear the fqdn2zone cache and return a dummy
SOA RR to make initial findZoneByFqdn call happy.
- Used publicsuffix library to determine if the "authorative" zone we found
is a public registry, in that case error out. (Also used by boulder btw)
- Removal of RFC2136_ZONE from help text
- Query nameserver directly to find zone we have to update
- During insert, make sure the new record is the ONLY challence.
(I had a few panics, hence 3 challences left. Not good.)
Prior to this commit, the checkDNSPropagation function was exiting
early if the TXT record could not be found on the recursive
nameserver, and thus the authoritative nameservers were not being
queried until after the record showed up on the recursive nameserver
causing a delay.
This commit changes that behaviour so that the authoritative
nameservers are queried on each execution of checkDNSPropagation when
possible.
This will prevent indefinitely-hanging requests in case some service or middle box is malfunctioning.
Fix vet errors and lint warnings
Add vet to CI check
Only get issuer certificate if it would be used
No need to make a GET request if the OCSP server is not specified in leaf certificate
Fix CI tests
Make tests verbose
The default AWS HTTP client retries three times with a deadline of 10 seconds in order to fetch metadata from EC2. Replaced the default HTTP client with one that does not retry and has a low timeout.
Add a new environment variable RFC2136_TSIG_ALGORITHM that accepts the
TSIG algorithm pseudo-domain name. Let it default to
"hmac-md5.sig-alg.reg.int." if unset.
* Gets a list of all authoritative nameservers by looking up the NS RRs for the root domain (zone apex)
* Verifies that the expected TXT record exists on all nameservers before sending off the challenge to ACME server
If TCP connection reuse (KeepAlives) are left on then, in a sequence
of challenges arising from a multiple-domain certficate, challenges
after the 1st can fail due to reusing the now defunct tcp connection
used in the first challenge. This has been observed when using the Go
standard library reverse proxy to forward the challenges to Lego.
Fixes#107
