mirror of
https://github.com/certbot/certbot.git
synced 2026-07-26 07:39:52 +02:00
ohemorangeandBrad Warren
4abd81e218
Summary of changes in this PR:
- Refactor files involved in the `certbot` module to be of a similar structure to every other package; that is, inside a directory inside the main repo root (see below).
- Make repo root README symlink to `certbot` README.
- Pull tests outside of the distributed module.
- Make `certbot/tests` not be a module so that `certbot` isn't added to Python's path for module discovery.
- Remove `--pyargs` from test calls, and make sure to call tests from repo root since without `--pyargs`, `pytest` takes directory names rather than package names as arguments.
- Replace mentions of `.` with `certbot` when referring to packages to install, usually editably.
- Clean up some unused code around executing tests in a different directory.
- Create public shim around main and make that the entry point.
New directory structure summary:
```
repo root ("certbot", probably, but for clarity all files I mention are relative to here)
├── certbot
│ ├── setup.py
│ ├── certbot
│ │ ├── __init__.py
│ │ ├── achallenges.py
│ │ ├── _internal
│ │ │ ├── __init__.py
│ │ │ ├── account.py
│ │ │ ├── ...
│ │ ├── ...
│ ├── tests
│ │ ├── account_test.py
│ │ ├── display
│ │ │ ├── __init__.py
│ │ │ ├── ...
│ │ ├── ... # note no __init__.py at this level
│ ├── ...
├── acme
│ ├── ...
├── certbot-apache
│ ├── ...
├── ...
```
* refactor certbot/ and certbot/tests/ to use the same structure as the other packages
* git grep -lE "\-e(\s+)\." | xargs sed -i -E "s/\-e(\s+)\./-e certbot/g"
* git grep -lE "\.\[dev\]" | xargs sed -i -E "s/\.\[dev\]/certbot[dev]/g"
* git grep -lE "\.\[dev3\]" | xargs sed -i -E "s/\.\[dev3\]/certbot[dev3]/g"
* Remove replacement of certbot into . in install_and_test.py
* copy license back out to main folder
* remove linter_plugin.py and CONTRIBUTING.md from certbot/MANIFEST.in because these files are not under certbot/
* Move README back into main folder, and make the version inside certbot/ a symlink
* symlink certbot READMEs the other way around
* move testdata into the public api certbot zone
* update source_paths in tox.ini to certbot/certbot to find the right subfolder for tests
* certbot version has been bumped down a directory level
* make certbot tests directory not a package and import sibling as module
* Remove unused script cruft
* change . to certbot in test_sdists
* remove outdated comment referencing a command that doesn't work
* Install instructions should reference an existing file
* update file paths in Dockerfile
* some package named in tox.ini were manually specified, change those to certbot
* new directory format doesn't work easily with pyargs according to http://doc.pytest.org/en/latest/goodpractices.html#tests-as-part-of-application-code
* remove other instance of pyargs
* fix up some references in _release.sh by searching for ' . ' and manual check
* another stray . in tox.ini
* fix paths in tools/_release.sh
* Remove final --pyargs call, and now-unnecessary call to modules instead of local files, since that's fixed by certbot's code being one layer deeper
* Create public shim around main and make that the entry point
* without pyargs, tests cannot be run from an empty directory
* Remove cruft for running certbot directly from main
* Have main shim take real arg
* add docs/api file for main, and fix up main comment
* Update certbot/docs/install.rst
Co-Authored-By: Brad Warren <bmw@users.noreply.github.com>
* Fix comments in readthedocs requirements files to refer to current package
* Update .[docs] reference in contributing.rst
* Move plugins tests to certbot tests directory
* add certbot tests to MANIFEST.in so packagers can run python setup.py test
* move examples directory inside certbot/
* Move CHANGELOG into certbot, and create a top-level symlink
* Remove unused sys and logging from main shim
* nginx http01 test no longer relies on certbot plugins common test
71 lines
4.6 KiB
ReStructuredText
71 lines
4.6 KiB
ReStructuredText
Challenges
|
||
==========
|
||
|
||
To receive a certificate from Let's Encrypt certificate authority (CA), you must pass a *challenge* to
|
||
prove you control each of the domain names that will be listed in the certificate. A challenge is one of
|
||
a list of specified tasks that only someone who controls the domain should be able to accomplish, such as:
|
||
|
||
* Posting a specified file in a specified location on a web site (the HTTP-01 challenge)
|
||
* Posting a specified DNS record in the domain name system (the DNS-01 challenge)
|
||
|
||
It’s possible to complete each type of challenge *automatically* (Certbot directly makes the necessary
|
||
changes itself, or runs another program that does so), or *manually* (Certbot tells you to make a
|
||
certain change, and you edit a configuration file of some kind in order to accomplish it). Certbot's
|
||
design favors performing challenges automatically, and this is the normal case for most users of Certbot.
|
||
|
||
Some plugins offer an *authenticator*, meaning that they can satisfy challenges:
|
||
|
||
* Apache plugin: (HTTP-01) Tries to edit your Apache configuration files to temporarily serve files to
|
||
satisfy challenges from the certificate authority. Use the Apache plugin when you're running Certbot on a
|
||
web server with Apache listening on port 80.
|
||
* Nginx plugin: (HTTP-01) Tries to edit your nginx configuration files to temporarily serve files to
|
||
satisfy challenges from the certificate authority. Use the nginx plugin when you're running Certbot on a
|
||
web server with nginx listening on port 80.
|
||
* Webroot plugin: (HTTP-01) Tries to place a file where it can be served over HTTP on port 80 by a
|
||
web server running on your system. Use the Webroot plugin when you're running Certbot on
|
||
a web server with any server application listening on port 80 serving files from a folder on disk in response.
|
||
* Standalone plugin: (HTTP-01) Tries to run a temporary web server listening on HTTP on port 80. Use the
|
||
Standalone plugin if no existing program is listening to this port.
|
||
* Manual plugin: (DNS-01 or HTTP-01) Either tells you what changes to make to your configuration or updates
|
||
your DNS records using an external script (for DNS-01) or your webroot (for HTTP-01). Use the Manual
|
||
plugin if you have the technical knowledge to make configuration changes yourself when asked to do so,
|
||
and are prepared to repeat these steps every time the certificate needs to be renewed.
|
||
|
||
Tips for Challenges
|
||
-------------------
|
||
General tips:
|
||
|
||
* Run Certbot on your web server, not on your laptop or another server. It’s usually the easiest way to get a certificate.
|
||
* Use a tool like the DNSchecker at dnsstuff.com to check your DNS records to make sure
|
||
there are no serious errors. A DNS error can prevent a certificate authority from
|
||
issuing a certificate, even if it does not prevent your site from loading in a browser.
|
||
* If you are using Apache or NGINX plugins, make sure the configuration of your Apache or NGINX server is correct.
|
||
|
||
HTTP-01 Challenge
|
||
~~~~~~~~~~~~~~~~~
|
||
|
||
* Make sure the domain name exists and is already pointed to the public IP address of the server where
|
||
you’re requesting the certificate.
|
||
* Make sure port 80 is open, publicly reachable from the Internet, and not blocked by a router or firewall.
|
||
* When using the Webroot plugin or the manual plugin, make sure the the webroot directory exists and that you
|
||
specify it properly. If you set the webroot directory for example.com to `/var/www/example.com`
|
||
then a file placed in `/var/www/example.com/.well-known/acme-challenge/testfile` should appear on
|
||
your web site at `http://example.com/.well-known/acme-challenge/testfile` (A redirection to HTTPS
|
||
is OK here and should not stop the challenge from working.)
|
||
* In some web server configurations, all pages are dynamically generated by some kind of framework,
|
||
usually using a database backend. In this case, there might not be a particular directory
|
||
from which the web server can serve filesdirectly. Using the Webroot plugin in this case
|
||
requires making a change to your web server configuration first.
|
||
* Make sure your web server serves files properly from the directory where the challenge
|
||
file is placed (e. g. `/.well-known/acme-challenge`) to the expected location on the
|
||
website without adding a header or footer.
|
||
* When using the Standalone plugin, make sure another program is not already listening to port 80 on the server.
|
||
* When using the Webroot plugin, make sure there is a web server listening on port 80.
|
||
|
||
DNS-01 Challenge
|
||
~~~~~~~~~~~~~~~~
|
||
|
||
* When using the manual plugin, make sure your DNS records are correctly updated;
|
||
you must be able to make appropriate changes to your DNS zone in order to pass the challenge.
|
||
|