- 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
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.
Fully backwards compatible in terms of credential mechanisms
(environment variables, shared credentials file, EC2 metadata). If a
custom AWS IAM policy is in use it needs to be updated with permissions
for the route53:ListHostedZonesByName action.
This commit adds support for Dyn, specifically Dyn Managed DNS. Makes
use of the Dyn REST API [1] and requires 3 environment variables for
credentails:
DYN_CUSTOMER_NAME
DYN_USER_NAME
DYN_PASSWORD
The Dyn DNS API requires a session to be established first using the
credentials above, After creating a session an api token is used for
subsequent requests.
The unit test performs a "live test" and currently requires a valid Dyn
account and domain.
[1] https://help.dyn.com/rest/
