* Creates SupportedChallengesAction
This fixes#3987 as the call to set_by_default can be removed entirely.
Additionally, logger.warning can be used rather than writing to stderr directly
because #3184 has been resolved and we're guaranteed to having logging setup.
* Move validator to SupportedChallengesAction
supported_challenges_validator was moved to SupportedChallengesAction so
argparse.ArgumentError can be easily used to provide nice error output. Tests
in standalone_test.py were also updated so the module still has 100% test
coverage.
* Better document ArgumentError usage
Implement an Authenticator which can fulfill a dns-01 challenge using
the CloudXNS DNS API. Applicable only for domains using CloudXNS DNS.
Testing Done:
* `tox -e py27`
* `tox -e lint`
* Manual testing:
* Used `certbot certonly --dns-cloudxns -d`, specifying a
credentials file as a command line argument. Verified that a
certificate was successfully obtained without user interaction.
* Used `certbot certonly --dns-cloudxns -d`, without specifying a
credentials file as a command line argument. Verified that the
user was prompted and that a certificate was successfully
obtained.
* Used `certbot certonly -d`. Verified that the user was prompted for
a credentials file after selecting cloudxns interactively and that
a certificate was successfully obtained.
* Used `certbot renew --force-renewal`. Verified that certificates
were renewed without user interaction.
* Negative testing:
* Path to non-existent credentials file.
* Credentials file with unsafe permissions (644).
* Domain name not registered to CloudXNS account.
* Add an account deactivate utility script.
This is handy if you created an account with a tool other than Certbot, and want
to deactivate the account.
* Move deactivate.py to tools.
* Add test for ConflictError.
* Fix lint error.
* Document how to set server.
* Move 'jwk' and 'alg' fields to protected header.
Previously, these were in the unprotected JWS header, which Boulder currently
allows. However, the next version of the spec doesn't allow anything in the
unprotected header. Moving these fields now allows server implementers who are
implementing the Certbot/Boulder version of ACME
(https://github.com/letsencrypt/boulder/blob/master/docs/acme-divergences.md) to
use JOSE libraries that don't support unprotected headers.
Fixes#4417.
* Only protect existing headers.
Implement an Authenticator which can fulfill a dns-01 challenge using
the Google Cloud DNS API. Applicable only for domains using Google Cloud
DNS for DNS.
Testing Done:
* `tox -e py27`
* `tox -e lint`
* Manual testing:
* Used `certbot certonly --dns-google -d`, specifying a credentials
file as a command line argument. Verified that a certificate was
successfully obtained without user interaction.
* Used `certbot certonly --dns-google -d`, without specifying a
credentials file as a command line argument. Verified that the
user was prompted and that a certificate was successfully
obtained.
* Used `certbot certonly -d`. Verified that the user was prompted for
a credentials file after selecting google interactively and that
a certificate was successfully obtained.
* Used `certbot renew --force-renewal`. Verified that certificates
were renewed without user interaction.
* Negative testing:
* Path to non-existent credentials file.
* Credentials file with unsafe permissions (644).
* Domain name not registered to Google Cloud Platform account.
Implement an Authenticator which can fulfill a dns-01 challenge using the
DigitalOcean API. Applicable only for domains using DigitalOcean for DNS.
Testing Done:
* `tox -e py27`
* `tox -e lint`
* Manual testing:
* Used `certbot certonly --dns-digitalocean -d`, specifying a
credentials file as a command line argument. Verified that a
certificate was successfully obtained without user interaction.
* Used `certbot certonly --dns-digitalocean -d`, without specifying a
credentials file as a command line argument. Verified that the user
was prompted and that a certificate was successfully obtained.
* Used `certbot certonly -d`. Verified that the user was prompted for
a credentials file after selecting digitalocean interactively and
that a certificate was successfully obtained.
* Used `certbot renew --force-renewal`. Verified that certificates
were renewed without user interaction.
* Negative testing:
* Path to non-existent credentials file.
* Credentials file with unsafe permissions (644).
* Credentials file missing token.
* Credentials file with blank token.
* Credentials file with incorrect token.
* Domain name not registered to DigitalOcean account.
Ensure that permissions are preserved when renewal data is written to
conf files. This allows users to limit access to the file, if they wish.
Testing done:
* `tox -e py27`
* `tox -e lint`
* Manual Testing
* Got a new certificate. Restricted the permissions on the renewal
conf. Renewed the certificate. Verified that the new renewal conf
permissions matched.
* Revert "Pin python-augeas version to avoid error with 1.0.0 (#4422)"
This reverts commit 1c51ae2588.
* make dependency-requirements
* separate certbot and dependency requirements
* fix build.py
* update hashin comment
* simplify release pinning
* separate letsencrypt dependency
* pin hashes in venv
* error out when bad things happen
* use pinned dependencies in tox
* Revert "pin hashes in venv"
This reverts commit 1cd38a9e50.
* use pip_install.sh in venv_common
* quote pip install args
* bump mock version
Implement an Authenticator which can fulfill a dns-01 challenge using the
Cloudflare API. Applicable only for domains using Cloudflare for DNS.
Testing Done:
* `tox -e py27`
* `tox -e lint`
* Manual testing:
* Used `certbot certonly --dns-cloudflare -d`, specifying a
credentials file as a command line argument. Verified that a
certificate was successfully obtained without user interaction.
* Used `certbot certonly --dns-cloudflare -d`, without specifying a
credentials file as a command line argument. Verified that the user
was prompted and that a certificate was successfully obtained.
* Used `certbot certonly -d`. Verified that the user was prompted for
a credentials file after selecting cloudflare interactively and
that a certificate was successfully obtained.
* Used `certbot renew --force-renewal`. Verified that certificates
were renewed without user interaction.
* Negative testing:
* Path to non-existent credentials file.
* Credentials file with unsafe permissions (644).
* Credentials file missing e-mail address.
* Credentials file with blank API key.
* Credentials file with incorrect e-mail address.
* Credentials file with malformed API key.
* Credentials file with invalid API key.
* Domain name not registered to Cloudflare account.
