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
```
This adds a function NewDNSProviderProgram() to the exec provider that allows to set the program to run directly instead of via the environment variable. This is similar to how other providers allow to set their credentials.
This commit fixes the naming inconsistency of Google Cloud DNS being
named `googlecloud` in the source and `gcloud` in the user interface.
Furthermore, improving my previous commit, I realized that the project ID
is stored in the service account file. We can save one environment variable
when using service account file (e.g. in automation applications).
* Adding output of which envvars are missing in Cloudflare dns provider
* go fmt, duh
* Fixing & adding test(s)
* Adding azure missing env vars checking
* Fixing test
* Doh, fixing up expected output
* Add dns provider duckdns see http://www.duckdns.org/spec.jsp for more info
* Add DNS challenge provider 'exec' (#508)
As discussed in #505, this commits adds a very simple DNS provider which
calls out to an external program which must then add or remove the DNS
record.
* Update duckdns to support caddy, and cleanup some comments
As discussed in #505, this commits adds a very simple DNS provider which
calls out to an external program which must then add or remove the DNS
record.
If Dyn responds with a 3xx or 4xx status code, information describing exactly
what went wrong is generally included in the body of the response (as part of
the typical Dyn JSON response). On the other hand, if Dyn responds with a 5xx
status code, we very likely have extremely limited information.
This commit modifies the reporting to display the explanatory messages included
in the body of the Dyn response for 3xx and 4xx status codes. The intent is to
make it much easier to determine what might be going wrong (when something is
going wrong).
The `acme.NewClient` function's `caDirURL` argument is expected to be
the full path to the ACME server's directory endpoint. In the README
example of using Lego programmatically against a Boulder instance only
the hostname & port are provided but not the directory path:
`"http://192.168.99.100:4000"`
This produces an error like:
```
2018/01/15 14:34:06 get directory at 'http://192.168.99.100:4000': invalid
character '<' looking for beginning of value
```
When used verbatim with a Boulder container since the `/directory` is
missing and "What is an ACME server" HTML index page is returned.
This commit updates the example to use:
`"http://192.168.99.100:4000/directory"`
Which allows the example code to work with Boulder as-intended.
* 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
