From d2578e05e7cfd6e408dc45b6e48d0c42685c014d Mon Sep 17 00:00:00 2001 From: alexzorin Date: Fri, 19 Nov 2021 07:14:10 +1100 Subject: [PATCH 1/2] docs: describe how to modify renewal config (#9014) * docs: describe how to modify renewal config * Apply suggestions from code review Co-authored-by: ohemorange * reword warning about manual modifications * explain the flags in the --force-renewal command Co-authored-by: ohemorange --- certbot/docs/using.rst | 67 ++++++++++++++++++++---------------------- 1 file changed, 32 insertions(+), 35 deletions(-) diff --git a/certbot/docs/using.rst b/certbot/docs/using.rst index 1f441cc55..c9bbaf324 100644 --- a/certbot/docs/using.rst +++ b/certbot/docs/using.rst @@ -747,53 +747,50 @@ commands into your individual environment. and when renewal is not necessary. .. _renewal-config-file: +.. _Modifying the Renewal Configuration File: +Modifying the Renewal Configuration of Existing Certificates +------------------------------------------------------------ -Modifying the Renewal Configuration File ----------------------------------------- +When creating a certificate, Certbot will keep track of all of the relevant options chosen by the user. At renewal +time, Certbot will remember these options and apply them once again. -When a certificate is issued, by default Certbot creates a renewal configuration file that -tracks the options that were selected when Certbot was run. This allows Certbot -to use those same options again when it comes time for renewal. These renewal -configuration files are located at ``/etc/letsencrypt/renewal/CERTNAME``. +Sometimes, you may encounter the need to change some of these options for future certificate renewals. To achieve this, +you will need to perform the following steps: -For advanced certificate management tasks, it is possible to manually modify the certificate's -renewal configuration file, but this is discouraged since it can easily break Certbot's -ability to renew your certificates. If you choose to modify the renewal configuration file -we advise you to test its validity with the ``certbot renew --dry-run`` command. +1. Perform a *dry run renewal* with the amended options on the command line. This allows you to confirm that the change + is valid and will result in successful future renewals. +2. If the dry run is successful, perform a *live renewal* of the certificate. This will persist the change for future + renewals. If the certificate is not yet due to expire, you will need to force a renewal using ``--force-renewal``. -.. warning:: Modifying any files in ``/etc/letsencrypt`` can damage them so Certbot can no longer properly manage its certificates, and we do not recommend doing so. +.. note:: Rate limits from the certificate authority may prevent you from performing multiple renewals in a short + period of time. It is strongly recommended to perform the second step only once, when you have decided on what + options should change. -For most tasks, it is safest to limit yourself to pointing symlinks at the files there, or using -``--deploy-hook`` to copy / make new files based upon those files, if your operational situation requires it -(for instance, combining certificates and keys in different way, or having copies of things with different -specific permissions that are demanded by other programs). +As a practical example, if you were using the ``webroot`` authenticator and had relocated your website to another directory, +you would need to change the ``--webroot-path`` to the new directory. Following the above advice: -If the contents of ``/etc/letsencrypt/archive/CERTNAME`` are moved to a new folder, first specify -the new folder's name in the renewal configuration file, then run ``certbot update_symlinks`` to -point the symlinks in ``/etc/letsencrypt/live/CERTNAME`` to the new folder. +1. Perform a *dry-run renewal* of the individual certificate with the amended options:: -If you would like the live certificate files whose symlink location Certbot updates on each run to -reside in a different location, first move them to that location, then specify the full path of -each of the four files in the renewal configuration file. Since the symlinks are relative links, -you must follow this with an invocation of ``certbot update_symlinks``. + certbot renew --cert-name example.com --webroot-path /path/to/new/location --dry-run -For example, say that a certificate's renewal configuration file previously contained the following -directives:: +2. If the dry-run was successful, make the change permanent by performing a *live renewal* of the certificate with the + amended options, including ``--force-renewal``:: - archive_dir = /etc/letsencrypt/archive/example.com - cert = /etc/letsencrypt/live/example.com/cert.pem - privkey = /etc/letsencrypt/live/example.com/privkey.pem - chain = /etc/letsencrypt/live/example.com/chain.pem - fullchain = /etc/letsencrypt/live/example.com/fullchain.pem + certbot renew --cert-name example.com --webroot-path /path/to/new/location --force-renewal -The following commands could be used to specify where these files are located:: + ``--cert-name`` selects the particular certificate to be modified. Without this option, all certificates will be selected. + + ``--webroot-path`` is the option intended to be changed. All other previously selected options will be kept the same + and do not need to be included in the command. + +For advanced certificate management tasks, it is also possible to manually modify the certificate's renewal configuration +file, but this is discouraged since it can easily break Certbot's ability to renew your certificates. These renewal +configuration files are located at ``/etc/letsencrypt/renewal/CERTNAME.conf``. If you choose to modify the renewal +configuration file we advise you to make a backup of the file beforehand and test its validity with the ``certbot renew --dry-run`` command. + +.. warning:: Manually modifying files under ``/etc/letsencrypt/renewal/`` can damage them if done improperly and we do not recommend doing so. - mv /etc/letsencrypt/archive/example.com /home/user/me/certbot/example_archive - sed -i 's,/etc/letsencrypt/archive/example.com,/home/user/me/certbot/example_archive,' /etc/letsencrypt/renewal/example.com.conf - mv /etc/letsencrypt/live/example.com/*.pem /home/user/me/certbot/ - sed -i 's,/etc/letsencrypt/live/example.com,/home/user/me/certbot,g' /etc/letsencrypt/renewal/example.com.conf - certbot update_symlinks Automated Renewals ------------------ From 676678604933d85d0d5b52449d3c5d3fccd35392 Mon Sep 17 00:00:00 2001 From: alexzorin Date: Tue, 23 Nov 2021 05:00:55 +1100 Subject: [PATCH 2/2] Fix Windows webroot crash when multiple domains have the same webroot (#9108) * Certificate issuing on Window while having web.confing and more then one domain in request * add a test * update changelog Co-authored-by: Serghei Trufkin --- certbot/CHANGELOG.md | 2 ++ certbot/certbot/_internal/plugins/webroot.py | 2 +- certbot/tests/plugins/webroot_test.py | 16 ++++++++++++++++ 3 files changed, 19 insertions(+), 1 deletion(-) diff --git a/certbot/CHANGELOG.md b/certbot/CHANGELOG.md index 8df29801d..0a5849d82 100644 --- a/certbot/CHANGELOG.md +++ b/certbot/CHANGELOG.md @@ -20,6 +20,8 @@ Certbot adheres to [Semantic Versioning](https://semver.org/). * Fixed an issue on Windows where the `web.config` created by Certbot would sometimes conflict with preexisting configurations (#9088). +* Fixed an issue on Windows where the `webroot` plugin would crash when multiple domains + had the same webroot. This affected Certbot 1.21.0. More details about these changes can be found on our GitHub repo. diff --git a/certbot/certbot/_internal/plugins/webroot.py b/certbot/certbot/_internal/plugins/webroot.py index 81f46b204..1a4892ac9 100644 --- a/certbot/certbot/_internal/plugins/webroot.py +++ b/certbot/certbot/_internal/plugins/webroot.py @@ -221,7 +221,7 @@ to serve all files under specified web root ({0}).""" if os.path.exists(web_config_path): logger.info("A web.config file has not been created in " "%s because another one already exists.", self.full_roots[name]) - return + continue logger.info("Creating a web.config file in %s to allow IIS " "to serve challenge files.", self.full_roots[name]) with safe_open(web_config_path, mode="w", chmod=0o644) as web_config: diff --git a/certbot/tests/plugins/webroot_test.py b/certbot/tests/plugins/webroot_test.py index 54c51ae1d..d7e961596 100644 --- a/certbot/tests/plugins/webroot_test.py +++ b/certbot/tests/plugins/webroot_test.py @@ -115,6 +115,22 @@ class AuthenticatorTest(unittest.TestCase): from certbot._internal.plugins.webroot import _WEB_CONFIG_SHA256SUMS self.assertTrue(webconfig_hash not in _WEB_CONFIG_SHA256SUMS) + @unittest.skipIf(filesystem.POSIX_MODE, reason='Test specific to Windows') + def test_foreign_webconfig_multiple_domains(self): + # Covers bug https://github.com/certbot/certbot/issues/9091 + achall_2 = achallenges.KeyAuthorizationAnnotatedChallenge( + challb=acme_util.chall_to_challb(challenges.HTTP01(token=b"bingo"), "pending"), + domain="second-thing.com", account_key=KEY) + self.config.webroot_map["second-thing.com"] = self.path + + challenge_path = os.path.join(self.path, ".well-known", "acme-challenge") + filesystem.makedirs(challenge_path) + + webconfig_path = os.path.join(challenge_path, "web.config") + with open(webconfig_path, "w") as file: + file.write("something") + self.auth.perform([self.achall, achall_2]) + @test_util.patch_display_util() def test_webroot_from_list_help_and_cancel(self, mock_get_utility): self.config.webroot_path = []