* 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.
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.
* 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.
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.
* new ChallengeProvider with Present and CleanUp methods
* new Challenge type describing `http-01`, `tls-sni-01`, `dns-01`
* new client.SetChallengeProvider to support custom implementations
